bouma@cs.purdue.EDU (William J. Bouma) (11/11/89)
In article <918@acf5.NYU.EDU> sabbagh@acf5.UUCP () writes: > >I would like to hear more about your efforts. In particular, how do you >handle the problem of not knowing how long a word defintion will be usin >dynamic memory? At present my policy is that I should only allocate as much memory as is needed. I use adjustable arrays for just about everything internal, including the stacks. Thus if a stack overflows I can query the user if he wants to grow it. When compiling a word, I begin with an array of some default size. If that overflows, I reallocate to a larger one. When done I reallocate to just the amount being used. If errors occur durring a compile, I free the whole array. The only problem with dynamic (de)allocation is the potential for memory fragmentation. I am not sure how much of a problem this will be in practice? For now, I don't worry about it, and just let the system memory manager do what it wants. There are other more noticeble changes as well. One can only 'forget' individual words and arrays, rather than a word and all that follows it in memory. ',' is not useful, so I have found other (better 8^) uses for the symbol. -- Bill <bouma@cs.purdue.edu> || ...!purdue!bouma
toma@tekgvs.LABS.TEK.COM (Tom Almy) (11/11/89)
This may sound crazy, but anyone interested in a dynamic memory managed Forth should look at Smalltalk (particularly the book "Smalltalk-80 The Language and It's Implementation"). Once you clear away the window dressing (pun intended) you find a token thread interpreted stack machine with dynamic memory management of objects (and *everything* in Smalltalk is an object). I spent a year of my life porting Smalltalk-80 to an 80386 and the whole time I felt like I was working on a bloated Forth (The "kernel", consisting of the interpreter with its primitives is >64k, but the code threads are very compact -- more so than Forth). Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply