Re: [colorforth] Musings on SEAForth

["Jeff Fox" <fox@xxxxxxxxxxxxxxxxxxx>]

> I cruised by the IntellAsys site last night. I signed up there some time
> last year, and my logon is still active, although the site is being
> revamped and is supposed to be alive some time this month. (Jeff, I
> suppose you can't confirm or deny that, can you?) The last time I was
> there, some tools were available but they appear to have been withdrawn.
> What I remember was that the tools ran in either SwiftForth on Windows
> or gForth on Linux, both of which I have.

Or gforth in windows.  And yes there is someone working on the site.

> What little is there is interesting. I think I understand how one would
> program these devices at the colorForth level now, but what's missing is
> two things:
>
> 1. Some insight into the design decisions. For example, why 18 bits?

In 1988 Chuck said 16 bits wasn't enough for addressing enough
data to do something as large as VLSI CAD.  So he made the ShBoom
which was 32-bit.  In 1990 he said that 32 bits was overkill and
that 20 bits of address was enough for the CAD system and that
he could reduce all costs by 3/8 by going from 32 to 20 bits.
He designed MuP21, I21 and F21.  In 2000 he decided to make a
chip that could have a reverse pinout of an 18-bit fast cache
sram so that it could be mounted back to back with an 18-bit
fast ram.  RAMS came in 8, 16, and 18 bit sizes.  Having spent
a decade with 20/21 bit architecture he decided to try 18 bits
for the parallel design.  You can kind of think of it as an
18-bit slice if you want and you could think of the latest
chip as being a 720 bit wide chip

I think part of it is that Chuck rebels against the 8-bitness
you see in C.  He says C has to carry that burden but he
doesn't.

> It's fine for CD-quality audio but not for DAT-quality, which requires
> 24 bits. Sure, you can get fewer 24-bit cores on a chip than you can
> with 18-bit cores, but you can get *more* 16-bit cores, and many more
> people have instincts about 16-bit arithmetic than 18-bit arithmetic.

You can do 16 bit arithmetic on an 18-bit processor if you want to.
With a 36-bit multiply 24 and 32 bit is pretty easy.
Europay does 300 bit math on an slow 8-bit processor after all.

> 2. How one would fit a large complex program to an array of these
> devices.

Fitting comes after factoring, coding, placement and routing.
One approach will not fit all problems.   It is not quite as
bad as how one fits a large complex program onto an FPGA.  It
is more like programming in Forth.

Many computers have no internal memory at all.  How do you fit
a large complex program onto one of those computers?  You put
the program in external memory if it is bigger than the memory
you have on chip, or you use more chips to hold more program
if it is a parallel program. Large programs in Forth are made
of lots of short words.  Think of putting a few words on each
node.

> While Forth is certainly a multi-level language eminently
> suitable for designing domain-specific languages, I don't see how you
> could *automatically* go from a high-level problem description to
> working hardware and software, especially with the cores having a ROM
> component!

The ROM component in cores is for booting and for having routines
that can be called from RAM to reduce the size of programs in RAM.
ROM is much smaller and cheaper than RAM.

The closest thing you will see to *automatically* generating code
is taking parallel objects from a library and dropping in into
a design and having them placed, routed, instantiated, and
having their data flow mathematically verified for you.  If you
have or license parallel library objects then you can work at
as high a level of abstraction as you want.  I suppose that if
selecting parallel objects from a library is too low level a
wizard with expert knowledge could assist you in the process
of selecting objects and the properties that you want to use.

I noticed that the first question all developers asked was, "How
to I get my program distributed to the array?" I always said
that will come later, don't worry about that now. You don't have
a program yet.  When you get that far you will have options.

You start by compiling your code directly to cores to verify
that it is correct.  Once you have done that there are tools
that distribute and collect parallel programs and data.  All
your programs can be turned into a stream that is loaded at
one place and which distributes your program to the nodes.
I don't recommend that you try to solve that problem yourself
before you learn to write and run simpler programs.

SEAforth processors can use memory for code or data and they
can execute code streamed to a port. While local memory
size is small time and source are the only limits to the
size of programs that can be sent and executed.

One can use parallel processors to do sequential things
efficiently if they can be programmed in pipelines and
you can also do other things in parallel very easily.

Best Wishes


---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com