Re: CPUs and Forth

[Jeff Fox <fox@xxxxxxxxxxxxxxxxxxx>]

Dear MISC readers:

Stephen Pelc wrote some nice explanations about the myth 
that Forth has some intrensic problem with readability.
It is nice to see strong logical arguments in this regard.

> a) A successful stack machine must be able to run C
> efficiently and must be supplied with a C compiler.

This may or may not be the case.  Success really depends
on getting a foot up into production in a product.  This
requires vision, funding, and producing a product that
sells.  Success may mean different things to different
people.  To some it may mean replacing Intel processors in
PCs.  To others it might simply mean being used in some
products.

It is true that if you are a die hard C programmer that you
will define a chip's "success" in terms of C.  But as I say
it depends on the goal.  Our goal was never to make the chip
look good to C.  That requires going in very different directions
that what we chose for my chip.

To be used in a product a chip requires software development.
It does seem to be true that most companies will dismiss any
technology that is not focused on C.  But the simple fact
is that you don't need to support everything people have on
a desktop to support embedded products.

MPE obviously can deliver products using Forth for the 
software.  They are not the only shop in the world capable
of this.  Of course Chuck's vision of Forth is very different
than the one promoted by the major vendors.  In order to get
acceptance of commerical products they must in general look 
and work like everything else.  Most people are just looking
for what is safe, ie what everyone else is doing.  Most people
are not confident enough in their own understand to set out in
a direction that is not the same as everyone else.

I actually think that the lack of confidence in Forth has 
been the major problem with Forth chips.  The RTX was a
killer Forth chip but Harris put their major push behind
C and it seems that C programmers often have a great deal
of hostility toward Forth.  I recall when I first heard
Mitch Bradley do a presentation on Open Boot he never
once mentioned the word Forth.  He was asked why he would
talk about a version for Forth for an hour and a half
without ever using the word Forth.  

He said that when he first gave presentations about Open Boot
he used the word "Forth" and noticed that after the boos and
cat calls died down that he had lost most of the audience.
He learned not to upset the 'C' programmers by using the
F word.  He learned it was better to not get booed out of
the room by the predujudice C programmers have toward Forth.
Much of this comes from thier missunderstand but certainly
some of it is just because it appears to be a threat to them
that they would rather dismiss as a cult than fairly consider.

IMHO being efficient at 'C' is essentially a style or
fashion issue since 'C' isn't the only programming language.
It is much like in the old days when people would say that
a given computer has superior price, performance, support,
etc. but could not be purchased because it didn't have the
correct 3 letters printed on the front.  Most people only
want to do what is safe even if all other indications are
that there is possibly a better choice.  Sure I could save
the company millions, but I would be putting my neck on the
line by going against corporate culture which is to accept
... without questions.  When you cater to that market all
you can do is give them what everyone else does.

> The hardware extensions required to run C efficiently
> on a stack machine are not ver great.
>
> b) For the same CPU instruction rate (however that is
> measured), the diffence in program execution rate of Forth
> and C will not differ much, regardless of whether this
> is a stack machine or a register/RISC/CISC machine. The

This is very very dependent on the design of the stack machine
and the code in question. Phil Koopman's book covers this very 
well and goes into details about the different approaches to 
stack machines and the inherent problems with C and stack machines.   

Sure you can start with a C machine and make it into a stack machine. 
Then you can say that there isn't much difference.  There isn't
much different if you go in that direction.

On the other hand you can also go in a completely different
direction. You can leave out the multi-stage pipelining,
cache controller, etc. and much of the other hardware if you
are not starting with the C machine concept and adding
stuff to make a stack machine.  You can also leave out much
of what is required for ANS Forth if you go in that direction.
Unlike ANS, Chuck has not been focused on supporting the many
details needed to support C.

MISC is the best example.  The most widely used C compiler states 
right up front in a disclaimer that a target machine 
requires four characteristics to get good performance:

1. lots of general purpose registers
2. byte addressing 
3. a word size of a multiple of 8 bits
4. sufficient memory addressing to hold the complete compiler 
   and GNU (>4MB)

It states that if a target machine does not have these four
characteristics that GNU will not support the machine well.

Then look at what Chuck did with MISC:

1. no general purpose registers, let alone lots.  Chuck did
this because he took the idea of zero operand to the extreme.

