Path: utzoo!attcan!uunet!yale!cmcl2!lanl!jxdl
From: jxdl@lanl.gov (Jerry DeLapp)
Newsgroups: comp.sys.transputer
Subject: Re: What makes Transputer interesting
Summary: I disagree!
Message-ID: <6426@lanl.gov>
Date: 21 Nov 88 16:59:06 GMT
References: <6048@lanl.gov> <5255@cbmvax.UUCP>
Organization: Los Alamos National Laboratory
Lines: 83

In article <5255@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) writes:
> in article <6048@lanl.gov>, jxdl@lanl.gov (Jerry DeLapp) says:
> > The transputer is fast (about the equivalent of a vax or sun 3 now,
> > and getting faster).
> 
> The comparison was with a 68030 or 80386, not a vanilla 68000.  For
> integer processing speed, a 68000 isn't quite a VAX 750.  The only
> T800's I've seen benchmarked IN A SYSTEM process integers in the
> VAX 780-785 range, like a medium performance 68020 system (which is
> just what a smaller Sun 3 is).  68030 systems outperform 8xxx VAXen
> in most integer benchmarks.

No, the question was what made it interesting, not whether it was
faster than the 68030. The 68030 was just used as an example. The
transputer's speed (I agree, about equal to a 780 on integer ops,
but much dependent on memory technology used with the transputer) is
plenty fast enough to be "interesting" (at least to me :-). Besides,
try to plug a 68030 into the hole for a 68000. You'll get smoke. Most
transputer systems can be upgraded by just plugging in newer, faster
chips.

> > The communications are very fast, have very low startup overheads,
> > and operate without any need of the CPU after setup.
> 
> Any DMA driven communications channel will operate without CPU 
> intervention after setup.

I agree, but I haven't seen one discrete implementation that can
comes close to the transputer in terms of low setup time. Also, why
implement the sucker yourself if you don't have to, and can't beat
the setup times to boot.

[stuff about FP unit and context switching deleted].

> > The transputer is RISC technology. The small instruction set means
> > that it's fairly easy to port compilers to it (although INMOS seems
> > to be real stodgy about realizing that the real world wants C and
> > FORTRAN).
> 
> The Transputer isn't RISC at all.  About the only thing it has in common
> with true RISC-methods CPUs is that it's rather small.  There aren't
> any registers; RISC chips typically have a minimum of 32, some close to
> 200.  A good portion of Transputer instructions are slow, microcoded
> instructions; RISC chips use hardwired instructions that execute in or
> near single cycles.  Transputers don't have cache memory; all RISC
> chip COUNT on caches.  Transputers don't have memory management, which
> is crucial to running protected operating systems.

Excuse me, but I think you're confusing implementation with theory.
RISC means: Reduced Instruction Set Computer. In that context, the
transputer certainly qualifies as RISC. Register counts, caches and
memory management have nothing to do with whether a chip is "true
RISC." They are just implementation details that might make one chip
more attractive than another. I agree that the absence (sp? :-) of
virtual memory management support makes the transputer less attractive
for implementing large multi-user systems, but it certainly doesn't
eliminate it completely.

(BTW: No flames please. I know the RISC/noRISC debate belongs in
comp.arch :-)

[remaining inane comment about transputers only being good as
sattelites to 68xxx systems or as loosely coupled systems deleted]

Actually, my experience has been that the transputer works best in
tightly coupled systems, not loosely coupled. Still, it's brought
loosely coupled systems into the realm of affordable reality.
Hence, most of the discussion in this newsgroup centers on how to
make loosely coupled systems work well.

Remember when drawing comparisons between the transputer and the 68xxx
803xx and others, that you're discussing differences between chip series
that have been around for many years vs. something "new and different".
In terms of progress and improvements, I think that INMOS is much
faster than either Motorola or INTEL in addressing problems with and
making improvements in their product.  (It took INTEL 8 years to
finally build a CPU worthy of respect. I've always respected the
68000 series).
-- 
_    /| The opinions here are my own, and even I don't agree with me :-)
\'o.O'  I am not an employee of LANL, I just use their computers.
=(___)= I stole the .sig file, but I did not shoot no deputeeee.
   U    Bill sez: AAAAK! PHHHT!   jxdl@lanl.gov