Re: more question about porting/gcc

[hyc@troy.la.platsol.com (Howard Chu)]

  > of one point: The mshrink() problem, which should really be fixed (this is
  > also good for Multitasking only, when I am compiling something and I am
  > starting up another program this usually ends up in crashes because the
  > gcc starts up very often and consumes up all Memory...

  I'm not sure this helps, but have you tried fixstack'ing different
  (either large positive or suitable negative) values?  If I remember
  correctly (it's some time since I used my Atari), gcc has stack of -1
  (glob all you get).

Correct. I usually fixstk mine to -2, for 1/2 of available mem. You can
of course choose other values as you see fit. -1 was a good default for
single-user STs; -2 or -4 might make more sense on your systems that have
larger amounts of RAM installed.

It's unfortunate that we're stuck with this contiguous stack/heap setup. 
(The library requires this to check for stack/heap collision.) I recall a
long time back some folks were talking about a new memory management scheme
that would allow more freedom for the stack allocation - anyone else recall
the details? Probably wrapped up in Fenix discussions. The problem here, of
course, is that gcc loves to use alloca() to dynamically allocate things on
the stack, so you have to give it as much potential stack space as you can
afford... Most programs that just use malloc() won't ever have this problem.
Maybe it's time we thought about a more flexible (but much slower) alloca()
implementation... If, instead of allocating the entire block on the stack,
it only pushed an activation record, and then called malloc to get the actual
block, stack usage would be decreased a whole lot. Then you just have to
remember to call free() on all the stacked records before popping out of the
current context...
  -- Howard