Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!jato!jdickson
From: jdickson@jato.jpl.nasa.gov (Jeff Dickson)
Newsgroups: comp.sys.amiga.hardware
Subject: Re: A3000 CPU Wars!!
Message-ID: <1991Jun12.223640.11718@jato.jpl.nasa.gov>
Date: 12 Jun 91 22:36:40 GMT
References: <16888@helios.TAMU.EDU> <1991Jun5.060518.9683@news.iastate.edu> <1991Jun5.072620.18879@mintaka.lcs.mit.edu> <22213@cbmvax.commodore.com>
Reply-To: jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson)
Organization: Jet Propulsion Laboratory, Pasadena, CA
Lines: 54

In article <22213@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes:
>In article <1991Jun5.072620.18879@mintaka.lcs.mit.edu> rjc@geech.gnu.ai.mit.edu (Ray Cromwell) writes:
>
>>  Hmm, anyone wanna tell me how transputers work? (multiprocessing)?
>
>Transputers define a loosely coupled multiprocessing system based on message
>passing.  Essentially, each transputer has four hard message ports, which can
>be used to send messages reasonably fast to four neighboring transputers. 

	If memory serves (BYTE a few years ago), it was something like 80
mega bits per second. They also did some benchmark, where a 1MHZ T800 was
as fast as a 4MHZ Z80. It was an attractive processor, because for instance
it performed multitasking in hardware. 

> The T800 series had decent floating point, but weak integer instructions.

	I didn't know that.

>On the other hand, INMOS was purchased by Thompson, and with some new money was
>able to define a next generation Transputer.  It's not out yet, but the new
>T9000 sounds much more intriguing.  It's considerably faster, so it could very
>well stand a chance of competing with other modern CPUs on a 1:1 basis.  The
>links are faster now, and they have a neat cross-point switch that works with
>them.  The hardware supports virtual messages now.  Basically, a header in the
>message structure indicates where it's going in your transputer network 
>somehow.  When the message gets sent out the hardware port, it can get to its
>ultimate destination through this message router, which will wait until a link
>to the destination is free, create a temporary routing path from one to the
>other, then dissolving it when the message has passed.  

	Oooh, nifty! Sure'd be nice if this one could make it down to some
platform so I could experiment with it. 
>
>Anyway, this new one looks to be pretty cool.  Yet, it doesn't solve the main
>problem with loosely coupled system, which is, how to schedule work such that
>it gets done faster on multiple processors than it does on a single one.  With
>this model, you're basically dependent on splitting things at the task level.
>This generally means that you have to write your code much differently, 
>adapting the problem to the solution.  Some problems adapt, others don't. 

	But perhaps it could better serve the system as an intelligent
coprocessor. I haven't even studied the T800 instruction set, so I don't know
its true possibilities. I just suspect that with its high speed message port
for instance, it could coordinate activites with other T800 coprocessors.
I'm exited, just can't get my hands on one!

	
>
>-- 
>Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
>   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
>	"This is my mistake.  Let me make it good." -R.E.M.

-jeff