josef@ugun21.UUCP (11/11/88)
Forgive me for my impertinence, the following question might sound like blasphemy to some of You, but I have had a discussion with my boss, and he posed this question: What distinguishes a Transputer from any other processor, especially if I take a, let's say 68030 or 32532, add 4 communication channels and write software to do processor-processor communication? What makes a Transputer so interesting? Josef Moellers paper mail: e-mail: c/o Nixdorf Computer AG USA: uunet!linus!nixbur!nixpbe!mollers.pad Abt. EG-3 !USA: mcvax!unido!nixpbe!mollers.pad Unterer Frankfurter Weg D-4790 Paderborn tel.: (+49) 5251 104691 Standard disclaimer: Blablabla opinion blablabla employer blablabla!
cme@cloud9.UUCP (Carl Ellison) (11/13/88)
In article <20000001@ugun21>, josef@ugun21.UUCP writes: > > What distinguishes a Transputer from any other processor, especially if > I take a, let's say 68030 or 32532, add 4 communication channels > and write software to do processor-processor communication? > What makes a Transputer so interesting? Aside from the MUCH lower chip count (& don't forget memory interface chips), the transputer has a very fast process switch and nearly free inter-process communications. Meanwhile, occam is designed for people who dream distributed systems as opposed to others who dream von Neumann and then have to coerce their one thread onto multiple processors. In fact, that's the key transputer characteristic as well. It's designed for the way I think. That's enough for me. ...for you? --Carl Ellison ...!harvard!anvil!es!cme (normal mail address) ...!ulowell!cloud9!cme (usenet news reading) (standard disclaimer)
grabas@m.cs.uiuc.edu (11/13/88)
What make the Transputer interesting is:
-- its integration (communication, multitasking, Floating-point on
the same chip) ==> speed
-- its RISC-like architecture (few simple short and fast instructions)
-- its built-in memory controller: The Transputer can drive DRAM with
no additionnal circuitry.
-- The speed and simplicity of its multitasking and communication due
to the fact that they are integrated at the processor-instruction
level.
To sum-up, the Transputer is great because it is ONE Transputer
instead of being MANY circuits + software.
One of the main things I reproach to the Transputer is that it does not
support virtual memory (vital to build any reasonnable stand-alone machine).
If anybody from INMOS reads this note, please, could he tell me when it
will be done (or why it shouldn't be done...)?
Dominique Grabas, University of Illinois at Urbana-Champaignjxdl@lanl.gov (Jerry DeLapp) (11/16/88)
In article <20000001@ugun21>, josef@ugun21.UUCP writes: [stuff deleted...] > I have had a discussion with my boss, and he posed this question: > > What distinguishes a Transputer from any other processor, especially > if I take a, let's say 68030 or 32532, add 4 communication channels > and write software to do processor-processor communication? > What makes a Transputer so interesting? > > Josef Moellers Well, you might say that the most interesting thing is that the transputer does everything that his gob of 68xxx and communications hardware and software does in one chip! Just the software effort involved in the "roll your own" version would be an ugly cost. Plus: The transputer is fast (about the equivalent of a vax or sun 3 now, and getting faster). The communications are very fast, have very low startup overheads, and operate without any need of the CPU after setup. This is not easy to accomplish in discrete silicon with software. In addition, the technology used for the communications allows for long (about 30-40 feet) cable runs. Memory management of the channels vs processor requirements are done on chip. The (T800) transputer has on-chip floating-point support. The context-switch time on a transputer makes the 68xxx look like a pig. 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). INMOS has good plans for the future growth and enhancement of the chip series. (Now if they'd just do the same with the software). OPINION: The transputer will probably define the future of parallel computing for the next 5 years or so IF IF IF INMOS will wake up and realize that the OCCAM language is a significant hindrance to acceptance of their product in the US market. OCCAM is a language best suited to CS weenies (BTW IR1, so I can say that :-). P.S. I am not an INMOS employee. I have had significant experience with the transputer in a large scale parallel machine. The transputer hardware works well, the software sucks rocks. OCCAM is the single biggest roadblock to general acceptance of transputer based systems. Most people that I introduced to the OCCAM language system said "Come back when you have 'real' languages". I am certain that we will not solve the problems of broad acceptance and understanding of parallel processing's capabilities as long as OCCAM is the context. -- _ /| 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
ellard@bbn.com (Dan Ellard) (11/16/88)
I'd like to get more information about transputers, available systems based on transputers, and what software has been written for these systems. I'm especially interested in documentation for the transputer assembly language, an OCCAM programming manual, and some description of whatever operating systems or executives which have been ported to/written for transputer-based systems. -Dan
rcoda@koel.rmit.oz (David Abramson) (11/16/88)
From article <37700002@m.cs.uiuc.edu>, by grabas@m.cs.uiuc.edu: > One of the main things I reproach to the Transputer is that it does not > support virtual memory (vital to build any reasonnable stand-alone machine). > If anybody from INMOS reads this note, please, could he tell me when it > will be done (or why it shouldn't be done...)? > > Dominique Grabas, University of Illinois at Urbana-Champaign Also the on-board memory should be organised as a cache. This makes programming much easier. PS. I agree about the +ve points. Dr David Abramson ACSnet: rcoda@koel.co UUCP: ...!uunet!munnari!koel.co.rmit.oz!rcoda CSNET: rcoda@koel.co.rmit.oz ARPA: rcoda%koel.co.rmit.oz@uunet.uu.net BITNET: rcoda%koel.co.rmit.oz@CSNET-RELAY PHONE: + 61 3 660 2095 Commonwealth Scientific and Research Organisation, Division of Information Technology, c/o Department of Communication & Electronic Engineering, Royal Melbourne Institute of Technology, P.O. Box 2476V, Latrobe St, Melbourne, 3000, Australia
rtm1@thumper.bellcore.com (Ravi Masand) (11/17/88)
In article <> josef@ugun21.UUCP writes: > >What distinguishes a Transputer from any other processor, especially if >I take a, let's say 68030 or 32532, add 4 communication channels >and write software to do processor-processor communication? >What makes a Transputer so interesting? > > Josef Moellers > 'Interesting' is a subjective characteristic. I personally feel that the transputer is interesting because, atleast from a hardware developer's viewpoint it offers a lot of bang for the design effort. Lets start with your 68030 alongwith its four communication channels - to match the transputer these links need to operate at 10 Mbps and contending with these communication devices is no cakewalk - both in terms of H/W and S/W The transputer provides a multitasking kernel built right in the microcode. The multitasking processes use channels for interprocess communication - and these channels can be implemented either with memory exchanges or over the serial links. This can be made transparent to the application programmer. What this does is that it allows initial development and use over a lesser number of transputer and at a later time, if so desired, performance can be enhanced and almost linear speedup achieved, by increasing the number of transputers in the system and redistributing processes. As far as the multitasking is concerned, all instructions use a register stack (on chip) which is valid only for the duration of the instruction. This makes context switching extremely fast. This philosophy of integrating the links right into the kernel pays divedends in another manner. The transputer is capable of booting itself right from the links. This implies that in a multiple processor system only one transputer is required to have a ROM. The others will be perfectly content with a simple RAM subsystem. Another hardware facility provided is that of a DRAM controller built right into the chip. This simplifies DRAM system design considerably. Also provided in hardware is a floating point unit. As to how it compares with the 80387 and Motorola's FPU I don't know. Reasonably well I'd suspect. Another hardware goody provided is on-chip memory. This is either 2k or 4k depending on the CPU (T414 or T800 resp). While not much in itself it can be used for code optimization as instructions running out of this on chip RAM run a lot faster than from external RAM. And the final hardware goody provided is an on chip frequency multiplier. This means that the different speed versions all take in 5 MHz clocks and multiply it appropriately to generate 20/25/30 Mhz. Thus these high frequencies are restricted to within the chip. These are all the hardware pluses I can think of. There probably are some more. Far as the software is concerned - Inmos claims that a high percentage (~70?) of the instructions can be coded in one byte. I have looked at the instruction encoding philosophy and found it to be impressive. If you are at all interested in CPU architectures you really should look at it. It is, to say the very least, 'Interesting'. I haven't really had any experience with the software but soon will have some. But probably not with Occam. Please keep in mind that I am no transpu-phile and Inmos has no say in my material well being. I have simply worked with the CPU for a little while and was favorably impressed. Furthermore I don't think that the transputer is 'better' than the 68030 or vice versa. For a given application one or the other may be more appropriate and for still other applications a Z-80/8085 would be clearly more desirable :-). Questions: Has anyone out there worked with the transputer in a language other than Occam ? How has it worked out ? Is Occam really mandatory to use the CPU to its fullest ? And anyone know of a good book/reference to pick up Occam in a hurry ?? Thats it. Cheers. Ravi Masand Bellcore (201)-829-4593.
daveh@cbmvax.UUCP (Dave Haynie) (11/17/88)
in article <6048@lanl.gov>, jxdl@lanl.gov (Jerry DeLapp) says: > Summary: Cheap, fast, powerful, cheap, cheap, (I like cheap) > 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. > 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. > The (T800) transputer has on-chip floating-point support. That's probably it's nicest feature. The on-chip floating point i pretty fast, though it's a small set of operations. You'd have to go to a Weitek chipset for that kind of performance on a 68xxx or 80xxx. Motorola's 88100 has an even better on-chip floating point scheme, using separate execution units for addition and multiplication. > The context-switch time on a transputer makes the 68xxx look like > a pig. ONLY IF you can use the hardware defined task model. In that case, it's pretty nice, since it'll actually wait for a minimum of task state before swapping. If you wanted to run a standard operating system on the thing, you'd be in trouble. And the 68030's interface to memory makes the T800's "look like a pig", to coin a phrase. > 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. I think if they get low cost enough, Transputers will make excellent satillite controller in a 68xxx or similar system, what with the on-chip RAM and math and all. They're also well suited to certain kinds of parallel problems that lend themselves well to loose coupling. Tim King's company Perihelion does offer a C compiler for the things that's not supposed to be all that bad; certainly more palatable to most software people than Occam. So I think Transputers have their place, but that place isn't the place currently occupied by most CISC and RISC CPUs, that of main processor. > _ /| 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 -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
w-colinp@microsoft.UUCP (Colin Plumb) (11/17/88)
First of all, I agree that it's the level of integration that makes a transputer interesting. They can do useful work with no external components - just feed it power, ground, clock, reset line, and hook up a link or two. You can boot it, download programs, and run them. In article <1389@thumper.bellcore.com> rtm1@thumper.UUCP (Ravi Masand) writes: >Also provided in hardware is a floating point unit. As to how it compares with >the 80387 and Motorola's FPU I don't know. Reasonably well I'd suspect. It blows them away. Against good FP ALUs (MIPS, Am29027, BIT's stuff) it's not great, but it's at least in Weitek's league. We've timed 2 MFLOPS doing dot products in on-chip RAM. >Far as the software is concerned - Inmos claims that a high percentage (~70?) >of the instructions can be coded in one byte. I have looked at the instruction >encoding philosophy and found it to be impressive. If you are at all interested >in CPU architectures you really should look at it. It is, to say the very >least, 'Interesting'. Well, they have got a patent on it. I think it's closer to 50%, but still the code is highly compact. (There are a few rearrangements I'd like to make, but that's another story.) Having programmed it in assembler a fair bit, I'll avoid "impressive" and stick to "interesting". There are things they could have done better. (Have cj pop the 0? Unsigned gt?) >Questions: Has anyone out there worked with the transputer in a language other >than Occam ? How has it worked out ? Is Occam really mandatory to use the >CPU to its fullest ? And anyone know of a good book/reference to pick up >Occam in a hurry ?? Well, several C compilers are available. I reccomennd Logical Systems' C compiler, $6xx.xx with full source last time I looked. Kirk, are you still out there to correct me? They're based in Corvallis, Oregon. We had a couple of problems writing our OS in it, but it can handle serious work. I haven't done any work in Occam, but C works fine. No, Occam isn't mandatory, although it makes communications-rich code a bit more legible. Kirk's compiler has #pragma asm and #pragma endasm so you can escape to assembler and get at anything the machine provides. It's fun to play around with. I enjoy watching Mandelbrot sets running on 28 processors. -- -Colin (microsof!w-colinp@sun.com)
jxdl@lanl.gov (Jerry DeLapp) (11/22/88)
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
daveh@cbmvax.UUCP (Dave Haynie) (12/01/88)
in article <6426@lanl.gov>, jxdl@lanl.gov (Jerry DeLapp) says: > Summary: I disagree! > Actually, my experience has been that the transputer works best in > tightly coupled systems, not loosely coupled. Huh? You only get loosely coupled systems using Transputers. At least, as long as you're using the built-in links, you're only going to be able to implement loosely compled systems. From what I've head from folks who've been working with them, the external bus interface of the Transputer makes it complicated to use in a tightly coupled manner. The 680x0 family isn't really rough to use in a tightly compled manner, but you certainly need some external buffering. Newer RISC chip like the 88k make tightly coupled systems a slam-dunk, and the rumor mill says that the 68040 will work in a similar fashion. To exist in a tightly coupled system efficiently, though, you absolutely need caches and hardware cache consistency, which you don't get in the internal 68020/68030 caches. > (It took INTEL 8 years to finally build a CPU worthy of respect. I've > always respected the 68000 series). I think we're in complete agreement on at least this last point. -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession