CDRIW@cr83.staffordshire-polytechnic.ac.uk (10/11/89)
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,
hierarchical 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?)
Iestyn Walters. "Representation is the essence
of programming" -- Where does that
leave occam?