Possible linker optimisations
colinleroy opened this issue · comments
Hi,
I'm currently on a project where the executables are big, due to my use of video, which reserves $2000-$3FFF for video). There is also too much code to use --start-addr 0x4000, so my binary looks like this, with code split below and above HGR video memory:
NULL 000000 000000 000000 00001
ZEROPAGE 000080 000099 00001A 00001
EXEHDR 0007C9 000802 00003A 00001
STARTUP 000803 000839 000037 00001
LOWCODE 00083A 001FDA 0017A1 00001
HGR 002000 003FFF 002000 00001
CODE 004000 00867F 004680 00100
RODATA 008680 008F2D 0008AE 00001
DATA 008F2E 009118 0001EB 00001
INIT 009119 009177 00005F 00001
RT_ONCE 009178 009C9C 000B25 00001
BSS 009C9D 009FFD 000361 00001
ONCE 009C9D 009E0A 00016E 00001
LC 00D400 00DFAC 000BAD 00001
In this example, I have a problem where I would like to reserve the second graphics page ($4000-$5FFF) to be able to do double-buffering. But this doesn't work, because there is too much code:
ld65: Warning: ../../config/apple2enh-avstreamer.cfg:34: Segment 'BSS' with type 'bss' contains initialized data
ld65: Warning: ../../config/apple2enh-avstreamer.cfg:17: Segment 'LC' overflows memory area 'MAIN' by 2866 bytes
ld65: Error: ../../config/apple2enh-avstreamer.cfg:18: Size of memory area 'BSS' is negative: -535
It would be nice to be able to build a tighter binary. This could be done by storing the ONCE segment somewhere inside $2000-5FFF. The LC segment, which is an Apple2enh target thing, also stores code at the end of the binary, after ONCE, and relocates it to $D400 at startup.
Having the ability to store ONCE and LC at $4000 would allow my executable to build and run fine.
I have tried to move ONCE and LC in the linker config file, but there are assumptions both at build and runtime that ONCE is at the end of the binary.