16 Jan
2024
16 Jan
'24
7:04 a.m.
On Jan 16, 2024, at 6:52 AM, Rodney Brown via cctalk
<cctalk(a)classiccmp.org> wrote:
Forth was ported to an HP-2100 in 1972, by Elizabeth Rather, so had early
history on HP hardware, though from what I can it it was never a product
available from HP.
I don't know if Forth Inc ever supported Forth on HP machines.
Anthony Pepin provided a Forth to the HP3000 Contributed Library in
September 1982, though I think his looks like a virtual machine, I don't
remember trying it in the day.
Thanks to Gavin Scott's "system" and J. David Bryan's SIMH HP-3000
emulator,
I can look at it now.
As Anthony Pepin observed, Forth implementations at the time assumed a
von Neumann architecture. The HP 3000 with a Harvard architecture implying
read-only code with a different address space, needs more thought.
Is the HP implementation a derivative of FIG-FORTH? (FIG is "FORTH Interest
Group".) The PDP-11 FORTH available a bit later came from there. I don't know
the full timeline, FIG may have been later. That version was released by DEC as an
"Unsupported" program for RSTS.
FORTH by its nature actually fits well in Harvard architectures. While it's not quite
the same consideration, a number of implementations of it handle RAM/ROM or RAM/Flash
splits nicely.
Why Forth?
FORTH is compact and powerful, though a bit tricky to use. I did a lot of work with it at
DEC (the RSTS FORTH port is my work, as are several of the FORTH based utilities that
shipped with it). And in the past 6 months I've gotten back into it, using the very
nice "Zeptoforth" version for the Raspberry Pico and similar dirt-cheap
microcontrollers.
...
Assemblers in Forth seem to be a common thing, it would be possible to
assemble the Data space code with minor peephole optimization, and the necessary
translation from modifying the Next Data instruction variable to branches in the
code. That and the Dictionary entry could then be written out as an input file
for PATCH.PUB.SYS, allowing the interpreter to be extended without understanding
the USL format.
A key FORTH principle is extensibility. The normal implementation technique is that a
small set of "words" is implemented in assembly code, and then all the rest is
in FORTH. You can see this in PDP-11 FORTH -- while it's all one big assembler source
file, most of what's in it is FORTH compiled code written out as a sequence of
MACRO-11 statements. In Zeptoforth it's even more explicit: the assembler code is for
the "kernel" and you then feed it the FORTH source files for everything else to
give you the final product.
And FORTH applications can extend or adjust the language if they want. The RSTS dump
analyzer SDA is an example: it changes the FORTH interpreter from a 16-bit one to a 32-bit
one so PDP-11 physical addresses can be manipulated easily.
I've finally read some of Koopman, Philip (1989)
"Stack Computers: The New Wave" looked a little at his Harris RTX-2000 MS-DOS
Emulator source, and at
James Bowman "J1: a small Forth CPU Core for FPGAs".
Like the HP 3000, the Harris RTX-20[01]0 & the J1 are 16-bit machines with a
16-bit instruction width (soley for the Harris & J1).
Later FORTH implementations may be 32-bit native; the Pico one is, for example. The
original FORTH definition is 16 bit oriented but later on that was cleaned up; there is an
ANSI FORTH standard that's independent of word size.
It would be an amusing retrocomputing exercise to port FORTH to old architectures. It may
be a good fit for the B5500 (though FORTH requires two stacks, not the usual one). But
imagine your favorite classic architecture running FORTH...
paul