Re: [cc65] # of local variables allowed?

Date view Thread view Subject view

From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2003-03-01 13:37:57


On Sat, Mar 01, 2003 at 01:14:18PM +0100, M Ancher wrote:
> Since I have two functions which are recursive, I cannot just use the
> »--static-locals«-switch on all code. I thought about moving the
> recursive code into another ».c«-file and compile that without
> »--static-locals«. (It could be linked later, right?)
>
> This is one option, but is it better to:
>
> I could move the functions that gives the error »Too many local
> variables« into another ».c«-file. This way only the »troublesome« code
> is compiled with »--static-locals«. This solution would save more memory
> at runtime, since it will only allocate memory when needed, right?

There's also a

        #pragma staticlocals(on|off)

command that will command the compiler to place local variables into the .bss
segment or onto the stack respectively. Using this pragma, you can compile one
function this way and another the other way. The #pragma command is described
in more depth in the documentation.

Using "--static-locals" will need more memory for data, because memory for
local variables is allocated statically, so it is needed even when the
function is never called. On the other side, accessing this data is easier and
faster, because the address is known and no index register and indirect
addressing mode is needed. So while "--static-locals" needs more memory for
data, the code is usually somewhat smaller and faster. Some of the sample demo
programs are compiled with static locals for this reason, because a few cycles
in a tight loop can add up considerably.

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.


Date view Thread view Subject view

This archive was generated by hypermail 2.1.3 : 2003-03-01 13:38:06 CET