Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!agate!usenet.ins.cwru.edu!eagle!ljkiraly!jim
From: jim@ljkiraly.lerc.nasa.gov (L J "Jim" Kiraly)
Newsgroups: comp.sys.next
Subject: Re: What about Transputers for NeXT?
Message-ID: <1991May14.205725.14944@eagle.lerc.nasa.gov>
Date: 14 May 91 20:57:25 GMT
References: <32842@usc>
Sender: news@eagle.lerc.nasa.gov
Organization: NASA Lewis Research Center, Cleveland
Lines: 65

In article <32842@usc> avery@rana.usc.edu (Avery Wang) writes:
->I tried posting this a few weeks ago but apparently the news software is 
->unreliable:
->----------------------------------------------------------------------------
->
->It would be interesting to see a NeXT based on the not-yet existing transputer.
->It seems to have a lot of promise, but is still vaporware.  Check this out:
->
->Electronic Engineering Times April 22 1991
->
->Transputer pumped up BY ROGER WOOLNOUGH
->
->Bristol, England--SGS-Thomson took the next step in its global 32-bit
->microprocessor strategy last week, unveiling further details and schedules
->for the powerful H1 Transputer from its subsidiary Inmos Ltd.
->SGS-Thomson--which has remained aloof from other silicon vendors in the
->scramble to align with a major RISC architecture--will rely on the power,
->flexibility and broad tool support of the new Transputer, dubbed T9000, to
->claim a share of the emerging 32-bit embedded computing market.
-> etc.

We've used transputers for several of our research projects.  The architecture
and native programming language (OCCAM) of transputers are derived from a 
communicating sequential process paradigm, with any number of logical channels
representing the interconnection between otherwise asynchronous processes.  
There are no global variables which results in some special programming 
concerns- such as allowing specific channels or tagged messages to tell 
otherwise continuing processes when to stop.  Transputers are very powerful 
in that logical connectivity between communicating processes can be mapped 
into somewhat arbitrary (and easily expandable) arrays of processors- each
of which manages it's own set of high speed serial links. The architecture 
and OCCAM constructs are similar to the message-object schemes of Objective C
(although I think it would take quite a bit of work to map Objective C into
a transputer environment).

We have not found any really complete/tight operating system to work with our
transputers.  For most applications, we've developed OCCAM programs using the
INMOS development system- which requires users to manage a lot of their own
system-type stuff that is normally invisible to the user.  There have been
some OS implementations which actively seek out unused processors in an
arbitrary network and add them as they come "on-line", or delete them as they
go off-line (Pretty good for fault tolerance)- but there hasn't been a good
overall OS implementation that at least we have found.  Some of the problem
had to do with past implementations of transputers- which are supposedly
addressed with the new T9000's (things like message routing, and better
support for higher level languages).

Anyway, my point with all this is to say, me too!  If NeXT was interested
in porting objective-C and NeXT Step, a workstation based on same could offer
a number of performance advantages such as internal client server operation
with internal, individual processors; objects mapped onto individual
processors, program controlled internal processor re-configuration to suit
different workstation applications (file-server, graphics workstation, client
workstation etc.), and the ability of users to incrementally upgrade their
workstations by adding transputer modules as they could afford them.

A useful product along these lines needs a corporate sponsor to set the 
interface rules, design the user interface, and develop the core utilities.
IT would really be a hot workstation, and I for one would love to have one.
I do feel that this is really a big job and too big a NeXT Step for NeXT- 
but I guess I still like to dream about the possibilities.
--
___________________________________________________________________________
  Jim Kiraly  - jim@ljkiraly.lerc.nasa.gov  -  NASA Lewis Research Center
---------------------------------------------------------------------------