Re: VM as target, was Is Assembler Language essential

>> [ about frame pointers or the lack thereof]


>
> ??? In general it costs nothing - local variable addressing is simply
> stack-relative instead of frame-relative. It's simple for the
> compiler to figure out the constant offsets involved when/if the frame
> expands.
>
> Non-locals are always addressed frame-relative. Regardless of FP or
> SP local addressing, the code has to maintain some kind of frame
> pointer to find non-local variables. Unless your chip has a hardware
> display, you're going to be using a general address register to fetch
> or find the nonlocal's frame and then adding a constant offset to it.
> In this situation, not using FP for local addressing gives you an
> extra address register.
>
> The only cost to stack-relative addressing is on the debugging end.
>


well, there are many uses beyond debugging...


other uses include:
stack unwinding in some approaches to exception handling (IP-range based
exception handlers);
simplifying reflection ability and allowing precise garbage collection;
...


for example, due to this deficiency one has to use another location to hold
a list of linked exception frames, which actually hurts raw performance in
general (universally keeping the frame pointer allows very lightweight
exception handling, since the only time anything is actually done specially
is during the exception itself, but otherwise the code is structured as if
there were no exception handler).


now, with no frame pointer, the compiler has to go and endlessly link in and
unlink exception frames (representing the try block), which is not free...
and the compiler can't just simply add this cheaper approach, because it is
not possible to implicitly unwind.




we can take note that the SysV/AMD64 and Win64 ABI's address this particular
problem specifically in their design (one by still using a frame pointer,
the other by using special prologues and epilogues but making the frame
pointer optional, while still allowing automatic unwinding).




>
>>> Stack tracing can be done without a frame pointer ... the debugger
>>> knows the function call sequence and the compiler's debug information
>>> provides the argument and local variable layout at function entry and
>>> may also incrementally provide info on other automatic variables at
>>> entry into local subscopes. From that starting point the debugger has
>>> to track the code position and monitor the stack pointer to build up a
>>> picture of what's currently on the stack. GDB doesn't do it.
>>
>>Yes, it is possible to backtrace, for example, by locating the return IP,
>>and then getting back to that function and locating the next return IP,
>>...
>>but this requires keeping precise debugging information, and is likely to be
>>both far more complicated and more computationally expensive than using the
>>frame pointer for backtracing.
>
> I guess the question is "what do you consider expensive?" I used to
> do cross platform embedded work. I expect hardware debuggers to run
> code at full speed, but I don't have the same expectations for any
> software debugger. I don't want the debugger to be "too intrusive",
> but neither do I expect it to have no impact on execution.
>
> It's simple for a debugger to take a link map and instrument the
> program with trap (software interrupt) or port output instructions to
> track function entry/exit. I've used chip simulators, cross-debuggers
> and 3rd party profilers that do this, but (oddly) I've never yet seen
> a native debugger use this technique - which is strange, I think,
> because they usually implement breakpoints with traps and good
> debuggers typically have the option of executing a script at a
> breakpoint and then continuing execution.
>
> If you are making millions of calls to tiny functions in an FPL, then
> maybe this would be a bit intrusive, but again, you have to consider
> that you are debugging. If you really need to debug your program at
> full speed, invest in a hardware debugger.


the issue is not so much debugging, but the frame-pointer may be useful in
in implementing many kinds of compiler and runtime features, which are then
fouled up by the presence of code in the call frame which does not allow
proper unwinding, and where the information necessary for this unwinding is
not available.


the lack of information leads to many kinds of difficulties, which is partly
why traditionally C and C++ are forced to use conservative garbage
collectors, ... when, technically, it would not cost much for the compiler
to leave the necessary information in the app itself (be it something as
simple as a frame pointer, to the symbol table, to the type annotations of
variables and functions, ...).




instead, it leaves many people with the impression that the future of
computing lies with the JVM and .NET, simply because they provide many
features for which the typical C and C++ compiler writers considered not
worthwhile to facilitate...

Return to the comp.compilers page.
Search the comp.compilers archives again.