Hi, In an attempt to free some code space, I'm looking at a couple of options; a) preventing the compiler from automatically placing all string constants in the common code area (regardless of in which banks the strings are used) or b) locating all string constants in XDATA. I gather I'll need to use OMF2 and STRING and maybe XCROM directives (and LX51). I'm missing something obvious with this option though, since the initialisation strings for these constants will have to be somewhere within the code, so where does the saving occur? Has anyone experience or recommedations with either of these approaches? Thanks, David
String constants in XRAM won't help you at all---XDATA is erased by power-cycling, so somewhere in the initialization code, there will have to be a master copy of that constant to generate the XRAM contents are reset time. Which of course means you've now come round full-circle and again have a string constant that the compiler has to store somewhere in CODE space...
Hans, Exactly! But what's killing the code space at the moment is the compiler placing all the 'code' string constants in the 'common' code area, so many are needlessly repeated in all banks. I'd like a more elegant way of directing certain string constants to reside in banks appropriate to the module in which they're used. This business of using BANK1 (?CO?MODULE, LOC) etc is okay, but I'd rather not have to manually fix the locations within the bank. Can't seem to find an easy way of doing this...
"the initialisation strings for these constants will have to be somewhere within the code, so where does the saving occur?" It relies upon your target hardware having some non-volatile storage mapped into XDATA space. eg, the Triscend E5 has a linear external address space, and the 8051's CODE and DATA are mapped into this linear space. Thus, you can map 64K of the external ROM into CODE space, and a few K of the external ROM (containing your strings) into XDATA space. You can do this with all your const items - not just strings. You need to make sure that you have the updated OHX51 without this bug: http://www.keil.com/forum/docs/thread2074.asp
It's not at all 'needless' that the constants are in the common area, and thus visible regardless of the current bank. The compiler cannot know which routines in which banks may, at some time or another, have a pointer to your string as one of their local variables. Given that, the string has to be available to all banks --- i.e., it has to be in the common area, if it's in code space at all.