[NOSC] Chuck Moore website and new Forth chips

[Jeff Fox <fox@xxxxxxxxxxxxxxxxxxx>]

Mark Sandford wrote:
> This is true, I have also had a fair portion of career
> spent in parallel processing and the systems are
> generally designed to be 1000 workstations rather than
> 10,000 efficent processors.  

Oh, were it only a 10/1 ratio.  But the ratio is from
1000/1 to 10000/1.  So rather than compare 1 1000Mhz
workstation to 10 2400Mhz processors based on
transistor count, cost, or power consumption you
have to use somewhere between 1000/1 or 10000/1.  So
the equivalent of the 1000 workstation multiprocessor 
is a 1,000,000 or 10,000,000 node MISC design.  I
think it is really hard for people to really picture a
24 billion MIP computer very clearly.

But the whole idea is only possible with Chuck's
ideas on programming which came first.  Without
those ideas you need 1000x more of everything to do
trivial things like a printf.  Printf exposes
the antiquated and poor idea that everything
is a file.

> They have a full OS that
> takes multiple megabytes to handle communications, a
> big portion of which is getting "printf" statements
> from this processor out to a control console.  

Exactly.

Remember that Chuck's interest in hardware began
because he felt that that was the remaining problem.  
He had invented Forth and mastered it which allowed
him to write smaller, more efficient and faster
solutions and be more productive.  

Given that as he put it, "the software problem was
solved" the remaining problems mostly had to do
with the hardware causing most of the problems.
The hardware had started to fight us at every
turn.  What other people wanted to put into the
hardware to support the overhead they put into
their software made doing Forth many times more
complicated that it needed to be.  Thus was born
the idea of hardware tuned to do Forth.

> I spent
> a large portion of my career using the Inmos
> Transputer, now defunct as it didn't fit peoples ideas
> of what a processor should be but it followed many of
> the MISC concepts.  

And the Transputer was a strong influence on my 
ideas of parallel hardware, parallel programming,
and what sort of custom CPU I would want.  I brought
the idea to Chuck eleven years ago.  But the people
in parallel processing considered Unix a joke and
wanted big industrial strength operating systems.
So they really didn't get the idea of Forth or
small processors at all.  The Forth people didn't
get the idea of parallelism at all.  A dozen years
later a few people are beginning to get the ideas.

> Intrested parties should scoure
> the web for information as it is a very powerful and
> good model of what a minimalist processor should look
> like.  It used byte codes and had a 3 element stack

Yes, but not dual stack, not Forth, not tuned for a
trivially simple second generation optimizing native
Code Forth compiler or tuned for instructions smaller
than bytes.  It was tuned for Occam.

P21 is about as minimal as you can get for Forth.
Forth has two stacks, it is hard to put that into
three cells.  Once you use those three cells as
stack pointers to memory it looks like a clumsy
version of a conventional processor.

> architecture, it was designed to be programmed in a
> high level languauge called OCCAM for which most
> operations turned straight into byte codes so even
> though it looked like a high level language (like C or
> Pascal) it ran like assembly.  It also had 4
> communications links that could tie to 4 other
> processors and create a "computing surface".  It is
> very low in transistor count and even contained a
> process scheduler in hardware so that no OS was ever
> required.  

Yes, of course.  I knew it well.  But because of where
it came from it also needed special support chips that
didn't quite fit in with commodity parts.  So engineers
had problems with it.  And people who were not already
using Occam didn't want a new language.  I had thought
a dozen years ago that there was already an established
community of people happy with programming in Forth
and didn't anticipate how they would change to something
entirely different, ANS Forth, over that fifteen year
period.

Occam and the transputer were tightly coupled.  I don't
know which came first.  A transputer could run other
things and Occam could run on other things but then
you lost the synergy.  We wanted that kind of synergy
but for Forth.  Particularly the exemplary style
of Forth practiced by Mr. Moore.

> It fit with many if not all the MISC
> concepts and the code was suffienctly small that in
> many cases the processor could do many significant
> functions completely from its 4Kbytes of on-chip
> memory.  

Yes, many but not all.  Occam isn't Forth.  But
Forth can include the features of Occam in a few
lines of Forth code.

> Many people missused it and added OS's and
> large amounts of external ram but you could build very
> powerfull systems efficently if you took simplicity as
> a design goal.  There is much to be learned from this
> processor and hopefully the 25x will use some of these
> concepts.

The research that led to 25x was built on top of the
Occam and Linda concepts and transputer legacy that I
brought to the table mixed with Chuck's MISC and Forth 
ideas.  That is ancient history now.
 
> that bandwidth issues often dominate and limit
> processing power so make sure that your processing
> power has suffiecent bandwidth support, so it doesn't
> spend all its time waiting for data.  

Of course.  We looked at workstation farms in the
old days and the communication between nodes was
most often the bottleneck because it was built on
top of hardware designed to compete with slow disk
drives, and on top of layers of OS software designed
to support the file paradigm.  That is why Chuck
designed gigabit self-routing network interfaces
that required zero memory bandwidth most of the
time as on F21 or the multiple gigabit serial
links on one P32 to support fiberchannel and
network routing and protocol translation on $1
chips instead of $10,000 boxes.  We did extensive
simulations for years on the variations of the
instruction set, memory space, and interconnection
options. 

