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...
.

Relevant Pages

  • Re: VM as target, was Is Assembler Language essential
    ... may, technically, break some assumptions that could be made by my compiler ... Whether it's a "good practice" is arguable, but omitting the frame ... In general it costs nothing - local variable addressing is simply ... From that starting point the debugger has ...
    (comp.compilers)
  • [ANN] ECL 9.6.0
    ... Important changes related to the usability of the debugger and ... inspector, debugging of compiled C code, handling of floating point ... Formerly ECL would refuse to print those pathnames if ... The compiler can now generate some Lisp constants as static C ...
    (comp.lang.lisp)
  • Re: Interview Embedded Software Questions
    ... Although this is NOT 100% true if we talk about the debugger! ... int x=1; ... The compiler doesn't have to be broken at all. ... it means that if z does not equal 3 it equals to something else ...
    (comp.arch.embedded)
  • Re: help with bsod... stop: 0x8e
    ... and see if it boots cleanly to regular mode. ... Some common problems are exception code 0x80000003. ... If this happens, make sure a debugger gets connected, and the ... Arg3: f7ad699c, Trap Frame ...
    (microsoft.public.windowsxp.help_and_support)
  • Re: my windows XP reboot suddenly
    ... Loading Kernel Symbols ... If a kernel debugger is available get the stack backtrace. ... Frame IP not in any known module. ... FOLLOWUP_NAME: MachineOwner ...
    (microsoft.public.windowsxp.configuration_manage)
Loading