On Tue, 28 Mar 2023 at 12:55, Adrian Chadd <adr...@freebsd.org> wrote:
> Hi! I'm writing a little editor for CP/M 3. I have found a bunch of > examples to generate CP/M binaries using SDCC and that works just fine. > > But the default 1k heap isn't large enough, and I'd really like to be able > to use whatever RAM is available between the end of the segment list(s) and > the top of the transient program area (TPA.) > > If I were doing this with gcc/gnu linker, I'd just define a symbol at the > end of the generated segments in RAM. but the segment/area list here is .. > not defined the same way. And it seems that the linker logic is a little > different per target platform because, well, embedded > microprocessor/controllers can have funky addressing/banking requirements. > :) > > So, what's a neat hack I could do to find the end of the generated segment > list? I thought about using a .o at the end of the build line, but I am not > sure what is the "last" generated segment. > > Ah, I think I figured out something that works. * fully list the areas in the CP/M crt0.s that is being used here, rather than only a handful * that includes HEAP/HEAP_END and such * put my end of file area (called ZZZ) with a symbol in it in that area * the linker now puts things in that order and bam, I end up with a symbol pointing to the end of the program + its memory allotments at runtime. It also means I can eventually do stuff like verify I have enough CP/M TPA for the data/heap segments rather than it just trashing RAM later on. I /also/ came up with a semi-neat way to add heap segments at runtime, as now i can enumerate the "rest of RAM" using the above method (which is basically the space between "end of program" above and the end of the CP/M TPA), I'll go pull down the svn version of sdcc and generate a diff against malloc.c to expose an extra API to add memory regions to the heap at runtime. (Obviously that only works for regions that aren't going to be banked out, but I figure if someone adds memory to the heap at runtime they know what they're doing.) -adrian
_______________________________________________ Sdcc-user mailing list Sdcc-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sdcc-user
