#2089 Initialized data stored twice in the output (string lit.)
SDCC : mcs51/gbz80/z80/z180/r2k/r3ka/ds390/pic16/pic14/TININative/ds400/hc08/s08 3.2.1 #8127 (Oct 2 2012) (Linux)
Global data initialization is awful with Z80: I use code loaded into RAM so I don't need complicated solutions needed when code/data memory is so separated like with general MCUs.
However, even with this _INITIALIZED and _INITIAILIZER scheme, I found some odd thing: why does sdcc store data _duplicated_ in the resulted binary? For example this C example fragment:
char welcome[] = "Hello world, this is not const!";
will cause something like this in asm listing:
.area _INITIALIZED
_welcome::
.ds XX
.area _INITIALIZER
__xinit__welcome:
.ascii "Hello world, this is not const!"
.db 0x00
Well, this is quite clear, even if I am happy to get some sdcc command line switch to turn off separating initializer/initialized segments and store the initialized data _EXACTLY_ the same way as with const. I use only RAM, no ROM, so it does not matter for me, currently as a workaround I use only const stuffs even if I want to modify the value via pointers/casts, but this is ugly :(
Anyway, the situation is even more complicated as it seems sdcc stores the initialized data once more time! With the example above, I found this as well:
.area _CODE
__str_4:
.ascii "Hello world, this is not const!"
.db 0x00
Why this is needed at all? Initialize value is already stored, what this is used for? CUrrently I am having some ugly awk script to "kill" these from the asm files generated by sdcc, as it seems it's a bug: these are NEVER used things, so why are they generated at all then?
I just tested, and I only see the bug when string literals are used to initialize; other cases seem to work as intended. String literals are a special case in some ways, so it seems I overlooked some of this special case handling when implementing _INITIALIZED/_INITIALIZER.
Philipp
I see, to be honest this is my first try to use sdcc for creating programs for the Enterprise-128 computer which is Z80 based, I wrote custom crt0 for the purpose so I've only tested some quick programs with string literals, and I noticed the problem. It would be great to fix this problem, thanks.
I almost daren't ask about the initiralizer "problem" anyway, that is it a simple way to forget the _INTIALIZED/_INITIALIZER scheme, and since I want to use only RAM it would be great to have the already initialized state somehow. As far as I can see sdcc is mainly for MCUs so it's a special case for it, and it's not something which is required by too much sdcc users. Anyway, the overhead is not so much now, just some LDIR for copying, but still I think it would be better if I can save this is as well.
This bug is not z80-specific. It occurs for the z80, z180, r2k and r3ka ports for the variables using the new initialization mechanism, but the same bug is visible in the other ports in the xinit mechanism (I just tested hc08, s08 and mcs51).
Philipp
The call to resolveIvalSym() in line 229 of SDCCglue.c calls decorateType(), which in turn calls stringToSymbol(), which allocates the second copy of the string. Simply disabling allocation there by setting noAlloc is not sufficient, since that would break initializations of char pointers by string literals.
Philipp
Fixed in reversion #9369.