Closed mankeli closed 1 year ago
I think this is an optimization. The Amiga data Hunk has a way to say "I have actual data until size X, the rest of the data hunk is filled with zeros". The zeros are not stored in the file. This is as good as a BSS section.
well, one exe is 2.1MB and the other is 62kB, so even if it's an optimization, it doesn't work. And if there's multiple arrays, the unintialized ones don't seem to be at the end of the data hunk.
I was wondering earlier if the __chip section attribute interferes with the section selection, but now that I found out that the initialization order matters, it seems more unlikely explanation.
The programs do run, if you have more than 2MB Chip RAM.
There is no direct .chipbss
section atm, you only have __chip
. The selection is done via hooks which select the section for you - and there is the problem, which will be solved eventually.
=> put all the uninitialized stuff at the end at the start and you get small executables.
If you have time, could you enlighten me a bit about where these section selection hooks are defined / how the selection process happens? I could take a look at it.
The hook amiga_named_section
now clears the last section on chip
, fast
or far
.
This may emit some superfluous section directives, but the switch to .bsschip
is now better handled.
Nice! This seems to produce bit-to-bit exactly same binaries with both code paths. Thank you :)
So two chip memory arrays. Initialized one should go to data section, non-initialized to bss. But if the initialized one is defined first, both of them go to data section. Repro case below, compile with gcc test.c -o test.exe -O3