Re: CPUs and Forth

[Greg Alexander <galexand@xxxxxxx>]

<snip>
>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.

One thing I like about the ShBoom is that its stack has automatic overflow
handling.  Now this is the sort of thing that you would say a Machine
Forth programmer doesn't really need.  I would agree.  But it makes it
extremely easy to efficiently implement an ANS Forth on top of it, I
think.  When implementing a traditional high-level Forth on the P21 you
pretty much have to use the stack only as a register, not as the main
user-level stack.  Therefore ANS code on the x21 is going to be 10x bigger
and slower than machine code on the x21.  On the ShBoom, Machine Forth may
not be as sexy, but at least you can implement the ANS Forth easily and
without a necessary huge speed loss.  I'm not saying this as a defense of
this tactic: it's certainly not the tactic I intend to use (I got my
P21!), but it's a very popular tactic and it's something that has made the
ShBoom a lot more palatable for some people.  If they fall in love with
the PTSC1000 that is not the same as falling in love with the P21, but
it's a lot better than falling in love with the m68k!!

>> 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.

I think it's great because it gets the real advantages of VLIW, except
that it's not very large.  We're not running 128 or 256-byte buses all
over our 5-layer PCBs just to fetch an instruction packet in a single
cycle!

<snip>
>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.

Now I hate to be critical because I agree 100% with what you're saying
here -- a lot of people will immediately dismiss approaches based around
simplicity because of fear and ignorance.  I've seen it a lot in all walks
of life.  But by constantly focusing on these closed-minded people I think
you're wasting time as much as they are.  I love to bash them too but I
don't see a single post by you here where you aren't mentioning these
people.  You've got a small group of strong supporters here (even me), and
it may be best to try to expand that group rather than trying to focus on
the borders of that group and the rest of the world.  It's kind of
bothersome, however, about the number of people here who are all "Why
don't you put a cache on it?" or "I can't use that at all unless it's
32-bits," etc., but if I were you I'd just ignore them.  They aren't going
to learn anything here unless by dumb luck so trying to lecture at them
won't do much good.

>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.

