From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2003-02-06 10:46:00
Hi!
On Wed, Feb 05, 2003 at 04:10:33PM -0800, Shawn Jefferson wrote:
> Am I correct in saying that local variables are put on the stack?
In most cases yes. Exceptions:
* Local variables declared as static do not go onto the stack.
* Using the --static-locals compiler switch will cause the compiler to
place local variables in static storage.
* Variables declared as "register" do not go onto the stack if register
variables are enabled and there's enough free space left in the register
bank.
> It
> appears that for some reason cc65 is grabbing a value from the stack
> incorrectly for some computations. The weird thing is that if I take this out
> of my program and put into a small test file it works!
Code generated for a specific function is independent of the other functions
in this module (that is, cc65 does no global optimizations). So if you move a
complete function into a separate module and include the same header files,
the same code will be generated.
> Would there be any case where the compiler would grab stuff from the stack
> beyond the local variables?
Apart from local variables, there are some other objects stored onto the
stack:
* Parameters passed to the executing function.
* Parameters passed to called functions.
* Intermediate results for expressions or values passed to runtime helper
functions.
* The old contents of the register bank if the function utilizes register
variables.
Have you tried using the debugger module instead of the builtin debugger of
your emulator? The debugger module runs on the 6502 machine, so it's more
limited in some areas than an emulator. However, since it knows about some
cc65 internals, and it has a nice fullscreen view, it can often display more
useful information. I have to admit that I prefer using the debugger module
over the debugger built into VICE, provided that none of the limitations come
into effect.
To use the debugger module, include <dbg.h>, and call the initialization code
at program start:
DbgInit (0);
Then, compile one or more breakpoints into the code using the BREAK() macro.
If the program reaches a breakpoint, the debugger screen will pop up
(destroying your program output). Among other things, it displays both stacks,
the parameter and the CPU stack ("CS" denotes the current C stack pointer).
Please note that you will have to use "s" to skip the BRK instruction
generated by the BREAK macro before you can single step through your code.
Don't know if this helps, but it's probably worth a try.
Regards
Uz
--
Ullrich von Bassewitz uz_at_musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2003-02-06 10:46:12 CET