Didier, In this regard the keyword static has the same effect as making the variable global. I guess Paul already made his variables global.
Paul, Is it ok to initialize those manually located variables? If so, add an initializer and check if overlaps still happen. A while ago I added this distinction that uninitialized variables located with __at are not allocated by the linker (same as before), but initialized ones do get their space reserved. But to be honest I'm not sure if it works in every memory space, so please verify the map-file. Maarten > 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 > > ------------------------------------------------------------------------- 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
