[M3devel] Static chains

Jay jayk123 at hotmail.com
Tue Jan 15 06:54:05 CET 2008


I really don't think an optimizing compiler should be passing around unused static links just for the debugger to use. The debugger should look up the stack itself.
 
Optimizing compilers remove locals, remove parameters, remove functions, create custom calling conventions, etc.
 
An non-optimizing compiler, sure, I guess.
 
Though it seems some level of optimization should be always on.
It pains me to think that every little function call I write might be made, and not inlined.
Microsoft compilers now do inlining across static lib boundaries.
Or that constant arithmetic like:#define A 1
#define B 2
int c = (A + B)
 
might be computed at runtime.
 
Or that 
while(1)  ..
  .. if ... break;
 
might generate a runtime check if 1 is not zero (along with the code bloat).
 
Microsoft has "__forceinline", and it is a warning or error if the compiler is unable to inline such a function.
 
 - Jay> Date: Mon, 14 Jan 2008 17:24:35 -0600> From: rodney.bates at wichita.edu> To: hosking at cs.purdue.edu> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] Static chains> > Think of the debugger as an interpreter for a substantial subset of the> language. When the program is stopped at some point, m3gdb can, in effect,> inject code to evaluate an arbitrary expression, typed by the debugger> user, or execute an arbitrary assignment or call statement. Although> there are a number of gaps yet in the implementation, m3gdb is approaching> fitting this description.> > The user-typed code can both create and use static link values that do> not occur in the original code that the compiler saws. The simplest> example is, when stopped in a nested procedure, the user types> 'print NonLocalVariable'. This works fine right now, unless the compiler> has not stored the SL in the current proc's activation record, which a> compiler might well do if the nested proc, as coded, has no references> to any nonlocal variables. (Or keeps the SL only in a register, etc.)> > You could say this is only a convenience, as the user could work around> it by just typing 'up' the exact number of times to get to the static> parent's frame (which is, of course, also a dynamic ancestor). But that> can slow down debugging a great deal, and I often find it a very important> convenience. Anyway, you could say that to a degree about much of what a> debugger does.> > A more complex example might be 'print Nested1(Nested2,NonlocalVar)',> where Nested1 and Nested2 are nested procedures. Here, the debugger> has create and pass the appropriate SL value in order to call Nested1,> which, unless Nested1 is one scope deeper than the current stop point,> also entails m3gdb's fetching the SL that was given to some procedure> on the current dynamic call chain. The same things are required of> m3gdb to construct the closure for Nested2, which it must pass to Nested1.> And if NonlocalVar is in an outer scope where Nested1 and/or Nested2> aren't visible, there would be no workaround possible at all.> > Tony, I haven't been able to try out your latest change anyway, as> I seem to have once again regressed to not being able to get CM3 to> link to a working version of libpthread on Mandriva. Also, I am about> to travel for a week, so may be out of this discussion for a while.> > > Tony Hosking wrote:> > Rodney,> > > > I just realised that the static chains variables are *not* always being > > set up for nested function internal use. i.e., callers will pass them, > > but nested functions that don't explicitly use them will not have a > > static chain. Is this something essential for you? Why would you need > > a static chain from within a nested function that doesn't use any outer > > scope variables? Since it doesn't use any outer scope variables they > > cannot affect its execution, so debugging the value of those variables > > seems unnecessary. This is the default behavior of gcc for static chains.> > > > -- Tony> > > > > > -- > -------------------------------------------------------------> Rodney M. Bates, retired assistant professor> Dept. of Computer Science, Wichita State University> Wichita, KS 67260-0083> 316-978-3922> rodney.bates at wichita.edu
_________________________________________________________________
Put your friends on the big screen with Windows Vista® + Windows Live™.
http://www.microsoft.com/windows/shop/specialoffers.mspx?ocid=TXT_TAGLM_CPC_MediaCtr_bigscreen_012008
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080115/655d6d12/attachment-0002.html>


More information about the M3devel mailing list