Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!bellcore!wind!sdh
From: sdh@wind.bellcore.com (Stephen D Hawley)
Newsgroups: comp.lang.forth
Subject: Re: Forth Implementation Question
Keywords: Forth, 68000
Message-ID: <17623@bellcore.bellcore.com>
Date: 14 Sep 89 21:52:38 GMT
References: <1715@thumper.bellcore.com> <7972@medusa.cs.purdue.edu>
Reply-To: sdh@wind.UUCP (Stephen D Hawley)
Organization: Bellcore, Morristown, NJ
Lines: 60

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. To produce a minimal
>      application you just forget all the words that aren't used. Then
>      run the compaction to move the words and data blocks around to
>      eliminate the gaps of unused memory.
>      Just, are there any other advantages of your dynamic code movement?
>      Forth with compaction seems like it would be simpler to write and
>      less error prone than the scheme you have presented.

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.  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.

Forth is dangerous in a machine that does not have memory protection (such as
the macintosh).  FORTH words like , or HERE are villanous.  FORTH is modular
enough without letting you change the way the compiler works.  My scheme would
use a heap allocation system for the code blocks that is completely robust and
safe.  If you can't assume that addressing the entire memory space is a safe
practice, then the current paradigm of operation for FORTH is unsafe.
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 I make the compiler comletely solid?

Effectively, I would like to eliminate any possibility of compile-time
segmentation faults.  This, I feel is a bigger win than "smaller is better".

The advantage of dynamic code movement is that in a system with memory
allocated from a heap in 2 ways (relocatable and non-relocatable), you take
advantage of the system's own memory management by using relocatable blocks,
so that the heap doesn't get fragmented.

You can allocate one big block for code space, but how big is big?  If you
guess too big, you're being a hog.  You may not be able to run some things.
If you underestimate, you'll be thrashing with calls to realloc() to get more
space.

The advantage is that you only ever use as much space you need.

Thanks for the input.  I guess I wasn't very clear about the target system.
The reason is has to be safe in memory is the potential of trashing desk
accessories or (if running under the multifinder), other applications.

Steve Hawley
sdh@flash.bellcore.com
hawley@occs.oberlin.edu
hawley@cwru.edu
"Up is where you hang your hat."
	--Jim Blandy, computer scientist