2. word addressing.  This simplifed hardware, made the Forth
faster and easier.  Like the NOVIX's word addressing it makes
a common word in Forth go away, CELLS.  CELLS becomes 1 *
which is the same as nothing.  It sure speeds up Forth to
make CELLS compile to nothing.  

3. 20 bit bus. Again Chuck new what his software looked like. 
no problem for him.  His machine has 20 or 21 bits, not a multiple 
of 8.  He doesn't even use 8 bit characters.

4. 20 (and 1/2) bits of addressing gives you many times more
memory than 16 bit systems at a tiny increase in price.  It
matched the requirements for Chuck's VLSI CAD software very
well.  However it doesn't give you 4MB of flat space so it
looks too small to be useful in 'C'.  Meanwhile Chuck claims
that most programs will fit in 1K so 1M is a huge memory
space from Chuck's point of view.  Other people need a meg
for a compiler, he needs a k.  Other people need hundreds of
megs of code to do VLSI CAD, he does it with 20k.  From the
perspective of software that Chuck has his hardware is quite
large.

What this says is that Chuck has taken a direction almost
opposite to that of C and most of the world.  It is very
very hard to understand what he is doing if you try to 
map it onto what everyone else is doing.  Chuck has clearly
headed in the opposite direction and is facing almost
an opposite set of constraints that the C folks.

One might say that there is little difference between a stack
machine and a RISC or CISC design. This is true for some
designs but the antithesis is true for Chuck's recent
designs.

An excellent example is the ShBoom.  Chuck did ShBoom in 1988,
word addressing, etc.   After the design ended up at Patriot
they had a team of engineers who spend ten years making the 
chip ten times bigger so that it could efficiently support
C and Java.  Converting it from a Forth chip to a C and Java
chip was a big project.

Meanwhile at the same time Chuck continued to explore the
ideas from ShBoom in the MISC chips.  He was interested in
going the VLSI route because the price (manufacture) and
performance ratio is 100 to 1000 times better than with
a generic PGA approach.

The changes to ShBoom made it look good to a C or Java programmer.  
However if you ask the design engineers who had more experience with 
Forth they may tell you that those same changes really messed
up the chip for Forth.  They make all sorts of things that were
simple in Forth before very complicated.  One of the engineers
refered to these changes as "brain damage."  I think to understand
why this is so requires understanding the chip before and
after the changes and from a Forth software point of view.  As
I say the changes look good and minimal to a C or Java programmer
but to a Forth programmer (with a perspective similar to Chucks) it 
is a completely different chip. It is much more expensive, much more
complicated and and much more difficult to use for Forth.  A Forth
programmer with a perspective more like C (or ANS) might see the
changes as useful to their idea of Forth in C or whatever.

> on chip stacks of the stack machine offer internal
> parallelism in the same way as the CISC/RISC register
> file. I'm leaving out any discussion of VLIW.

Yes, Chuck has taken a different approach to on-chip
parallism.  The sequence for decoding and executing is
highly parallel.  The multiple instructions per word is
also a form of parallelism sort of like VLIW.

But VLIW is another technology going in an almost opposite
direction to the direction Chuck is going.  I realize that
by making instructions only 5 bits a 20 bit word can
contain multiple instructions so it has a little in common
with VLIW but VLIW is one of the most expensive approaches
to hardware design.

> c) Currently, peak CPU bandwidth (1GHz or so) is running
> at about 10 times the memory bandwidth (100Mhz or so),
> so memory interfae and code density are limiting
> factors, which is where MISC comes in. 

Yes.  Of course MIPS ratings and benchmarks can be very
deceptive.  I have read a lot of complaints from users that
they have systems that advertize that they can get 4
instructions per clock cycle and the vendors have lots of
examples of benchmarks that do this.  But they complain
that on their real world code they get more like 1 instruction
per 4 memory clocks not the other way around.  Despite the
investment in millions of transistors to speed things up
the fact that real programs are bigger than cache and that
large data sets slow things down to the speed of random
access to memory regardless.

These same limitations apply to MISC but even more so.  The
lack of cache doesn't hide the problem with benchmarks that
are not characteristic of real code so it is even more
visible.  It depends a lot on the problem being coded.  Some
problems do require expensive hardware but not all problems.

