Path: utzoo!attcan!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: alternative
Keywords: Forth, 68000
Message-ID: <7972@medusa.cs.purdue.edu>
Date: 14 Sep 89 20:16:50 GMT
References: <1715@thumper.bellcore.com>
Organization: Department of Computer Science, Purdue University
Lines: 33

In article <1715@thumper.bellcore.com> sdh@thumper.bellcore.com (Retief of the CDT) writes:
>	I need some help pronto.  I'm writing a forth compiler for a 68000
>machine, and am trying to implement it in a way that doesn't require
>access to the contiguous address space of the machine.  In effect, when a
>word is compiled, it is shoved in a dynamically allocated block in a heap that
>is relocatable.  All function calls would be rerouted through a dispatcher
>that would located the handle of the code block, lock it down
>and execute it.  Upon return, it would unlock the block and return to the
>calling word.

      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.

>I realize that if I do the first it is no longer forth, but a warped hybrid.

      Well, any step away from the forth83 standard is a step in the 
      right direction!

>Please advise me on which approach I should take.  If you need more info,
>ask me and I'll post anything I've left out.

      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.
-- 
Bill <bouma@cs.purdue.edu>  ||  ...!purdue!bouma