Newsgroups: comp.sys.transputer From: tbjorkho@james.abo.fi (Tom Bj|rkholm AT) Subject: FAQ Organization: Abo Akademi University, Finland Date: Mon, 4 Oct 1993 22:40:03 GMT Release date: 04-October-1993 THE TRANSPUTER FAQ Contents: A. Introduction Level A1. Flynn's taxonomy A2. The Transputer A3. Communication: Links and Channels A4. Timesharing A5. The words "process", "task" and "thread" A6. Iserver, afserver, pserver A7. Languages A8. Porting A9. Alternate A10. Timers, sleeping and wakeup. A11. Events (Interrupts) A12. Resetting and booting A13. Shared variables A14. Free Software A15. B004 and TRAM A16. Suppliers and Prices B. More Advanced Topics B1. Communication performance B2. Performance tuning with priorities C. Further Reading Q. Questions and Answers Q1. Can you have more than one channel on a link? ------------------------------------------------------------------------- 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. (Another explanation for the word "transputer" is that it was derived from TRANSistor and comPUTER. Not because it is made of transistors, but because it is a computer that can be used as a component for building larger systems, in the same way that transistors can. (Ian Glendinning sent me this explanation)) The transputer family include four different series of transputers. They are shown below together with their peak performance. (Actually the peak 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. (Different systems such as RS-422 and optical links exist for reliable communication over longer links.) 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 100 Library Plaza 15 North 100 East Provo, UT 84606-3100 Phone: (801) 374-2300 or (800) 753-4CSA (4272) Fax: (801) 374-2306 fax email: csa@infonaut.com Home Page: http://www.infonaut.com/~csa/ The Transputer Education Kit (US$396) includes a PC add-in board (T400 + 1 MB), a T400 C compiler, a T400 Occam2 compiler, and documentation. CSA also offers a complete line of other transputer products. 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-52070 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 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 B1. Communication performance The communication time over a link can be modelled in the following way: T = a * size + b where T = time spent sending message size = size of message, in byte a = time spent sending the byte (link speed) b = time spent initialising for communication. From the form of the above equation it is obvious that communication is more efficient if the data can be sent in big chunks. The constants ('a' and 'b') in the equation should according to (a simplified) theoretical reasoning be a little more than 20 cycles (1 microsecond) for 'b'. 'a' should be directly given by the link speed, thus 'a' should normally be about 0.5 microseconds/byte. The result of measurements (on one particular system) is however: T = 0.761E-6 (s/byte) * size + 13.E-6 s (where E-6 means "times 10 to the power of -6"). (The exact figures is not important - they vary with the compiler and hardware used. The key idea is that the communication time consists of two parts: the setup time, and the actual transfer time.) It should also be noted that the links are DMA driven (as stated in A3). Thus the key to efficient communication is to send big packets and overlap the communication with calculations. B2. Performance tuning with priorities It seems to be a common misunderstanding that things happen faster on high priority. This is not the case. If you have one single process on a processor, doing a calculation, it needs exactly the same amount of time to complete on high priority as on low. The priorities only affect the order in which things are done (when having several processes). But, performance can be gained by tuning the priorities. Communication over a link only needs a few cycles of CPU time to initialise, and after that it can happen concurrently with calculations on another process. In the following example, performance is gained by running the communication at high priority. Consider a process A that creates data to be sent to the neighbour processor. Then we have a process B that does the exchange of data (and no calculations). The process C only needs data from the local A process, but D needs data from both C and the A process at the neighbouring processor. Thus the scheduling could be like this: Processor 1: Processor 2: A A C C C and B can happen concurrently but idle B <---> B idle C happened to be scheduled before B D D which obviously is bad for the performance. By running B at high priority we can assure that the communication is started immediately and continues in parallel with C. 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. Q. Questions and Answers Q1. Can you have more than one channel on a link? The link hardware can handle only one channel (in each direction). If more than one channel is needed on a single link a multiplexer task has to be inserted on both ends of the link. Most new compilers/configurers insert these multiplexer tasks automatically. The multiplexer tasks often take the form of a light weight communication kernel called the VCR (after the virtual channel router developed at the University of Southampton). The VCR not only multiplexes the channels that has to be placed on the same link, but also connects channels on different links to create a virtual channel between non-neighbouring processor. The idea with the VCR is to allow virtual channels between any two processes, independent of the hardware architecture. --- -- 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