The main issue with MISC is one of diminishing returns.  The
first simulated benchmark comparisons to expensive chips 
indicated that we could get 70 to 80% the performance for
1/100 to 1/1000 the investment in hardware.  But that is
because we are not including the expensive stuff needed to
support resource rich programming environments or deal with
the expensive problems.

When I did the first simulations on P20 I was quite suprised
that the MIPS ratings were always inversely proportional
to performance for a given chip.  It took me quite a while
to grasp the concept. Then it became very clear.  The most
efficient code will not have the highest mips rating and
the it is easy to get a high mips rating on inefficient code.
MIPS discussions are generally very deceptive because of this.

> The reason for this is that a stack machine usually
> has to execute the stack operations, whereas in a
> RISC/CISC architecture, these are replaced by indexed
> loads with a single stack adjustment per block. The
> stack machine instructions are 0-address.

Yes.  Exactly.  It is the ability to treat stacks as arrays,
to index into structures in stack space efficiently is where
much of the expense comes from.  On the MISC chips the
stack interface is really tiny.  On RISC/CISC chips that
provide a variety of mechanisms and addressing modes to
make it easy to mix up the concept of stacks with arrays
is part of what makes those chips expensive and complex.
To support the sophistication of C you need to move much of
the work and expense into the hardware.
 
> The real point about MISC is that it uses a minimal
> set of very short opcodes, which should give very good
> code density. 

