> On Jan 16, 2024, at 6:52 AM, Rodney Brown via cctalk <cctalk@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
