🚀 go-pugleaf

Grain for thought:

Performance with programmability is the target.  Surely the point is to
keep the memory as busy as possible?  Cycles-per-instruction is not the
issue, but accesses-per-memory-location.  Microprocessors in general
are too big:  A 10 mip processor with 10 Meg of RAM accesses each
location only once per second.  What a waste of RAM!

The `grain-y-ness' of occam is great, with its 3 primative processes,
hierachical process structure and lack of shared memory.  When applied
to transputers however, the niceness begins to break down.
Distributing a program on transputers imposes a flat process structure,
with a limit of 4 channels per process.  Processes with internal
parallelism (i.e. communication) run time-sliced.  What is required is
transputers with internal transputers!

How about a (size 1) TRAM with 4 T2s arranged in a tetrahedral
structure, although RAM would be a big problem here.  Even more
interesting would be 4 (say) transputers on the same die.  In this case
the intra-die link engines need not be serial but 8- (or why not 32-)
bit parallel -- this would really get the data flowing.

We need systems with *much* higher processor-communication / RAM.  This
may require smaller processors with better communication (looks very
neural-nettish, eh?)