Hi! On Sat, Mar 20, 2004 at 03:23:53PM +0100, Spiro Trikaliotis wrote: > I would have thought that function a() would generate almost the same > code as function b(), but "reuse" the memory for variable b with > variable c. As I see in the assembler output, this is not the case. > Instead, the stack is manipulated twice, once when a block is left and > once when the new block is entered. Yes. This is documented behaviour (see coding.sgml). > I know other C compilers (a "little" bit bigger than cc65, like MSVC) > analyse the full function, reserve enough memory for *every* block > inside at the beginning of the function, and just dynamically adapt the > usage of this memory when entering and leaving blocks. This way, the > stack has to be manipulated only once. Isn't this possible with CC65? > Does it need too much analysis? cc65 generates direct assembler code in one pass (no intermediate code). The problem with stack access is that there is no base pointer, variables are accessed via sp+offs. This means that when changing the variable space, the compiler does not only need to adjust all offsets accessing the stack, it may even have to change the code later on (if variables are no longer reachable with an index register). If you compare that with code for the 80x86 family, you will see that adjusting variable memory is easy with a base pointer (I've done that myself in other compilers). No need for any analysis, just increase the space for variables. The only instruction that will have to be patched when the function is complete is the sub sp,xx on entry. I've thought about that already, and considered using a base pointer. Since a base pointer is fixed, variable offsets do not change, so adding more variable space does not need code changes. But unfortunately, the 6502 has no way to use negative offsets. This means that one part of the stack would have to be accessed as before (relative to sp), while variables would have to be accessed relative to bp. This would double the code needed for the small helper routines that manipulate stuff on the stack. So I dropped the idea. Regards Uz -- Ullrich von Bassewitz uz@musoftware.de ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Sat Mar 20 18:49:30 2004
This archive was generated by hypermail 2.1.8 : 2004-03-20 18:49:36 CET