Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!bouma From: bouma@cs.purdue.EDU (William J. Bouma) Newsgroups: comp.lang.forth Subject: Re: Forth Implementation Question Summary: say what? Message-ID: <7990@medusa.cs.purdue.edu> Date: 16 Sep 89 00:26:34 GMT References: <1715@thumper.bellcore.com> <7972@medusa.cs.purdue.edu> <17623@bellcore.bellcore.com> Organization: Department of Computer Science, Purdue University Lines: 51 In article <17623@bellcore.bellcore.com> sdh@wind.UUCP (Stephen D Hawley) writes: >In article <7972@medusa.cs.purdue.edu> bouma@cs.purdue.EDU (William J. Bouma) writes: >> Why? You mention two features that this scheme would facilitate. >> One is forgetting just a word rather than a word and what follows >> in memory. The other is producing an application without unused >> code. But you can get both of these advantages in a normal forth >> without dynamic code movement. All you need is a compaction routine >> similar to a garbage collector in lisp. > >You can't "just foget all the words that aren't used". Forget will eliminate >everything defined after as well. What if you want to forget something in the >middle? You're screwed. And what is stopping me? It is trivial to write 'forget' so that it just eliminates one word from the dictionary, and frees just its memory! Sure this leaves chunks of unused memory interspersed with valid forth junk, but that is where compaction comes in. > Compaction is also unsafe - you have to adjust >the addresses of all the everything you move. You have to write a garbage >collector. These are notoriously slow techniques. If you generate code that >is threaded through JSR's and may include inline code, this gets harder. Less >error prone? I think not. Ask anyone who has implemented LISP (like me, for >example), just how free of errors garbage collection routines are. Don't tell me that just because you personally could not write an error free garbage collector that they don't work! Yes, they can be slow, but GC only happens when memory has apparently run out. This should not happen very often. It seems you want to adjust addresses on the fly, fine. All I am saying is that you can wait until you need to, then adjust the addresses. >Zipping through memory, enlarging code space is not safe. What if the segment >gets swapped out and swapped in somewhere else? This only works if you have >virtual memory, which I assure you, the Mac does not have. How can the mac swap memory around without maintaing virtual addresses? Could you explain more clearly exactly what it is the mac does about memory management? >Effectively, I would like to eliminate any possibility of compile-time >segmentation faults. This, I feel is a bigger win than "smaller is better". Perhaps I will understand what you mean here after you clarify how the mac handles segments? >Thanks for the input. I guess I wasn't very clear about the target system. You still aren't clear, at least to me. -- Bill || ...!purdue!bouma