I see your point, though I think that the call becomes substantially
tougher in microcoded machines that have no explicit "%processor" mapping.
However, I'm sure that we'll all agree that we don't need to squander
additional bandwidth here to semantics!
Bill
At 08:37 PM 5/8/00 +0100, Tony Duell wrote:
ard(a)p850ug1.demon.co.uk (Tony Duell) wrote:
Perhaps a PERQ was not a LISP machine if hardware support for LISP and
supporting services such as garbage collection is your criteria, but a
Yes, I guess that is how I define a LISP machine. In much the same way,
I'd not call a Jupiter Ace (UK home micro, Z80 based, Forth in ROM) a
'forth machine'.
Hi
This is a hard call, I would call the Jupiter Ace a
Forth machine. It did have a Z80 heart but the interface
was the Forth interpreter. Even things like the NC4000
or RTX2000 that were considered a Forth engines had an
underlying assembly language that was easily formed into Forth.
Yes, that's the point. The Z80 is not really optimised to run Forth
(IMHO, the 6809 does better for this but anyway...). So while the Jupiter
Ace is a machine that runs forth, where the user interface is forth, etc,
it's not a 'forth machine'. I reserve that title for machines where there
is hardware support for features of the forth language (like 2 stacks,
threading, etc).
The problem is that if you're not careful, any computer could be called a
<foo> machine where <foo> is any language or operating environment that
you choose. And that rather makes '<foo> machine> meaningless.
The Jupiter Ace didn't have any specific
operations
or hardware to support Forth, other than the ROM. I guess,
if one uses this as a drawing line, it makes some sense.
I wonder how one could define the Canon Cat? Although,
it had Forth in ROM, it was an application machine.
Wouldn't one call it an application machine, even though
it have an underlying processor with Forth overlayed
on that and the application on top of that?
No. I'd call it a %processor based machine. That happens to run software
written in forth.
-tony