Article 52377 of comp.sys.amiga.hardware: Path: news.csos.orst.edu!flop.ENGR.ORST.EDU!ogicse!uwm.edu!math.ohio-state.edu!howland.reston.ans.net!pipex!sunic!trane.uninett.no!news.eunet.no!nuug!news.eunet.fi!funic!nic.funet.fi!sheffield.ac.uk!D.Lamptey From: D.Lamptey@sheffield.ac.uk Newsgroups: comp.sys.amiga.graphics,comp.sys.amiga.hardware Subject: Warp transputer system.. Message-ID: <9310121003.AA09592@ntsc.shef.ac.uk> Date: 12 Oct 93 14:03:51 GMT Article-I.D.: ntsc.9310121003.AA09592 Sender: root@nic.funet.fi (The FUnny NET guru) Organization: Finnish University & Research Network Lines: 122 Content-Identifier: Warp transput... Alternate-Recipient: Allowed X400-Mts-Identifier: [/PRMD=UK.AC/ADMD= /C=GB/;<9310121003.AA09592@ntsc.shef.ac] X400-Content-Type: P2-1984 (2) X400-Recipients: non-disclosure:; X400-Originator: D.Lamptey@sheffield.ac.uk X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed; Xref: news.csos.orst.edu comp.sys.amiga.graphics:19654 comp.sys.amiga.hardware:52377 Hello, everyone. This is some info which I find *very* exciting for obvious reasons! I can provide further transputer info if anyone is interested, later! Derryck. _____________________________________________________________________ National Transputer Support Centre, Derryck Lamptey, MSc(Eng) (University of Sheffield) (D.Lamptey@sheffield.ac.uk) 5 Palmerston Road, Sheffield S10 2TE South Yorkshire, U.K. (NTSC@sheffield.ac.uk) Telephone: (+44/0) 742 768740 Facsimile: (+44/0) 742 727563 "use e-mail: save a tree" _____________________________________________________________________ ----- Begin Included Message ----- Date: Wed, 06 Oct 1993 14:10:59 MDT From: Neil MacMullen To: D.Lamptey@sheffield.ac.uk Subject: Re: WARP system.. Background ----------- The transputer was designed to be a high-performance parallel-processing microprocessor; the instruction set was modelled directly on the OCCAM language, and task switching is directly supported, with typical task-switch times of less than a microsecond. Most parallel-processing schemes rely upon shared memory for synchronisation and communication, leading to a tail-off in scalability at around 7 processors. The transputer has 4 serial 'links' which enable it to communicate with other processors - as a result scalability is much greater. New transputers are designed to be backwards-compatible with older chips, so code written on a 10 Mips T414 will also run on a 300 Mips T9000. Whilst the newer devices do add some instructions, the instruction set remains substantially the same, so it is not necessary to recompile code in order to gain the maximum performance when moving to new devices. All transputers run from a 5MHz clock, with an internal phase-locked loop multiplying the clock to the required frequency for the particular device. The Warp Board -------------- The device used in the WARP board is the T805; this is a 32-bit, 30 Mips/3 MFlops transputer with on-board 64-bit floating point unit. Mips ratings aren't really something to take too seriously for any processor, but our preliminary testing on a MandelBrot calculation program indicates that the WARP board runs somewhere between 6 and 10 times faster than an A3000 with 68882 coprocessor. There will be two varieties of WARP board; the first is a PIC for the amiga, the second is a module which will plug into an external box. The ironmongery is still under development, but the external box will probably hold up to 40 modules. Of course, you can connect up more than one external box if you want even more processors. The PIC has DMA access to amiga memory, allowing a high amiga-transputer communications rate. Transputer-transputer communications are provided via the links and are at the rate of 2 Mb/s per link. The current board to board interface will be supported for all future products, so you will not have to junk your existing boards in 5 years time when the next generation of processors appear - they can still be sitting in a corner of the network doing some useful work. The OS ------- The WARP board runs our proprietary OS which is loosely based on the amiga OS. Extended message functions allow messages to be passed between processors in a manner which is transparent to applications. Messages may even be passed back and forth between two or more amigas on the same network. Libraries allow amiga tasks to use the same functions as are available on the transputer; a properly written program will compile for both the amiga and transputer without any changes. The OS is fully multi-tasking and supports fork-type threads as well as simple parallel tasks. The OS can automatically load a task onto every processor in the network, so it is not necessary to know the network configuration at compile-time. Although most programs may be run on the transputer with minimal changes, to take full advantage of multiple processors it is usually necessary to redesign the program to some extent. Fortunately, the redesign required for most renderers/ray-tracers is fairly trivial. The porting process is made easier by a large number of run-time error requesters - eg an attempt to put a message to an invalid port will result in a requester detailing the processor, task name, error, and other pertinent information. We are currently in negotiation with INMOS to port their compiler to the amiga - our ideal would be to bundle their compiler with the board, but obviously we are dependent upon them for this, so no promises yet.... On the plus side, we are committed to providing a high level of support to our customers, and will be setting up an email list for techical support and general discussion of the product and related topics. Availability ------------ We hope to have the board out by Christmas - maybe even by the end of November. There will also be a T9000 board with approximately 10 times the performance but it is unlikely that this will be out in less than a year. Neil -- Neil MacMullen Vc. (1-403) 264-2338 U.S. Cybernetics Vc. (1-403) 289-0252 Email: neil@powerstor.cuc.ab.ca Fax: (1-403) 282-1238 ----- End Included Message ----- Article 52777 of comp.sys.amiga.hardware: Path: news.csos.orst.edu!flop.ENGR.ORST.EDU!rutgers!usc!howland.reston.ans.net!xlink.net!fauern!uni-regensburg.de!news.uni-regensburg.de!c5039 From: c5039@rrzc1a.rz.uni-regensburg.de (Harald Backert) Newsgroups: comp.sys.amiga.hardware Subject: Re: WARP Transputer question Message-ID: Date: 17 Oct 93 16:16:23 GMT References: <29q63i$bvr@nnrp.ucs.ubc.ca> Organization: Universitaet Regensburg, Germany Lines: 34 NNTP-Posting-Host: rrzc1.rz.uni-regensburg.de In-reply-to: jmacleod@unixg.ubc.ca's message of 17 Oct 1993 01:11:14 GMT In article <29q63i$bvr@nnrp.ucs.ubc.ca> jmacleod@unixg.ubc.ca (James Macleod) writes: I was reading a magaizing that had a short article on the WARP card. It said that the card would be out sood with a 30MB...<---what does that mean? What are transputers? Are these things different from CPUs? Is anyone going to buy these things? ( that is if there is software for them..) Wasn't it 30 MHz? Anyway, 30 MB RAM is a) quite unusual and b) quite expensive. Transputers are normal CPUs (just like any other RISC-CPU), but they have 4 so-called links, which they use to communicate with each other or with other 'normal' computers. Each can move data with 20 MBit/s (1.8 MB/s uni- and 2.3 MB bidirectional). And since they use DMA, the core processor is not slowed down by much. The instruction set of these chips is very unusual. All instructions are exectly one byte in size. But transputers use a very clever scheme to allow operands and instructions, which are more than 4 bit in size. But as long as one does not program them in assembler, one does not care. It's interesting and funny though. The FPU in the T8xx-series ist quite fast (~3 MFlops). Newer chips like 8048 are faster, but hey, transputers are quite old (~ 6 years). And one can buy 20 T8xx, which are linked via its links. Do this with a bunch of other CPUs, and you have trouble :-) Btw, I would buy one, if it's payable. Bye, Harald Article 52870 of comp.sys.amiga.hardware: Path: news.csos.orst.edu!flop.ENGR.ORST.EDU!ogicse!hp-cv!sdd.hp.com!swrinde!cs.utexas.edu!uunet!munnari.oz.au!metro!dmssyd.syd.dms.CSIRO.AU!its.csiro.au!mel.dit.csiro.au!etrog!m892994 From: m892994@hpc.citri.EDU.AU (Steven McLean) Newsgroups: comp.sys.amiga.hardware Subject: Re: WARP Transputer question Message-ID: <1993Oct18.060527.757@etrog.se.citri.edu.au> Date: 18 Oct 93 06:05:27 GMT Article-I.D.: etrog.1993Oct18.060527.757 References: <29q63i$bvr@nnrp.ucs.ubc.ca> Sender: news@etrog.se.citri.edu.au Organization: RMIT CSE High Performance Computer Systems (CITRI) Lines: 44 In article , c5039@rrzc1a.rz.uni-regensburg.de (Harald Backert) writes: |> In article <29q63i$bvr@nnrp.ucs.ubc.ca> jmacleod@unixg.ubc.ca (James Macleod) writes: |> |> I was reading a magaizing that had a short article on the WARP card. It |> said that the card would be out sood with a 30MB...<---what does that mean? |> What are transputers? |> |> Are these things different from CPUs? |> |> Is anyone going to buy these things? ( that is if there is software for |> them..) |> |> Wasn't it 30 MHz? Anyway, 30 MB RAM is a) quite unusual and b) quite |> expensive. |> |> Transputers are normal CPUs (just like any other RISC-CPU), but they have |> 4 so-called links, which they use to communicate with each other or with |> other 'normal' computers. Each can move data with 20 MBit/s (1.8 MB/s |> uni- and 2.3 MB bidirectional). And since they use DMA, the core processor |> is not slowed down by much. |> |> The instruction set of these chips is very unusual. All instructions are |> exectly one byte in size. But transputers use a very clever scheme to |> allow operands and instructions, which are more than 4 bit in size. |> But as long as one does not program them in assembler, one does not care. |> It's interesting and funny though. |> |> The FPU in the T8xx-series ist quite fast (~3 MFlops). Newer chips like 8048 |> are faster, but hey, transputers are quite old (~ 6 years). And one can |> buy 20 T8xx, which are linked via its links. Do this with a bunch of other |> CPUs, and you have trouble :-) You can with the TMS320C40 DSP chip! It has 6 20Mbyte links (120Mbyte/sec total), and can do 50MFlop (peak). But it costs quite a lot (I've heard $1000 each in quantity). I've heard of people replacing 28 transputers with one C40 chip and it wasn't even fully loaded either! DSPs are fairly powerful. Steve... |> |> Btw, I would buy one, if it's payable. |> |> Bye, Harald |> Article 52930 of comp.sys.amiga.hardware: Path: news.csos.orst.edu!flop.ENGR.ORST.EDU!ogicse!netnews.nwnet.net!news.clark.edu!spool.mu.edu!caen!batcomputer!munnari.oz.au!bruce.cs.monash.edu.au!trlluna!titan!rhea!aduncan From: aduncan@rhea.trl.OZ.AU (Allan Duncan) Newsgroups: comp.sys.amiga.hardware Subject: Re: WARP Transputer question Message-ID: <1993Oct19.000357.16443@trl.oz.au> Date: 19 Oct 93 00:03:57 GMT Article-I.D.: trl.1993Oct19.000357.16443 References: <29q63i$bvr@nnrp.ucs.ubc.ca> Sender: root@trl.oz.au (System PRIVILEGED Account) Organization: Telecom Research Labs, Melbourne, Australia Lines: 25 From article <29q63i$bvr@nnrp.ucs.ubc.ca>, by jmacleod@unixg.ubc.ca (James Macleod): > > I posted this question in amiga.graphics, but I thought it might be better > asked here. > > I was reading a magaizing that had a short article on the WARP card. It > said that the card would be out sood with a 30MB...<---what does that mean? > What are transputers? > > Are these things different from CPUs? These are CPUs conceived in England, and therefore unacceptable to mainstream computing in the USA (even though the first silicon was done in the US). The US multi-processor people instead have persisted in trying to weld together CPUs that weren't really designed for it, and have wasted several years as a result. And no, I don't come from England, but as a resident of neither I can step back and see the wood amongst the trees. No smiley. Allan Duncan ACSnet a.duncan@trl.oz (+613) 253 6708 Internet a.duncan@trl.oz.au Fax 253 6664 UUCP {uunet,hplabs,ukc}!munnari!trl.oz.au!a.duncan Telecom Research Labs, PO Box 249, Clayton, Victoria, 3168, Australia. Article 52880 of comp.sys.amiga.hardware: Path: news.csos.orst.edu!flop.ENGR.ORST.EDU!ogicse!hp-cv!sdd.hp.com!math.ohio-state.edu!howland.reston.ans.net!pipex!uknet!mcsun!sun4nl!hacktic!blackhl.hacktic.nl!daniel From: daniel@blackhl.hacktic.nl (Daniel Ockeloen) Newsgroups: comp.sys.amiga.hardware Subject: Re: WARP Transputer question Message-ID: Date: 17 Oct 93 18:59:00 GMT Article-I.D.: blackhl.gate.2V8kBc1w165w References: Organization: Black Hole BBS/HIN Lines: 53 X-Newsreader: Rnf 0.77b3 c5039@rrzc1a.rz.uni-regensburg.de (Harald Backert) writes: >In article <29q63i$bvr@nnrp.ucs.ubc.ca> jmacleod@unixg.ubc.ca (James Macleod) writes: > >Transputers are normal CPUs (just like any other RISC-CPU), but they have >4 so-called links, which they use to communicate with each other or with >other 'normal' computers. Each can move data with 20 MBit/s (1.8 MB/s >uni- and 2.3 MB bidirectional). And since they use DMA, the core processor >is not slowed down by much. Thats true for the real 'transputer' by inmos (T8xx) of a few years ago, the newer ones like the T9000 go much faster and/or have more com. ports for example the TMS320C40 will give you 6 Byte-wide ports, 2 global mem ports and a jtag ... TI claims ( i know better ;-) ) speeds of up to 320mb/sec and 275Mops. both the T9000 and the C40 seem about 25-30 times faster in real life. >The instruction set of these chips is very unusual. All instructions are >exectly one byte in size. But transputers use a very clever scheme to >allow operands and instructions, which are more than 4 bit in size. >But as long as one does not program them in assembler, one does not care. >It's interesting and funny though. This is true, but if you want a really fast system (not flexible) you beter go down to asm again. ( really cool to do with all the delayed jumps, multiplexing the status regs and sorts ;-) ). >The FPU in the T8xx-series ist quite fast (~3 MFlops). Newer chips like 8048 >are faster, but hey, transputers are quite old (~ 6 years). And one can >buy 20 T8xx, which are linked via its links. Do this with a bunch of other >CPUs, and you have trouble :-) im not sure about the T9000 but the C40 will do 2 floats in one cycle (at 40 bits) giving it 50Mflops a chip. >Btw, I would buy one, if it's payable. one of them ??? whats the use.... >Bye, Harald The best part about these chips is that they are _really_ cool one of our home-made C40 test boards takes 2.3 Watts (if you keep in mind that most of this juice will go to the glue logic) it simple won't get hot. Try that with a pentuim or 68040 ;-). Daniel. .......................................................................... .. Daniel Ockeloen . Internet daniel@blackhl.hacktic.nl .. .. Black Hole BBS . Tel +31-30-940197 (300-14400) .. .. Utrecht, The Netherlands . Using A1000, A4000/40, 386/40 .. .......................................................................... Article 52957 of comp.sys.amiga.hardware: Path: news.csos.orst.edu!flop.ENGR.ORST.EDU!ogicse!netnews.nwnet.net!news.clark.edu!spool.mu.edu!howland.reston.ans.net!pipex!sunic!news.funet.fi!funic!nic.funet.fi!sheffield.ac.uk!D.Lamptey From: D.Lamptey@sheffield.ac.uk Newsgroups: comp.sys.amiga.hardware Subject: Re: WARP Transputer question Message-ID: <9310191421.AA01461@ntsc.shef.ac.uk> Date: 19 Oct 93 18:21:15 GMT Article-I.D.: ntsc.9310191421.AA01461 Sender: root@nic.funet.fi (The FUnny NET guru) Organization: Finnish University & Research Network Lines: 118 Content-Identifier: Re: WARP Tran... Alternate-Recipient: Allowed X400-Mts-Identifier: [/PRMD=UK.AC/ADMD= /C=GB/;<9310191421.AA01461@ntsc.shef.ac] X400-Content-Type: P2-1984 (2) X400-Recipients: non-disclosure:; X400-Originator: D.Lamptey@sheffield.ac.uk X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed; Hello, I have spoken to the developers of WARP quite a few times. The basic idea at the moment is to use the multi-processing/multi-tasking capabilities of the transputer for gfx based applications on the AMiga. One key idea is that the application will be seamlessly integrated into the AmigaDOS environment. To this extent they have developed a custom transputer OS which looks like AmigaDOS to run on the transputers on board. And also source code should compile for the warp board or the amiga with no source code changes. Thus impulse/imagefx should be able to rapidly produce prototype ports without getting down to transputer specifics. The multi- tasking concepts sit rather easily on Amiga users, and the transputer is good at it. (Task switching takes 630 nanosecs on the t800!) Anyway, thats almost all I know. Derryck. _____________________________________________________________________ National Transputer Support Centre, Derryck Lamptey, MSc(Eng) (University of Sheffield) (D.Lamptey@sheffield.ac.uk) 5 Palmerston Road, Sheffield S10 2TE South Yorkshire, U.K. (NTSC@sheffield.ac.uk) Telephone: (+44/0) 742 768740 Facsimile: (+44/0) 742 727563 "use e-mail: save a tree" _____________________________________________________________________ p.s: Somebody said: ]|> ]|> Transputers are normal CPUs (just like any other RISC-CPU), but they have ]|> 4 so-called links, which they use to communicate with each other or with ]|> other 'normal' computers. Each can move data with 20 MBit/s (1.8 MB/s ]|> uni- and 2.3 MB bidirectional). And since they use DMA, the core processor ]|> is not slowed down by much. ]|> Pedantic here, but it is not slowed down at all. I do not think this is so with the C40 series.. ]|> are faster, but hey, transputers are quite old (~ 6 years). And one can ]|> buy 20 T8xx, which are linked via its links. Do this with a bunch of other ]|> CPUs, and you have trouble :-) ] The t2/t4/t8 series are rather dated. But you can happily hook up over a thousand of them without the usually crippling bottleneck (if your topology is optimal. Meaning you do not expect a communication from a to b to be routed through 50 nodes! ]You can with the TMS320C40 DSP chip! It has 6 20Mbyte links (120Mbyte/sec total), ]and can do 50MFlop (peak). But it costs quite a lot (I've heard $1000 each in ]quantity). I've heard of people replacing 28 transputers with one C40 chip and C40s and Transputers are essentially different beasts. One of the boards cur- rently available is a c40/t800 board, the c40 concentrating on the dsp stuff and the t8 doing the comms.. ] ]Thats true for the real 'transputer' by inmos (T8xx) of a few years ago, ]the newer ones like the T9000 go much faster and/or have more com. ports for Yes. The t9000 does go much faster, executing code compiled for the t8 at typically 10 times faster. (Well, O.K. the clock speed has to be higher 2.5 times). Optimized t9 code is faster still. I am trying not to get too deep into this thread... Peak performance is something like 200 mips/ 25 mflops. "Improvements over IMS T805" "In addition to executing several instructions each cycle, the number of cycles required to perform many arithmetic and logical operations has been reduced from previous transputers by adding extra hardware. This, combined with the faster clock speed and new micro-architecture, means a ten-fold increase in speed over the IMS T805. In addition there is improved support for error handling, and protecting code and data from the errant behavior of a program. The IMS T9000 provides better access to the transputers scheduling mechanism, making it easier to implement software kernels for a particular processing model." No. The t9000 does not have more communication ports. It uses a communications subsystem (VCP) Virtual Channel Processor to produce up to 64k virtual channels out of the existing links, and takes care of all the message-passing routing issues, error-handling, etc. (E.g if one link breaks down, routing the info other ways round the system). the bandwidth is up as well, Memory bandwidth is something like 200Mb/sec and the combined data rate out of the links (each can proceed independently) is something like 80 MB/sec. ] ]im not sure about the T9000 but the C40 will do 2 floats in one cycle (at ]40 bits) giving it 50Mflops a chip. ] The T9000's execution unit uses a pipelined superscalar-like architecture to process as many as 40 instructions simultaneously, reaching a peak execution rate of 200 Mips at 50 MHz. At the head of the pipeline is a 32-instruction fetch-ahead buffer. From this buffer, a hardware scheduler, called an instruction grouper, picks instructions and groups them together for dispatch. The pipeline can accept one group-up to eight instructions on each cycle. (50-80 mips is the sustained figure, however... Not really as savage as the C40.) ]>Btw, I would buy one, if it's payable. ] t9000's cost in the region of US$600. Article 53001 of comp.sys.amiga.hardware: Path: news.csos.orst.edu!flop.ENGR.ORST.EDU!ogicse!netnews.nwnet.net!news.clark.edu!spool.mu.edu!howland.reston.ans.net!pipex!sunic!news.funet.fi!funic!nic.funet.fi!sheffield.ac.uk!D.Lamptey From: D.Lamptey@sheffield.ac.uk Newsgroups: comp.sys.amiga.hardware Subject: Transputer information... (LONGISH, but necessary!) Message-ID: <9310200822.AA01725@ntsc.shef.ac.uk> Date: 20 Oct 93 12:22:35 GMT Article-I.D.: ntsc.9310200822.AA01725 Sender: root@nic.funet.fi (The FUnny NET guru) Organization: Finnish University & Research Network Lines: 976 Content-Identifier: Transputer in... Alternate-Recipient: Allowed X400-Mts-Identifier: [/PRMD=UK.AC/ADMD= /C=GB/;<9310200822.AA01725@ntsc.shef.ac] X400-Content-Type: P2-1984 (2) X400-Recipients: non-disclosure:; X400-Originator: D.Lamptey@sheffield.ac.uk X400-Received: by /PRMD=UK.AC/ADMD= /C=GB/; Relayed; Hello. A lot has been said about transputers in the last few weeks, and alothough this is not the group for it, (try comp.sys.transputer) this is some info on the latest transputer offering. You'll have to contact me e-mailly (or via comp.sys.transputer) to get more information. Hopefully, this post will cut down the number of queries we get and widen our understanding of things) (stuff follows There is also some info about the transputer concept) Yours Derryck. @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ @ @ Derryck Lamptey, MSc(Eng) e-mail... @ @ National Transputer J/IP: D.Lamptey@sheffield.ac.uk @______ @ Support Centre, also: co2dll%sunc.shef.ac.uk @/ / @ Univ, of Sheffield, U.K. or: lamptey@acse.shef.ac.uk @ / @ or: derryck@dcs.shef.ac.uk @ / @ @ / @ "The great thing aboout standards: @ / @ THERE ARE SO MANY TO CHOOSE FROM" ________ @/ @ Voice (+44) 742 309165 \ \ \ @ @ \ \ \ @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@\ \ \@@@@@@@@ \ \ \ / \ \ \/ -------- - ------------------------------------------------------------------------- Introducing the INMOS IMS T9000 family The INMOS IMS T9000 is the latest member of the transputer family. It is designed to provide far higher performance and greatly improved communications facilities. INMOS has used advanced CMOS technology to integrate a 32-bit integer processor, a 64-bit floating point processor, 16 Kbytes of cache memory, a communications processor and four high bandwidth serial communications links on a single IMS T9000 chip. The IMS T9000 transputer excels in real-time embedded applications, delivering exceptional single processor performance and scaleable multiprocessor capability. The IMS T9000 is binary compatible with previous transputers. It extends the transputer range, making it easy to upgrade and complement existing transputer systems. There is extensive, industry standard software support for all members of the transputer family; this includes high level language compilers, systems software (such as real time operating systems) as well as an extensive range of development tools. - ----------------------------------------------------------------- Performance It is essential that any microprocessor family designed for the embedded system market provides the required performance at low cost. The transputer family includes a 16 bit processor, a 32 bit range of fast integer and floating point processors and now, the highest performance member of the family, the IMS T9000. These are all designed to make it easy to design low cost, high performance systems. ** the IMS T9000 transputer boasts exceptional single processor performance; the new superscalar CPU is capable of a peak performance of 200 MIPS and 25 MFLOPS. ** the IMS T9000 offers sub-microsecond interrupt response and context switch times, making it ideal for high performance real-time systems. ** the four IMS T9000 communication links provide a total of 80 Mbytes/second bidirectional bandwidth. ** the interprocessor communications architecture gives scaleable performance - the ability to increase the performance of a system by adding more processors. ** the IMS T9000 implementation makes it easy for compilers to fully exploit the superscalar performance using a range of industry standard programming languages. ** the IMS T9000 offers supercomputer performance at an embedded systems price. - ----------------------------------------------------------------- Multiprocessing For applications that demand performance that single processors cannot provide, the IMS T9000 has complete on-chip support for multiprocessing: ** the transputer architecture includes instruction level support for the creation and scheduling of any number of concurrent processes ** the transputer instruction set includes instructions for communicating between concurrent processes. The same instructions are used to communicate between processes running on a single transputer and between processes running on separate transputers. ** the presence of a dedicated communications processor which operates concurrently with the main processor, makes interprocessor communications flexible and efficient. The integration of the communications system on-chip makes it easy to write programs for multiprocessor systems ** all the IMS T9000 transputers in a system can be initialized, loaded with code and monitored for errors through a completely independent communications system. - ----------------------------------------------------------------- Communications support devices The IMS T9000 transputer is complemented by a range of communications peripherals that extend the communications capabilities of the IMS T9000. The IMS C1XX family ensures that any size of IMS T9000 system can be constructed, connecting first generation and second generation transputers and providing an interface to the outside world. ** the IMS C104 is a complete routing switch on a single chip. The IMS C104 connects 32 links to each other via a 32 by 32 way, non-blocking crossbar switch with sub-microseco nd latency. This allows simple, fast communication between IMS T9000 transputers that are not directly connected. Multiple IMS C104s can be connected together to make larger and more complex networks, linking any number of IMS T9000 transputers, or any other devices that use the link protocol. ** the IMS C100 system protocol convertor converts between the first generation transputer links and control signals and the new IMS T9000 protocol.The IMS C100 provides an inter-networking solution for transputer systems, allowing networks to be constructed using the optimum mix of transputers to satisfy processing power, communication bandwidth and system cost. - ----------------------------------------------------------------- Software The success of any microprocessor is determined as much by the quality of its software development tools as by any other feature. INMOS has over a decade of experience in developing software tools for transputers and for multiprocessing systems. The range of compilers and powerful development tools support all the requirements of software developers. ** instruction set compatibility with the first generation transputer family means that the IMS T9000 transputer has inherited a significant range of development and application software. ** the transputer toolset is a set of development tools for programming, configuring and debugging mixed transputer systems. The toolset is available on a variety of host computers including: IBM PC NEC PC VAX Sun 3 Sun 4 ** INMOS provides a powerful, interactive debugger for debugging programs running on networks of transputers. This provides full source level debugging with the ability to set breakpoints in any process and on any processor, and then to examine the state of the stopped process as well as the low-level state of the processor. For fast time to market, and to satisfy the diverse programming requirements of different application areas, the toolset can be used with a variety of industry standard compilers, all with major support for multiprocessing. The IMS T9000 is supported by a range of compilers including: ANSI C C++ Fortran occam Ada ** system software support for the IMS T9000 reflects the requirements of the embedded systems marketplace. A range of operating systems and real-time kernels are available for the transputer including: C Executive VRTX CHORUS distributed Unix This impressive array of development tools, industry standard compilers and system software satisfies the demands of the embedded systems market. It also ensures that the user can benefit from a significant reduction in the critical time to market. - ----------------------------------------------------------------- Applications The transputer family provides unprecedented price/performance solutions for a wide range of embedded systems applications. The IMS T9000 transputer has been specifically developed to satisfy the requirements of three segments of the embedded systems market: ** the imaging market comprises applications that involve the generation, manipulation and transmission of image data. Such applications include: Laser printers Graphics systems Image processing systems Industrial inspection systems Robotics ** the embedded computing market comprises applications that are run within a computer environment and add overall performance and functionality to the computer system. Such applications include: Application accelerators: (graphics, numerical, scientific, DTP) Disk arrays and high performance file servers Databases X terminals Supercomputers Factory automation ** the embedded communications market can be segmented into two main areas that require high performance microprocessors. These are: Networking: low cost LAN interfacing - FDDI, Ethernet; internetworking systems - bridges, gateways and routers. Packet switching systems. The IMS T9000 transputer is highly applicable to the communications market due to its integrated architecture combining high performance CPU and communication links with a packet based protocol. The IMS C104 packet routing switch has been designed to support the IMS T9000, and is useful in a range of telecommunications switching applications. The transputer family provides a range of price/performance solutions for all the above applications. - ------------------------------------------------------------------------- Copyright C 1993 Tom Bjorkholm This text might be freely copied and redistributed as long as this copyright message is included. Comments, corrections, suggestions and additions are welcome. Please send an email message to: tbjorkho@ra.abo.fi WARNING: ABSOLUTELY NO WARRANTY This text is not guaranteed to be accurate or applicable. If this text is misleading and you destroy your computer (or career) by following it, that is your problem. - ------------------------------------------------------------------------- A. Introduction Level A1. Flynn's taxonomy Let's start with an overview of different parallel processing systems to see where the transputer systems fit in. Michel J. Flynn's taxonomy for classifying transputers dates back in 1972. It is the most common way to classify (parallel) computers. A computer can have either a single "stream" of data, or multiple data streams. Orthogonally a computer can have either a single stream of instructions, or multiple streams. This gives us a classification in four groups: | Single instruction | Multiple instruction | stream | streams - ------------------------+--------------------+--------------------- Single data stream: | SISD | MISD - ------------------------+--------------------+--------------------- Multiple data streams: | SIMD | MIMD - ------------------------+--------------------+--------------------- The single instruction, single data stream (SISD) computer is the normal, sequential (von Neumann) computer. There are no multiple instruction, single data stream (MISD) computers. Maybe some day someone invents one ;-) Single instruction, multiple data stream (SIMD) computers have been around for a while. Famous computers like the AMT Distributed Array Processor, the Connection Machine, and the Maspar MP-1 are all SIMD. SIMD computers have a (possible large) number of processing elements that all simultaneously execute the same instruction, but on different data sets. Multiple instruction, multiple data stream (MIMD) computers are more flexible than SIMD computers. In a MIMD computer there is a number of processing elements that all execute their own code on their own data sets. Systems built from transputers are MIMD, other famous MIMD systems are Sequent and iPSC/2. Both SIMD and MIMD computers can be sub-divided into two groups: Shared memory systems and distributed memory systems. In a shared memory system there is one single shared RAM memory for all processing elements. Every processor can access any memory location, so there is no need for message passing. A serious problem with shared memory systems is that only one processor at a time can use the memory bus. Thus the memory bus becomes a bottle neck, and the system scales poorly to really big systems. In the distributed memory system every processing element has its own memory. In this way the memory bus does not become a bottle neck. The drawback with this is that processing elements (processors) cannot read each others memory. Thus all information exchange between processing elements has to be done by explicit message passing. The transputer systems use distributed memory. Of course, there are also transputers that are used in single processor systems (SISD). For example as process controllers. A2. The Transputer The word transputer is derived from TRANSmitter and comPUTER. It is a microprocessor made by Inmos Ltd. Compared to other microprocessors the transputer has two very special features: it has on chip serial links for "talking" to other transputers, and it has hardware support for timesharing. The transputer family include four different series of transputers. They are shown below together with their peek performance. (Actually the peek performance is very optimistic, as always.) T2-series: 16 bit transputer No math coprocessor MIPS: 30 Context switch: 630 ns Link speed: 5/10/20 Mbit/s (selectable) T4-series: 32 bit transputer No math coprocessor MIPS: 30 MFLOPS: 0.3 - 0.5 Context switch: 630 ns Link speed: 5/10/20 Mbit/s (selectable) T8-series: 32 bit transputer On chip math coprocessor MIPS: 30 MFLOPS: 2 Context switch: 630 ns Link speed: 5/10/20 Mbit/s (selectable) T9-series: 32 bit transputer On chip math coprocessor Not yet officially released Has hardware support for virtual channels MIPS: 200 MFLOPS: 25 Link speed: 160 Mbit/s Context switch: < 1 micros (Notice: These are marketing values, for a product that is not yet available. They might change.) A3. Communication: Links and channels [From this on machine instructions for doing different things will be mentioned. Do not worry - everything can be done in high level languages. You are not supposed to program the transputer in assembly. The machine instructions are mentioned mostly to stress the fact that the transputer can do certain things in one machine instruction, that requires big driver programs on other processors.] The key idea in the design of the transputer is that it should be programmed with communicating sequential processes (see the reference to Hoare's book below). There are two machine instructions on the transputers for communication "in" and "out", that both take three arguments: the memory address to communicate at, the address of the message buffer, and the message length. (Actually there are a few more instructions available, but do not worry about those now.) These machine instructions are translated to different constructs in high level languages, but the key feature is there. Any word in memory (except for a few special memory locations) can work as a channel between two processes. A channel is a one way communication between (exactly) two processes. Every channel communication is synchronising. If process A tries to send a message (with out) to process B on channel C, it will block until B does a receive (with in) on channel C. If the receiver is the first to try to communicate, the reverse will happen: the receiver will block until the sender sends the message. It is important to remember that the channel is used by exactly one sender and one receiver. If several processes wants to send something on the same channel, there has to be a multiplexer process inbetween. On every transputer there is four special memory addresses that will cause the message to be sent on an external link, instead of waiting for a process on the same processor. Likewise, there are four special memory addresses for receiving messages from the external links. The links are bidirectional, so each link holds two channels - one in each direction. The link channels are used in exactly the same way as the intraprocessor channels: i.e. the same machine instructions are used, and the communication is blocking. The links are DMA driven, so the processor can work on other processes while the communication completes. The link protocol on the T2, T4 and T8-series of transputers is a byte stream protocol. The hardware never communicates the size of the messages, that is left to the programmer (or OS). In this way it is possible (but not recommended) for the sender to send one message with 1 KB of data and for the receiver to receive two messages of 0.5 KB each. This is sometimes used to simplify multiplexers, but more often it is a programming error if it occurs. The links are high speed serial links designed for short distance communication. The specification for the simple twisted pair cable links is 30 cm, generally universities are stretching the specs a bit and twisted pair cables of 2 - 4 meters are not uncommon. The T9-series of transputers has a somewhat different link specification. The T9-links are designed for routing, so the base unit of communication is the packet, not the byte. The T9-links do also have a different electronical specification: they are differential to support reliable communication at higher speeds. A4. Timesharing The transputer has a wonderfully simple scheme for process scheduling implemented in hardware. The hardware manages two lists of process pointers in memory. One list keeps the pointers to all high priority processes, and one the pointers to all low priority processes. These lists keep only pointers to processes that are ready to run. Processes that are blocked are managed elsewhere. The first high priority process runs until it has completed, or blocked. After that the next high priority process will run until it completes, and do on. The low priority processes will run only if no high priority process can run. Because of this behaviour you should never do computation in a high priority process. (Inmos has somewhere stated that high priority should only be used for processes that will complete within 1 microsecond.) Low priority processes are given a time slice of one "tick" (64 microseconds). (As long as there are no high priority processes:) The first process in the low priority list will run for on "tick", after that it will be descheduled at the first scheduling point in the program. At the descheduling the instruction pointer (program counter) is stored on the stack and the stack pointer is put at the end of the low priority process pointer list, i.e. round robin scheduling is achieved. No registers are saved at the descheduling. This is achieved by allowing descheduling only at special instructions, which are defined to trash all registers. These instructions are called descheduling points, the most common of them are "jump", "in", "out" and "loop end". The only thing that identifies the descheduled process is the pointer to the stack with the program counter, and the stack variables. As the stack is always word aligned, the least significant bit of the stack pointer can be used to indicate priority ( 0 for high, and 1 for low). Whenever a high priority process becomes ready to run it immediately deschedules the running low priority process (without waiting for a descheduling point). In this case the registers of the low priority process is saved (either at a special memory address or in shadow registers, depending on the transputer model). High priority processes are sometimes called urgent processes and low priority processes called normal, or not urgent. A5. The words "process", "task" and "thread" This far the word "process" has been used for something that has its own program counter, and own variables. This is also the normal use of the word. However, one should be aware of the fact that the word "process" has a few other meanings, too. The designers of the occam programming language (the first one to be supplied with the transputer) chose to name their procedures processes. In the abstract reasoning about the program this makes sense: processes might follow after each other, or work in parallel. The word "task" usually refers to a traditional main program with its own variables. The only way a task can communicate with the rest of the world is though channels. In a parallel program there are usually many tasks. The word "thread" refers to a function or procedure that is started by the main program, but runs in parallel with the main program. (The main program itself is a thread.) Each task consists of at least one thread. The threads within a task can share variables. (What operation that are allowed on the shared variables varies from language to language). In occam a thread is splitted into two or more threads by the PAR statement. It is not clear weather the word "process" refers to a thread or to a task. A hardware designer usually means a thread, and an OS designer usually means a task, when he says "process". A6. Iserver, Afserver, Pserver The transputers communicate by the means of channels, which sometimes are links. The transputer system is often connected to a host computer (which can be a PC, Sun or VAX) for I/O. For this I/O to work a process is needed in the host computer that communicates on the link channels. This process is called the iserver (if supplied by Inmos), the afserver (if supplied by 3L) or the pserver (if supplied by PACT). The iserver (or pserver or afserver) has a specified protocol for communication with the transputer program. By using this protocol the transputer program can request that the iserver outputs something to the screen, reads a file, or does some other kind of I/O. It is also the iserver that resets and boots (see below) the transputer system. A7. Languages There is a great variety of programming languages available for the transputer by different vendors (see the compiler survey summary): occam, C, fortran, Pascal, Ada... When choosing the language two important things should be remembered: 1) Use a language that you are comfortable with. 2) Never try to convince someone that you choice of language is better. That will only result in hurt feelings and flame wars. Despite the previous paragraph there are some things that talk in favour of some of the languages, in some circumstances. It is obvious that if a group should work together closely on some programming or computer research project, they should all choose the same language. Occam was the first language supplied with the transputer. It was especially designed for CSP. Thus the parallel algorithms are very clearly expressed in occam. Occam is also a very good language if you want to do formal reasoning about your programs, as the language deliberately lacks some features that make formal reasoning difficult (like dynamic memory allocation). Whether or not you choose occam as your programming language, you should learn it if you want to really join the transputer community -- occam is considered general knowledge. There are several flavours of C for the transputer. The difference is mainly in how they have implemented the threads and the communication. Several C versions use function calls to hide these, while one C version has extension in the language itself. C is mainly used by "engineers" on the transputer. The main reason for using C is often that these same persons have to program other computers/devices in C. Buy using C they can use the same language on all systems, which increases their productivity. The main reason for using fortran seems to be that one wants to port some sequential application written in fortran to the transputer. The syntax of the different languages is not covered here. This information is found in the compiler manuals and in textbooks. A8. Porting It seems to be quite common that professors on science (not Computer Science) laboratories wants some student to port an existing program to a transputer system (as M.Sc. theses or ...). Be aware! Porting an application from a sequential system to a transputer system requires extensive knowledge about how the program works. I, and many others, have found that it is often easier to write a new program from scratch, than to port an existing program. Especially, if you haven't written the sequential program yourself. A9. Alternate Sometimes one wants a program to listen to several channels and do the receiving from the first one, that can supply a message. The transputer provides hardware support for this, too. It is done by a combination of several special machine instructions that form an alternate construct. (Exactly how this is done in assembler falls outside the scope of the Introduction Level). If several channels becomes ready for communication almost simultaneously, the transputer alternate construct can choose to communicate at any one of these channels. I.e. the first one to be ready is not guaranteed to be selected. The occam ALT statement is equivalent to the low level alternate construction described above. A10. Timers, sleeping and wakeup The transputer has two on chip timers. The high priority timer that is incremented once every microsecond, and the low priority timer that is incremented once every 64:th microsecond. The timer (of the same priority as the current thread) can be inspected. There is also a special machine instruction "tin" (timer input) that will block the current thread until the timer is "after" a specified time. The tin instruction is very similar to the "in" instruction, hence the similar naming. The occam construct "clock ? AFTER t" does a "tin t", i.e. it waits until the timer value is after t. Using these kind of constructs it is very easy to sleep for a specified time. This, combined with the timesharing and the channels, makes it easy to program real time systems on the transputer. The timer input (wait) is very similar to channel input. Just as you might expect it is also possible to include a timer in the alternate constructs. On PACT C or in occam the ALT construct remains syntactically the same, one channel input is just replaced by a timer input. This is how timeouts in communication is implemented. A11. Events (Interrupts) The transputer has an event pin, that is connected to a channel word in memory. A process can wait for an event by doing a "in" on the event channel. This is how interrupts are implemented on the transputer. (The process, that listens to the event channel, never receive any real input - it is just unblocked. Thus it makes most sense to try to input a byte.) A12. Resetting and booting The transputer has one reset and one analyse pin. The transputer is reset by pulsing the reset pin. If the analyse pin is held high when the reset pin is pulsed, the transputer is analysed instead of reset. The transputer is reset reset in order to initialise its internal state and memory interface, and then to boot. It is analysed in order to investigate its internal state. When the transputer is analysed, it stops operation in a way that preserves as much information as possible about its state. When the transputer is reset (or analysed) it starts to boot. If the "boot from ROM" pin is held high the transputer will boot from ROM, otherwise it will boot from a link. When booting from a link the transputer initially listens on all links to determine where boot code is comming from. If the fist byte to be received on a link is 0, then a word of address is input followed by a word of data to put on that address. The transputer then returns to its previous state. If the value of the first byte is 1, then a word of address is also input, but this address is read. And the data is output on the link. The transputer then returns to its previous state. If the first byte received is 2 or greater then that many bytes of code will be input from the link and placed in memory starting at MEMSTART. This code will then be executed. As (almost) all useful transputer programs are longer than 256 bytes, this initial code is a bootstrap code that loads the real program and then transfers control to the real program. This bootstrap code is automatically inserted by the linker (or configurer) for all high level languages. More information about resetting and booting can be found in the "Transputer Instruction Set" (see below) on page 73 ff. A13. Shared variables Threads can share variables, as far as the hardware is concerned. Some languages/compilers (like occam) restricts this sharing for cleaner semantics, while others like C allow free use of the shared variables. Reading of shared variables is totally safe. However if a shared variable is to be updated (e.g. incremented) by several processes the access to the variable has to protected by semaphores, so that at most one thread is updating the variable at any instance. (Write access to shared variables is not allowed in occam.) A14. Free Software There is some free software available for the transputer. See the FTP sites lists for information about where to obtain the free software. A15. B004 and TRAM One of the early products from Inmos was the B004 board. This was a PC add in card with one processor, some RAM, and a device driver. The B004 has become a de facto standard. Most PC add in boards today are B004 compatible, as this insures that software will work without modifications. Inmos has launched a complete program of BXXX boards, with different feature, for different architectures. Several years after the B004, Inmos introduced the TRAMs. TRAM is short for TRAnsputer Module. The idea is that a processor and some memory is put on a small card, with a standard interface, the TRAM. There are motherboards that take a number of TRAMs. The user can now build his/her own "Lego" computer by choosing TRAMs with suitable amounts of memory and plugging them into the TRAM motherboard. There are also special TRAMs for ethernet access, SCSI, HPIB etc. With the introduction of the T9000, Inmos is also introducing a new TRAM standard - the HTRAM. A16. Suppliers and Prices A few suppliers are listed here together with the price of their products. This is only included to give an indication about the price level of transputer products - and thus enable non transputer users to see if they can afford a transputer system or not. One should be aware of the fact that unlisted vendors could have competitive prices. Ingenieursbureau Bieware P. O. Box 717 NL-2700 AS Zoetermeer The Netherlands Phone: +31 79 61 09 09 Fax: +31 79 61 55 55 Parallel Programming Education Kits, B004 compatible plug in card for PC's with 2 T400/20 MHz with 1 MB of RAM each. Comes with a limited version of occam 2 and a limited PACT C. Approx. price US$ 1000.- excl. VAT CSA, Computer Systems Architects 950 North University Avenue Prove, Utah 84604 Phone: 1-800-753 4CSA or 1-801-374-2300 Fax: 1-801-374-2306) Build and sell transputer educational kits. Prices range from about US$ 600. Archipel S.A. P.A.E. des Glaisins 1 rue du Bulloz 74940 Annecy le Vieux France Phone: +33 50 64 06 66 Fax: +33 506 40 734 Email: fest@archipel.fr Transputer cards for Sun Sparc Stations. Transtech Parallel Systems Ltd. 17-19 Manor Court Yard Hughenden Avenue High Wycombe Bucks HP13 5RE United Kingdom Phone: +44 494 464 303 Fax: +44 494 463 686 A complete range of transputer products, ranging from PC plug in cards to big systems. Parsytech Computer GmbH Julicher Strasse 338 D-5100 Aachen Germany Phone: +49 241 166 000 Fax: +49 241 166 00 50 A complete range of transputer products, ranging from PC plug in cards to big systems. Inmos Business Center SGS-THOMSON Microelectronics Inc. 2225 Executive Circle P O Box 16000 Colorado Springs Colorado 80935-6000 Phone: 1-719-630-4000, Fax: 1-719-630-4329. All kinds of transputer equipment. Inmos Business Center SGS-THOMSON Microelectronics Ltd. Planar House Parkway Globe Park Marlow Bucks SL7 1YL Phone: +44 628 890 800 Fax: +44 628 890 391 All kinds of transputer equipment. If you need more addresses to Inmos offices worldwide - try the FTP server unix.henca.ac.uk. B. More Advanced Topics Sorry, this section is not yet written. C. Further Reading General notice: The books described here are the books that I have access to. I believe that there are newer versions available for some of the older Inmos books. @book{hoare, Author = "C. A. R. Hoare", Title = "Communicating Sequential Processes", Publisher = "Prentice Hall", Year = 1985} This book describes the "Communicating Sequential Processes" reasoning. It is around this reasoning that the transputer and occam was designed. It is truly a recommended book. @book{inmos:ref, Author = "Inmos", Title = "Transputer Reference Manual", publisher = "Prentice Hall", address = "Hempstead, UK", year = 1988, Note = "ISBN 0-13-929001-X"} A very technical but useful book. It includes memory maps, timing diagrams, pin layout and much more. @book{inmos:t9000, Author = "Inmos", Title = "The T9000 Transputer - Products Overview Manual", publisher = "Inmos", address = "Bristol, UK", year = 1991} @book{may:networks, Editor = "M. D. May and P. W. Thompson and P. H. Welch", Title = "Networks, Routers \& Transputers: Function, Performance and Application", Publisher = "IOS Press", Year = 1993} Two books about the new transputer generation. "The T9000..." is more technical and "Networks..." is more academic in touch. The second one is clearly the easier one to read. @book{inmos:instr, Author = "Inmos", Title = "Transputer Instruction Set, A Compiler Writer's Guide", publisher = "Prentice Hall", address = "Hempstead, UK", year = 1988, Note = "ISBN 0-13-929100-8"} @book{roberts, Author = "John Roberts", Title = "Transputer Assembly Language Programming", Publisher = "Van Nostrand Reinhold", Address = "New York, U. S. A.", Year = 1992, Note= "ISBN 0-442-00872-4" } @misc{plumb, Author = "Colin Plumb", Title = "An Introduction to Transputer Assembly Language", Howpublished = "Distributed as electronic mail by the author in 1988", Year = "1987", Note = "Copyright Cogent Research, Inc."} Three books and one paper on transputer assembly programming. Clearly the assembly programming of the transputer should not be necessary, you can do everything in occam or C - but the interest seems to be there. The Inmos book is the reference that you have to have, but it is somewhat special and not that easy to grasp. Roberts have tried to write a more conventional book on the subject and it is easier to read. However, Roberts has got a few things wrong in his book so cross-check it with the Inmos book. Try to get hold of the paper by Colin Plumb, if you can: It is clearly the best introductory text. @book{gerlach, Author = "Uwe Gerlach", Title = "Das Transputerbuch", Publisher = "Markt \& Technik", Address = "Haar bei Munchen, Germany", Year = 1991, Note = "ISBN 3-87791-019-X" } A book about how to build your own transputer boards for a variety of uses. The book comes with PC plug in transputer board (without components). There are several prints for transputer boards and interface cards in the book. The book also includes a chapter with the most used transputer assembly commands. (In German). @techreport{inmos:iserver, Author = "Bob Green", Title = "Iserver 1.42 Specification", Institution = "Inmos Ltd", Year = 1990, Month = "June", Number = "SW-0102-3", Note = "DRAFT"} This document describes the Inmos Iserver (see above). This is essential if you like to get I/O from your own assembly routines. If you use a normal compiler you can happily let the details of these protocols remain buried in the I/O libraries. @book{inmos:tasystems, Author = "Inmos", Title = "The Transputer Applications Notebook - Systems and Performance", Publisher = "Inmos", Address = "Bristol, U. K.", Edition = "First", Year = 1989} A collection of Inmos technical notes describing various details in hardware, systems, software, applications and performance. A very handy reference book. @book{inmos:databook, Author = "Inmos", Title = "The Transputer Databook", Publisher = "Inmos", Address = "Bristol, U. K.", Edition = "Second", Year = 1989} The ultimate information source for hardware specific data. Includes tables of processor cycles for instructions, pin layout, timings, voltage levels... @book{trew:past, Editor = "Arthur Trew and Greg Wilson", Title = "Past, Present, Parallel", Publisher = "Springer-{V}erlag", Year = 1991 , Address = "Berlin, Germany"} A survey of available parallel computing platforms. Puts the transputer into a perspective. @techreport{barret:occam3, Author = "Geoff Barret", Title = "occam 3 reference manual", Institution = "Inmos", Year = 1992, Note = "Draft - March 31"} A reference manual for the occam language. (Actually for the new version occam 3, the currently used occam compilers use occam 2.) IOS Press in Amsterdam has also published all proceedings of the "World occam and Transputer Users Group", "North American Transputer Users Group", "Nordic Transputer Users Group", "Australian Transputer and occam Users Group" etc. These proceedings show the more academic activities that has involved transputers. - --- Tom Bjorkholm Process Design Laboratory Phone: +358 21 654 863 Department of Chemical Engineering Fax: +358 21 654 479 Abo Akademi University Internet: tbjorkho@ra.abo.fi Biskopsgatan 8 or: tbjorkholm@finabo.abo.fi SF-20500 Abo Bitnet: TBJORKHOLM@FINABO FINLAND Nordunet: ABOVAX::TBJORKHOLM Article 53232 of comp.sys.amiga.hardware: Path: news.csos.orst.edu!flop.ENGR.ORST.EDU!gaia.ucs.orst.edu!news.uoregon.edu!netnews.nwnet.net!news.clark.edu!spool.mu.edu!agate!library.ucla.edu!news.mic.ucla.edu!unixg.ubc.ca!acs.ucalgary.ca!cpsc.ucalgary.ca!debug!lucretia!amerock!randy From: randy@amerock.cuc.ab.ca (Randy Young) Newsgroups: comp.sys.amiga.hardware Subject: Re: WARP Transputer question Distribution: world Message-ID: X-NewsSoftware: GRn 1.16f (10.17.92) by Mike Schwartz & Michael B. Smith Date: 21 Oct 93 10:46:36 MST Organization: Not an Organization Lines: 33 In article <29q63i$bvr@nnrp.ucs.ubc.ca> jmacleod@unixg.ubc.ca (James Macleod) writes: > > I posted this question in amiga.graphics, but I thought it might be better > asked here. > > I was reading a magaizing that had a short article on the WARP card. It > said that the card would be out sood with a 30MB...<---what does that mean? That should actually say 30 MIPS > What are transputers? A transputer is a CPU with special high speed serial communication links to other transputers or to external devices. > Are these things different from CPUs? Yes, they are different from the 68000 series, but they are still considered to be a CPU. > > Is anyone going to buy these things? ( that is if there is software for > them..) That is what we are hoping for, there was a large interest at World of Commadore show for the board. Even though the board is initially aimed at the ray tracing people, this board is such a good general purpose accelerator that there is no limit on what can now be done on a Amiga, eg. virtual reality, real time rendering, medical imaging, any application that need to do tons of logic or math. -- Later -- Randy Young -- Endings are just beginnings in a different form. randy@amerock.cuc.ab.ca (403)256-9775