The numbers which we saw consistently were that native
code was 10 to 100 times smaller than threaded Forth
versions.  The threaded Forth was considerably smaller
than the equivalent C.  This is part of why Chuck maintains
that if it isn't 100x smaller than C that it isn't Forth.
(I guess that might also mean that a Forth in C really isn't
a Forth.  Since it is also C it can't be 100x smaller than C.

> Since the world is now communication
> oriented, 

As Chuck puts it, since most applications today are mostly about moving
data (communication oriented) and formating the display they
require little math and almost no FP.  This is why he focused
more on putting cheap gigabit communcation coprocessors on-chip and
why the instruction set looks the way it does on his chips.

> my Forth CPU would be 32 bit and byte
> addressed. However, my point here is that MISC is
> an interesting slant on CPU design.

Yes.  The tiny instructions and zero operand architecture
provide an unusual design.  Of course the 20 bitness is not
an inherent characterist of MISC chips!  

Focusing on the 20 bit issue is like focusing on the number 
of keys Chuck used to use or the hardware used to drive the 
bus. Those are not intrinsic propteries of MISC although they
are the ones that distract people from the real value
of the design and approach.

I don't know how many times I have said this, or how many
times I will say it.  We chose to prototype the first chips
in 20 bit size to save a few hundred thousand dollars (or more) 
in development costs.  Chuck has said before that converting
from 20 bits to 32 bits takes a few days.  He has done it
before.  It will require paying for a few more pins and
they do cost about $.01 each in production.  Not a big
factor at that stage.

I do think it is somewhat of a waste for a lot of people
who are capable of writing software to spend so many years
debating hardware design tradeoffs when they only have
experience with software.  It seems like a waste when 
writing programs for this unusual architecture is so
education and instructive.  It is really easy and makes
the whole approach make sense.  If one haven't learned
how wonderfully easy it is to program in this modern
style of Forth one sees problems where they don't exist.

When it is so easy to write good code on these machines
that could be made for almost nothing it seems like a
waste that rather than try it so many people have spent
ten years talking about programming in C or ANS Forth
and so little time actually programming this stuff. They
seem to think it is going to be hard, and maybe it will
be if they try to force the wrong software ideas on it.

I have said "Try it, you might like it."  But a number of
the ANS Forth experts have said that they don't consider
it Forth, they will refuse to even look at examples of
Chuck's code if they are posted, they will not consider 
any of the ideas or even listen to them or look at them.

When we posted results people questioned them.  They said,
"Where are the benchmarks?"  When we published the benchmarks
they declared that they would not even look at them.  They
only want to discuss they number of keys Chuck had on his
keyboard ten years ago, the number of bits on the bus,
or the issues of bus design and cross compiler design or
other side tracking issues.

Some of the these same people, who refuse to look at the
real information, do occasionally post information about
our chips or software. (I am not talking about Stephen here,
I think he is well informed and correct from his point of
view.)  I am just saying that some of the people who state
that they are proud of ignoring whatever information we
publish about our project also feel they are helping people
by providing alternate explanations.  Unfortunately they
often have no technical information on which to base their
arguments because they have intentionally avoided learning
the actual facts and they just insert their assumptions. 
This results in some people trying to balance the missinformation
against the information from the people doing the work.  It does
confuse a lot of people.

I think the biggest mistake was that Chuck tried to explain 
VLSI CAD to people.  They got the issues of his chips and
VLSI design all mixed up because of Chuck talking about the
details of what he was doing at the hardware level.  He gave
many people the impression years ago that programming these
chips was 100 times more complicated than it really is.  After
a decade it remains a big problem.  Look at all the wasted
bandwidth that still goes no in this mail list discussing the way 
Chuck explained hardware design tradeoff issues ten years ago as 
if they had a noticable effect on software.

My point is that anyone who wrote an Intel compiler that ran
on a Moto chip, the other way around, or even just ported an
application from a Moto chip to an Intel chip or visa versa
has had to deal with the fact that they use a different
hardware representation on the bus.  Not a big issue. It
takes a couple of minutes to deal with.  It really doesn't
require ten years of discussions about how hardware details
should be "completely transparent" to a programmer!  People
could make more productive use of their time than that.

We all know the myths that circulate about Forth.  Someone
who never learned to program in Forth can't even read
their own code will say that Forth is unreadable.  Someone
who has never written anything except trivial code snippets
in Forth will say that Forth is only good for that.  We know
these are Forth myths if our experience goes beyond the level
of those people.

We also have a set of myths that circulate about MISC chips.
Someone who has never tried programming them will say that
they are difficult to program.  Despite the fact that Chuck
has done 8 bit, 16 bit, 20 bit, and 32 bit designs people
will say that MISC means 20 bits.  Despite the fact that
Chuck has a menu from which one can pick features people
often state that the choices made for a specific chip are 
the only choices possible.

People who have never worked with this stuff will helpfully
inform others that the issues are things like 20 bit, no
cache, a particular type of memory bus, a particular set
of coprocessors as the definition of MISC.  Absolutely not!
These are issues for a particular chip, not the 
approach.  The width of the bus, the particular choice of
instructions, the design of the memory interface, the number
of memory intefaces, whether stacks are in memory or on chip,
whether stacks can be indexed or treated as an array, the
details of the coprocessors etc. are all specific to individual
chips not to MISC.

Now if people want to talk about the specifics of a particular
chip, such as F21d, then it will have specific characteristics.
But for some reason some people have posted that since one of the
MISC chips had ... that all MISC chips must by defintion have ...

Since the 8088 had an 8 bit bus should we assume that Intel
was incapable of making a chip with more than 8 bits?  When
people discuss the pentium we don't have people claiming it
is only an 8 bit chip but we get that sort of thing all the 
time in MISC.

Chuck has a menu.  It is like a menu in a restraunt.  Even if
there are 100 choices on the menu in the restraunt you will only
order one of them when you go in for a meal.  Wouldn't it be
silly if a restraunt critic interviewed you when you left and
asked you what you ordered and then wrote an article about the
restraunt that said that it was no good because there was only
one choice on the menu.  But we see that all the time in MISC.

It is really silly but we still see it all the time.  Some of these
myths that get repeated all the time are:

MISC is 20 bits.  (false, Chuck has done 8,16,20,and 32 bit designs)
MISC is VLSI only. (false, things have been done in PGA also etc.)
MISC is word addressing only. (false, just a choice)
MISC means stacks in registers.  (false, just a choice)
MISC means no stacks in memory.  (false, just a choice)
MISC means one memory bus. (false, just a choice)
MISC means small designs.  (false, a 16 bit bus gives less addressing
   than a 20 bit, and 20 gives less than 32, and 32 gives less than
   64. Do you want a 128 bit address bus?  Just a choice.)
MISC means ROM boot.  (the way things boot is your choice.)
MISC means DRAM, SRAM, SDRAM, or some other memory bus.  (the memory
   bus is just one of the design choices)
MISC means low res video only.  (false, the analog or video coprocessors
   may be designed for whatever you require.  Because P21 used only
   one pin for composite was a limitation on _that_ chip.)
MISC means NTSC video only.  (false. even P21 can generate PAL it is
   just a matter of software.  F21 has three pins for RGB.  Other
   designs have been done with other video variations.)
MISC mainly means cheap. (false. The extremely low power, high
   performance, and rugged environmental operating characteristics
   mean that MISC chips have been considered for the most expensive
   types of applications like spacecraft.)
MISC means a single CPU. (false, F21 is an example of a MISC chip with
   hardware support for SMP)
MISC means a fixed insruction set. (false,  I made changes to the 
   F21 instruction set.)
MISC is weak on C.  (Well, maybe this is not a myth, just backwards.
   perhaps it would be better to say that C is weak on MISC!)
The main thing about MISC is the CPU. (false, it is the ballance between
   on-chip specialized coprocessors and a general purpose Forth CPU.)
MISC hardware is complicated.  (MISC hardware is far less complicated
   than most hardware.  The problem is that hardware is complicated
   to software folks.)
ANS Forth is the real Forth.  (ask the man who invented Forth ;-)
MISC needs C.  (programmers who only understand C need C.)

And of course we all put up with such absurd insults that they
cannot even be called myths such as:

Forth is a cult, Forth is a sect, Forth is a religion
Forth high-priests are trying to "program" people
Forth is for people who can't read or write code
Forth is just "wrong" ;-)
Forth isn't really a programming language because it has no syntax
People who have read or considered Chuck's essays about Forth or
   hardware are nothing more than "parrots" and "mindless sicophants"
