[Coco] DCC and UltiMusE 3

Jeff Teunissen deek at d2dc.net
Fri Jan 1 22:08:42 EST 2021


On Fri, Jan 1, 2021 at 3:56 PM Jeff Teunissen <deek at d2dc.net> wrote:
> However, it seems that UltiMusE is causing the preprocessor to use an
> absurd amount of stack space. By increasing stack space to 25 pages
> (the default is 14), I was able to get it built, but that reduces
> dcpp's ability to store symbols, which I'm not yet prepared to do.
>
> I'm looking at making a slight change to how dcpp uses memory --
> allocating all available RAM in the program header, and using ibrk()
> instead of sbrk() to do variable allocations. This should allow truly
> huge (temporary) stack use for programs that need it, while also
> allowing the maximum number of preprocessor symbols.

I have successfully made a version of dcpp, the DCC preprocessor, that
runs with 40K of combination stack-space and preprocessor symbol
space. If you need a lot of stack, you'll have a greater tendency to
run out of storage for named symbols...but if you don't need a lot of
stack, you'll be able to define a very large number of them.

dcpp is still way faster than c_prep, about the same speed as c.prep
-- but a lot more capable. It seems to have no trouble with anything
UltiMusE can throw at it.

One file, bin.c, seems to cause dcc68 to run out of memory right now,
but that's possibly to be expected.


More information about the Coco mailing list