I actually strongly dislike the benchmark world.  I haven't seen your
benchmarks and I'm actually rather glad of this fact.  Yeah there are some
representative programs, but when most PC people hear the word benchmark
they think "WinStone 98" or something -- huge bloated benchmarks targetted
at C, intended to test who knows what, and definitely not the sort of
problems that I want a computer to be good at!  To me it is much more
important that I can have this low-power portable processor (you cannot
really call anything with more than 10M transistors portable because you
will be constantly recharging your battery!) that has an instruction set
that I can easily implement a comfortable FORTH in without feeling queasy
about it (implementing FORTH on x86 makes me uncomfortable because the
most simple implementations generally fail to make use of a lot of x86
features, so I know that not only am I going to get comparatively bad
performance, but in FORTH I /know/ that all this nastiness is going on
under the hood to adapt my code to the x86 and I simply don't want to have
play any role in such a system).  Code compactness is also very important
to me.  I can implement a slow threaded FORTH on the 8051, but if I try to
implement a native-code FORTH, it still won't be very fast and I will have
all sorts of code bloat.  But I'm confident that if I buy a single 32k
SRAM that will be sufficient for my FORTH system on the P21.  That it can
execute 80MIPS means a lot to me -- it means that the thing is ludicrous
fast (on any other chip with this power consumption, I would get maybe 1
MIP and I would be spending 5 cycles to do anything at all) so I won't
need to even think about speed in most situations.  So I will focus on
keeping the code small and simple, and speed can be a secondary concern
(and I won't be saying "no, I can't do that, I'd need to spend a year
hacking assembly to implement that algorithm on this chip."  I'm confident
that a comfortable FORTH environment on the P21 could run a chess
acceptably fast, whereas on the HP calculator, for example, the chess I
used was fairly slow and it was only playable at all because the author
had spent a month hacking raw assembly.

>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.

On the one hand it may have made a lot of people with shutters hanging
over their eyes to automatically pull the string that lets the shutters
close, but for people like me, that means a lot.  I wouldn't give a damn
about x21 if I hadn't been so intrigued when reading about it the first
time around, and most of that intrigue was a simple reaffirmation of my
belief "if you cut out the fat, any one man can do anything with a
computer that MS would use an army of programmers for."

>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.

I'm going to disagree in a small way here: I think that no cache is an
essential feature of MISC.  I work for a professor who is a big fan of
"functional programming" and spends most of his time ranting about how bad
C is at optimizing recursion because the compiler authors have wasted
several decades trying to get loops fast.  We're trying ot popularize a
recursive matrix layout that encourages natural locality (if you have it
row-major then column strides will be bad for the cache, etc.).  The nice
thing about this format is that the recursive code to work with it is
quite simple.  Hoever, the programs we've written are very complicated.
We have two versions of each of the core functions because the order of
accesses matters to the cache (we have an 'up' verson and a 'down' version
to traverse the data in an alternating order).  Further complexity is
introduced by manually making some data global that shouldn't be global
from a functional programmer's viewpoint because we're always worried
about C function call overhead.  We've unfolded the basecase of the
recursion into about 100 lines of code to exploit superscalar pipelined
optimization.  We've spent days puzzling over questions like "Why does it
superscalar-schedule this code if it's in a for loop, but if it's just
straight line code, it needs us to make this variable static and blah
blah."  We've spent days making tiny changes throughout the code, then
rerunning with SGI's C compiler to see if it will optimize this code or
that code better, and then we had to undo a lot of that when we discovered
that Sun's compiler optimizes code totally differently.  Usually I
wouldn't bother with such tuning but whether or not the compiler will
optimize for superscalar performance can easily be an order of magnitude
speed up right there.  I spent about two days messing around because SGI's
fork() system call got a lot slower in the new version.  The code ran, I
guess, so they can still call C portable, but simply porting from one
version of IRIX to another resulted in a 4x slowdown.
	In other words, I'd never try to do anything "for fun" on a MISC
chip with: pipelining, superscalar optimization, or cache.  I respect the
work that the prof is interested in -- he's being practical about this
considering his environment.  But I find myself asking again and again,
"why can't we just redesign the hardware so that all code executes fast
and instead of using crazy algorithms we could just do caching
explicitly."  His big thing is trying to make it into code that he knows
the compiler will automatically optimize and he's trying to push compiler
writers to optimize recursion.  I'd rather just write what I mean.
	I think it is inherent in any reasonably simple system that there
is no cache, etc.  Of course, this whole 20-bit limitation thing and
Chuck's funky input/output devices, that's just fooey to me.  I don't care
at all.  My own input device is going to be pretty zany on its own and I'm
seriously contemplating a new style of FORTH user interface that will be
better for the extremely small display I'll probably end up with.

<snip>
>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.

Actually, there is the joke that goes something like this:
Windows is a 32-bit front-end
on a 16-bit hack
for an 8-bit processor
...something about 4-bit...
made by a 2-bit company
without 1-bit of sense.

<snip>
>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.)

I would disagree with this also.  You can implement chips that embody MISC
ideals on PGA, but the current state of the art demands that you abandon
MISC ideals during development of said chip, so effectively to be really
MISCy about it you have to avoid PGA.  Though a lot of PALs are easy to
program without proprietary crappy software, so there is a programmable
logic option for really MISCy people.  It shouldn't take more than a
handful of small PALs to build a good forth chip.

>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.)

heh, I was planning on using SRAM boot since the cost of keeping such a
low-power design running all the time is so low...but PCs are definitely
ROM-boot only.  You may think you're booting off a hard disk, but I've
never met a PC where you waited less than 5 seconds for the BIOS to scroll
by.

>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.)

What spacecraft were you talking about earlier, btw?  I found pioneer 9 &
10 and voyager 1 & 2 left the planetary solar system on NASA's website but
they don't give many technical details about the things.

>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.)

