On Tue, 13 Jun 2017 09:19:51 -0700 "John R. Hogerhuis" <jho...@pobox.com> wrote:
> > Thanks for the responses. You're welcome. > > I'll give some thought to a "heap". One idea would be to just > allocate a heap on the stack. > Man, I told another M100 guy (not on this list AFAIK) that I was building a m100 runtime for Small-C, and he was immediately on my case about RAM overhead. :-( And now you want a heap, as well as the stack? Guy can't win for losing around here. HHOK :-) > I think the stack grows downward from HIMEM towards files that grow > up from low RAM. It's basically the programmer's problem to worry > about it. > Yes, but the M100 is such a weird machine... The usual penalty for your stack growing too large is your own program gets eaten first. On the M100 it would be the user's files. And that might make them... cranky. > I'm not sure a guard is possible because, yeah, files grow at > runtime. So it would be expensive to constantly monitor. I've thought about it. Yes, it would be expensive, and would require the compiler add calls to a stack-check function in basically every function. > > Though if we create a file management library it could probably be > done efficiently if the programmer agrees to only use the file > management library to mess with files. Heh, sorry I'm busy providing access to the raw ROM file-handling API... ;-) (:Man, when they say KILASC can only delete ASCII files they mean it! :) Willard -- Willard Goosey goo...@sdc.org Socorro, New Mexico, USA I search my heart and find Cimmeria, land of Darkness and the Night. -- R.E. Howard