We insulted them first by calling them "idoits" (for facing so many
  self imposed problems and being so unproductive)

Personally I think Chuck is the only person with the right to
use the plain term "Forth" for what he does.  IMHO, everyone else 
should say "My Forth" "This Forth" "Our Forth" etc. to clarify that 
they are talking about _a_ Forth for their niche not _all_ Forth.  

However Chuck does what I think other people should do and likes to 
use a qualifier when he uses the word Forth.  He will say "Machine 
Forth" or "Color Forth" for clarity. But unfortunately the majority 
of people have been working for hard to move "Forth" toward looking 
like everything else and many people now feel that "Standard Forth"
is really Forth even though it seems much closer to everything
else than to Forth to me.

It brings up a somewhat philosophical question.  If I write a
Forth in 'C' what do I have?  Is it Forth?  Isn't it also a
'C' program and therefore 'C'.  Is it half Forth and half 'C'?

I ask the same thing about a sort of thing about a meta-Forth 
definition standard. (ANS)  It certainly isn't Forth.  It is a
description of Forth, but also a description of half Forth
half 'C' or half Forth half Java or whatever.  It could apply
to some very convoluted things.  If I write a Cobol compiler
in 'C' that compiles a Prolog that compiles something else
that compiles a Forth compiler what do I have?  Forth?  Or is
it 20% C, 20% Cobol, 20% Prolog, 20% something else and 20%
Forth.  (or more likely 30% C, 25% Cobol, 23% Prolog, 21%
something else and 1% Forth.)

The point I am making is that we can't help but bring our
background with us.  From one person's point of view Forth is
a megabyte of 'C' code on top of many megabytes of OS code
written in 'C' and many megabytes of compiler written in 'C'.
From another person's point of view Forth is the bootom few
K that is the operating system and compiler.  

The first person might say, that it isn't really Forth unless
it is megabytes on top of megabytes of C.  It isn't really
Forth if it isn't written in 'C'. 

The second person might say it isn't Forth unless it is written 
in Forth and that it isn't Forth if it isn't providing the OS.  
Forth means really different things to different people.  

All that the majority of people know about Forth is what they
read in places like John Dvorak's column where he has said that
there has never been a decent program written in Forth because it
is a religion not a programming language.  Many people don't realize 
that he was getting paid to make outrageous jokes. At times he
can be very funny. ;-)

The problem is that some people don't realize that it is a joke.
In America calling someone a cultist is about as low as one can
go. There is nothing worse or more dangerous than cultists, that
is the meaning of the word. It carries the strongest of negative
connotations.  Send in the tanks and flame throwers, it doesn't
matter if there are children there, there are also cultists!  This
is the kind of rhetoric that encourages hate crimes.  I would have
never thought that computer software would be a target of religious
persecution.  Many people came to America to practice their religion
in peace without persecution.  Funny how programming a computer
can cause some people to tell others about your religion or that
you are really a cultist.  Who would have ever guessed that people
would behave like that?  Interesting phenomonon.

Jeff Fox