That was really funny to me.  I went onto comp.arch.fpga a few months ago
and explained to them that hardware is complicated, but not too
complicated for a determined software folk.  They assumed that when I
refered to Chuck Moore that I was making things up and that I would never
be able to recreate their VHDL synthesis software, completely ignoring my
point that I didn't want VHDL synthesis software.  It sounds like I'm
ranting: I am...but as a counterpoint there were about half the people
there bashing me (the worst actually worked at Xilinx) and about half the
people there saying "Now I'm not certain this kid can do this, but there's
no inherent reason he couldn't."  You shouldn't give up on whole groups so
quickly!  The assholes were a vocal minority but a lot of people listened
to what I said -- even citing open-source projects that do a lot of the
work involved in FPGA design, everything short of actually generating the
bitstream to program a real devnice.

>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"

I think that some of the people who come onto this list and say "man, MISC
ROCKS!!...now add a cache and a 32-bit bus so it can actually be
useful...while you're at it add these three instructions and an
MMX-compatable FPU!" can come across as 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.  

I think that's teh problem with the ANS standard.  When I wanted to
implement a very very simple front-end to an assembler to give it
FORTH-like syntax in a [successful] attempt to get the first 10x I didn't
even consider ANS at all -- it wasn't even at all in my mind.  I didn't
even consider calling it FORTH.  I simply called it "gf" with the
assumption that anyone who actually saw it would connect the dots and call
it "Greg's Forth."  I think I'm lucky that I learned FORTH from a very
out-dated webpage on forth.org instead of the ANS standard (which I've
tried to read, but found unintelligible).  I saw that first 10x in plain
view without any attempt at trying to represent a large group of FORTH
users.  They were just showing "well here's our stack notation, and here's
some syntax for defining CODE words...isn't that simple?" and ignored all
the complex issues, allowing me to chose my own solutions for them, some
of which have been very stupid, but always very simple.
	hahah, on the issue of simple.  I explained to a C head that C
function call overhead is really really huge.  He assumed I was some mad
performance freak going after the 10% speedup you could maybe get with a
very strong inlining C compiler.  I don't think he had any idea that I was
actually not after performance, I was after cleanliness.  I then went
ahead and implemented a FORTH system that was painfully slow compared to
his C system because I had + as just another word, rather than attempting
to convert it to an ADD opcode or whatever.  Had I done that in C, I would
have had a system unacceptably slow, but doing something like that in
near-zero-call-overhead FORTH resulted in non-optimal performance, but it
was well within the limits of what I would call usable, and all with the
advantage that I wrote my compiler and library in an afternoon, whereas he
would spend an entire afternoon just to download the C library source,
it's so big.

>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.  

Reminds me of when I thought of FORTH as a scripting language because it
was so easy to implement a FORTH interpretter in C.  I had this C program
where I wanted pattern matching (tape backup software) and I implemented a
very simple FORTH for it, then I wrote the program I needed (without using
real pattern matching -- if you're writing in FORTH you don't mind your
list of files to back up being imperative rather than pattern-matching),
and it was very simple and just as fast and didn't involve anything i felt
really uncomfortable about (such as implementing a proper greedy regex
parser).  I think that you shouldn't bash such systems because they /do/
get the first 10x.

>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.

On the one hand I'm annoyed that they are so negative towards us.  On the
other hand, it doesn't really matter.  I got a lot of harsh words with my
message of simplicity on comp.arch.fpga, but nobody drove over here and
shot at my house.  And in a very real sense FORTH /is/ a religion.  Not a
religion like Fortran where backwards-portability and understandability by
idiots who have know intention of understanding.  Not a religion like
Christianity where your greatness is measured by how blind your faith is.
With FORTH our religion values not control over people, but control over
the computer.  We don't value blind faith, we value constant open
questioning -- I know that if I, personally, find another system this
ridiculously simple, I will seriously consider converting...I'm not any
more loyal to FORTH now than I was to C back then, I'm still waiting for
something better to come along (though I have enough experience now that
I'm not so confident that such will happen).  We have an aesthetic sense
very closely tied to minimalism, simplicity.  Aesthetic sense has long
been a religious issue -- many eastern religions value understanding and
simplicity in life, whereas many western religions value complicated
hierarchical governments and blind faith.  We are talking very much
about religious issues -- just because we aren't shooting homosexuals or
abortion doctors doesn't mean we aren't a religion -- not all religion has
the same dark history of Christianity or Islam.