[sdcc-devel] [ sdcc-Bugs-3575227 ] Initialized data stored twice in the output (string lit.)

[SourceForge.net <no...@so...>]

Bugs item #3575227, was opened at 2012-10-07 02:03
Message generated for change (Comment added) made by lgb
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3575227&group_id=599

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: z80 port
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: LGB Gábor Lénárt (lgb)
Assigned to: Nobody/Anonymous (nobody)
Summary: Initialized data stored twice in the output (string lit.)

Initial Comment:
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?

----------------------------------------------------------------------

>Comment By: LGB Gábor Lénárt (lgb)
Date: 2012-10-07 06:12

Message:
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. 

----------------------------------------------------------------------

Comment By: Philipp Klaus Krause (spth)
Date: 2012-10-07 03:18

Message:
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


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3575227&group_id=599