Not all things are best for all problems.  We
didn't want a universal general purpose solution
that only operated at very low efficiency most of
the time, wasting 99.99% of its power most of the
time. So for real code, and real problems that
interested us we picked some designs and tuned things.

Many people have complained that it isn't the
way they would tune their own design.  Fine.
Please, do your own design.  Do the research,
tune it for what you want.  Not everyone wants
the same thing.  

There is no such thing as a general purpose solution
that gets maximum efficiency on everything.  There
are many general purpose designs, or at least that
was the goal of many designs.  Our goal was to get 
1000x better efficiency by narrowing the focus.  

If it isn't your focus then tune your design
differently.  Chuck is in the custom silicon business.
Bring your ideas and funding and do your thing.  It
is easier to be critical of other people's focus
than to have one of your own or to expose it.

> Maybe my comment
> are related to my current work which is developing a
> chip for voice processing that has 9 DSPs running at a
> realitively high speed (10% of Chuck's 25x speed) and
> we are bandwidth not MIPS limited so I put this
> forward and caution that many people underestimate
> thier bandwidth needs and get burned in the longrun.

Yes.  And few people invented their own language and
worked exclusively with it for twenty or thirty years
before building hardware based on their understanding
of how the language worked.  You didn't get to tune
the instruction set on your chips, so you could not
shrink the code by a factor of 100 and reduce your
memory bandwidth needs.  Maybe you didn't spend
a few years simulating the effiency of different
design options to create a target architecture
tuned to your problem.  If you used off the shelf
DSP then you had the problem that led Chuck to
want to design hardware in the first place, that
if someone else makes the hardware design decisions
they are not likely a close match to your software
plans.  This leads to extra layers of software,
more work programming, reduced hardware and
software and programmer efficiency.  And it also
leads to increased memory bandwidth requirements.

I like to say that at the software level any program
can be represented by one bit on the right hardware
or zero bits if the hardware only runs one program.
Custom hardware people, or programmable hardware
people often take solutions described in software
and compile them directly to logic gates.  There
is really no hard line between hardware and software
in that sense.

But most programmers use off the shelf hardware
where someone else made the hardware decisions and
they have to add software on top to fill in the gap. 
Most programmers use off the shelf OS and compilers
where someone else made the software decisions and
they have to add software on top to fill in the gap.
So there are extra layers of hardware that are not
only not needed but get in the way and extra layers
of OS software that are not only not needed but get
in the way and more extra layers of software that
_are_ needed to get around those other extra layers of
hardware and software.  Bloat becomes inevitiable and
things like memory bandwidth requirements go up and
performance and programmer efficiency go down.

The effect of the syngergy of highly tuned hardware 
and software, and of Forth hardware and software are
very difficult for most programmers to grasp because
to them software is all about those extra layers that
they deal with for a living.  They just have no
experience with highly tuned efficient hardware and
software and how the line between hardware and
software isn't hard at all in such systems.  They 
have a hard time stepping out of the world where
they live where hardware is hard, and megabytes
of software is hard, and only some software is 
slightly softer.

In our world hardware is soft and the synergy between
highly tuned custom hardware and highly tuned custom
software changes the whole picture completely.

> You can never have too many friends, money or
> bandwidth.

I don't know about that.  I know a lot of people who
have way too much money for their own good or anyone
else's.  I don't think it really helps them. It just 
makes them lazy, greedy, arrogant, and mean spirited.  
They worry about getting more money not being a better
person or helping anyone else or doing good with their
life.

Even with friends, qualtiy is everything and quantity
accounts for little.  Evil people can find plenty of 
other evil people to be their friends.  Much better
to find one good person to be your friend.

I think there is a sense of satisifaction that comes
from doing more with less.  Being able to meet your
goals without squandering resources and making other
people slave or starve or breath excessive levels of 
your smoke. But we live in a culture that promotes the 
idea of conspicuous consumption and retched excess as the
ideal and fosters the illusion that more is always better.

Many people, even in the Forth community, say they
want the "ideal" computer and describe it as an
infinite register machine. I laugh and say that is
exactly the problem.  They want infinite waste. 

I think infinite registers means infinite addressing
width, and infinite registers times infinite width
is infinite hardware which will require infinite
cost, infinitely large programs and infinite
time to even decode one instruction.  The idea is
simply impossible, but if everything in the universe
was converted into the best approximation of their
infinite waste machine they could meet their goal
of selfishly and stupidly destroying the universe
to make one infinitely useless and infinitely slow
computer for them.

I always found Math and Physics to have a form
of beauty that rivaled any painting or  symphony.
The beauty of simple yet powerful ideas.  I liked 
the elegance and beauty of the shortest and simplest
solution, not the ugliest of the biggest or
most complex solution to a problem. This is why I 
was attracted to the best example of elegant beauty
that I have found in the world of computing, Chuck 
Moore's ideas about Forth.

I know they are not the ultimate ideas, but computers
are still a very young idea.  They are just the best
ideas I have found in that field.
------------------------

To Unsubscribe from this list, send mail to Mdaemon@xxxxxxxxxxxxxxxxxx with:
unsubscribe NOSC
as the first and only line within the message body
Problems   -   List-Admin@xxxxxxxxxxxxxxxxxx
Main 4th site   -   http://www.