Re: VM as target, was Is Assembler Language essential

On Mon, 23 Feb 2009 07:20:49 +1000, "cr88192" <cr88192@hotmail.com> wrote:


>"George Neuner" <gneuner2@comcast.net> wrote in message
>> On Sat, 21 Feb 2009 05:38:11 +1000, "cr88192" <cr88192@hotmail.com> wrote:
>>
>>>a related issue is that, my code can be linked with code produced by GCC
>>>(or MSVC, which has something similar), and GCC has this issue: many people
>>>think it good practice to compile code with '-fomit-frame-pointer', which
>>>may, technically, break some assumptions that could be made by my compiler
>>>(such as if directly implementing exception unwinding, ...), and sadly, is
>>>common practice within many of the system APIs (as evidenced by gdb's
>>>inability to produce backtraces, ...).
>>
>> Whether it's a "good practice" is arguable, but omitting the frame
>> pointer increases function call speed, slightly reduces stack usage
>> and provides another general address register to use.
>
>yes, but at a reasonable cost?...


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




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


George

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