Re: Musings on SEAForth

Jeff Fox wrote:
> Or gforth in windows.  And yes there is someone working on the site.
Thanks! I haven't even bothered with gForth on Windows -- SwiftForth is 
so much better.

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

Ah ... yeah, if you can't get 24-bit RAMs then 18 it is, since it's 
better than 16 or 8. So is an 18-bit address wide enough for VLSI CAD?

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

So is the ROM pre-set to something by default, or does each SEAForth 
customer have to have a custom ROM designed, tested and built?

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

That's pretty nifty if you can actually do it. I hope I can get a 
simulator in the near future and try some of this out. :)

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

Yeah ... I wasn't in the room when the guys at FPS invented/discovered 
software pipelining, but I *was* in the building when they taught a 
Fortran compiler how to do it. :)