Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!A.ISI.EDU!ENGLE
From: ENGLE@A.ISI.EDU
Newsgroups: comp.sys.transputer
Subject: H1
Message-ID: <[A.ISI.EDU]29-Nov-89.11:26:54.ENGLE>
Date: 29 Nov 89 16:26:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 59


James Price Salsman writes:

>> Somewhere else I heard about 6 links ?
>Nope, only TWO!!!  Kinda defeats the purpose.  The H-1 is
>definetly going to be a linear array.

Given virtual routing, I think you have to ask whether more than two 
links are necessary.  The effect will be that we can all toss out our
code that routes between intermediate processors and let the chip 
handle it.

An Inmos representative at NATUG expressed the number of links issue as
a dynamic -- you can have more links at the same or slower speeds, or 
you can have less links at faster speeds.  Isn't it also partly due to
some clever trick in the chip timing which gives the DMA engines a window
to operate without burdening the rest of the chip?  I recall that there is
some magic number (I think that its 2x) which sets the ratio of the link
speed to the CPU such that this window arises (experts care to comment?).

As for the MMU, all I would ask for is some form of memory segmentation.
In a language such as C where you can set a pointer to an arbitrary integer
you need some form process isolation in the memory system.  I remember 
watching errant programs trash video RAM on my Apple II while learning linked
lists.  If this chip is ever going to make it in some of the more demanding
applications we need some way of guarenteeing that you can willfully or 
accidently overwrite the operating system.

I personally can't image using any sort of virtual memory scheme effectively 
in a transputer array, unless you did the sort of thing that Chrysalis on the 
BBN Butterfly does.  In their system, processes can generate page faults when
they attempt to access non-local RAM, which in turn maps the access to 
somebody else's local RAM.  You get the effect of a shared memory machine.

In regard to the link speed, one way to get the promised throughput is to
just make the links parallel rather than serial.  This would give you an
eight-fold increase in speed for what I suppose would be an equivalent loss
of die area.

In larger applications we are also beginning to see a lot of RAM sitting 
around.  Some designers have demanded error correcting memory support and so 
forth simply because as the amount of RAM increases your changes of errors
increase.  Does anyone have a feel for whether this should be a concern?

How important is upward compatibility?  Particularly given the sort of
marketplace that the transputer is hitting (primarily innovators and 
academics).  I feel sorry for all those frustrated engineers at Intel who 
must continue to support this stupid segmented architecture.  One thing that 
RISC has done is its allowed companies with entrenched dinosaur architectures 
to have an excuse for dropping upward compatibility in their new product line.
Its also opened a narrow window for upstarts to jump in and be taken seriously
(e.g. MIPS).  Are there enough users of the Transputer series to justify 
maintaining upward compatibility or should (can) Inmos go for the potentially 
bigger marketplace?


Steven W. Engle
Senior AI Software Engineer
MIMD Systems, Inc.