Does that help? "The use of static inside a function is the simplest. It simply means that once the variable has been initialized, it remains in memory until the end of the program. You can think of it as saying that the variable sticks around, maintaining its value, until the program completely ends. For instance, you can use a static variable to record the number of times a function has been called simply by including the lines static int count =0; and count++; inside the function. Because count is a static variable, the line "static int count = 0;" will only be executed once. Whenever the function is called, count will have the last value assigned to it. "
The linker should never reassign the memory location used by a static variable. You could then find the address of the variable with a pointer to it. However, a "static" declaration by itself will not allow you to "set" the address of the variable. Maybe something like: static unsigned char at GLOBAL_V_LOCATION+0x86 FooBar; would work in SDCC. This could be declared at the function level or module level. Once static, the variable space is permanently allocated, where you declare it only affects visibility. I am not familiar enough with the SDCC linker to know if overlay linking is supported, but I am familiar with the Keil overlay linker, and unless a variable is declared static (or is global), the Keil overlay linker will reuse memory locations for local variables, in an effort to optimize memory usage, unless the "NOOVERLAY" option is specified. This is done through a function dependency analysis, to make sure that variables that are overlaid are truly independent. It reduces RAM usage sometimes dramatically. Didier -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, August 18, 2008 1:08 PM To: sdcc-user@lists.sourceforge.net Subject: Re: [Sdcc-user] laying out memory didier wrote: > Would'nt the "static" keyword take care of that? i'm not sure how that would help. > > Is it that you want to know where the variable resides, or > simply to make > sure the memory space is not overlaid with > another variable? well, it's never my intention to inadvertently use the same memory location for two different variables. and yes, i need to set the explicit location of large numbers of variables which are sometimes accessed externally by a host processor for debug and monitor purposes. paul > > Didier > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] > Sent: Monday, > August 18, 2008 10:09 AM > To: sdcc-user@lists.sourceforge.net > Subject: > [Sdcc-user] laying out memory > > i've recently discovered sdcc's (highly > unusual :-) trick of letting two > variables overlap, without much in the > way of user warning. > > i have variables in xdata on an 8051 that need to be "locked down" with > > something like: > unsigned char at GLOBAL_V_LOCATION+0x86 FooBar; it turns out that sdcc > will > happily reuse that location for its own purposes, as documented (thanks to > > frieder for pointing this > out): "Thus it is left to the programmer to > make sure there are no overlaps > with other variables that are declared > without the absolute address." (took me > quite a while to find this -- i > consider this a bug in the linker. at the > least, the docs should have a > more prominent "WARNING" at that point.) > > the obvious workaround is to > tell the linker that xdata lives in a region not > used by my "locked down" > variables. however, i really need to tell it about > two separate sections > -- the space in between needs to be locked down for > "legacy" reasons. (i > can probably change this, but i'd much rather not.) > > so i'd like to do > something like: > > $(LD) --xram-loc-1 0xf400 --xram-size-1 256 --xram-loc-2 0xf800 \ > --xram-size-2 256 > > is the sdcc linker capable of this? > > paul > =--------------------- > paul fox, [EMAIL PROTECTED] > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Sdcc-user mailing list > Sdcc-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sdcc-user > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Sdcc-user mailing list > Sdcc-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sdcc-user =--------------------- paul fox, [EMAIL PROTECTED] ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
