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