Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site umn-cs.UUCP
Path: utzoo!linus!security!genrad!grkermit!masscomp!clyde!floyd!harpo!eagle!mhuxl!ihnp4!stolaf!umn-cs!smith
From: smith@umn-cs.UUCP
Newsgroups: net.lang.forth
Subject: Re: Portable Forth for Unix - (nf)
Message-ID: <398@umn-cs.UUCP>
Date: Wed, 18-Jan-84 21:02:52 EST
Article-I.D.: umn-cs.398
Posted: Wed Jan 18 21:02:52 1984
Date-Received: Sat, 21-Jan-84 06:58:58 EST
Sender: notes@umn-cs.UUCP
Organization: Computer Science Dept., U of Minn, Mpls, MN
Lines: 48

#R:bunker:-32100:umn-cs:14200006:000:1982
umn-cs!smith    Jan 18 18:49:00 1984

A Portable Forth Kernel?  Hmmm.

My first impression is to say "Nonsense!" but then, maybe not.  Discussing
such a thing might drag this newsgroup out of the doldrums...

Building a 'portable' kernel may be a real pain.  I see several problems,
none impossible, but still problems:

1. Forth dictionary storage is completely unstructured, so you'll need
   to do typeless references to it.  I wouldn't want to use Pascal, even
   with variant records.

2. The inner interpreter ("address interpreter") would be a sight to behold
   in any high level language.  It wouldn't run very fast, either.
   Forget Pascal, since you'll be manipulating addresses of procedures.
   (Ooooh noooo, Mr. Wirth!)

3. The code might compile a kernel that works over a broad range of
   machines, but I'd expect there to be problems porting applications,
   especially between 16 and 32 bit machines.

4. How many of the 'classical' elements of Forth would be lost?  I've talked
   to people who have tried to build Forth kernels in Fortran, etc, and
   they generally discard the traditional structure of Forth for something
   that better fits the language they're writing it in.  Also, I've never
   spoken to anyone who's actually used one of these Forths, only people
   who are trying to build one.
   
   I'm not saying that Forth text always (or even often) depends on
   such things as the location of the dictionary header, but in Forth
   you usually rely on such facts during debugging.

5. My definition of a 'real' Forth system is one that can support
   some sort of assembler.  This knocks out those high level languages
   that make it impossible to branch into a data area.  Does anyone think
   it can be done in C?  Maybe with the inner interpreter written in
   assembly language?  Or a special function branch(addr) written in
   assembler? (be sure to clean your stack when you're done...)

Enough for now.  Comments?

Rick.
[smith.umn-cs@CSNet-Relay]
 [...ihnp4!umn-cs!smith]