Editing Transputer (section)

== Design ==
The transputer was the first general purpose microprocessor designed specifically to be used in [[parallel computing]] systems. The goal was to produce a family of chips ranging in power and cost that could be wired together to form a complete parallel computer. The name, from "''trans''istor" and "com''puter''",<ref name="aspinall">{{cite journal |title=The Transputer |journal=The Microprocessor and Its Application: An Advanced Course |last=Barron |first= Iann M. |editor=D. Aspinall|publisher=[[Cambridge University Press]] |year=1978 |page=343 |isbn=0-521-22241-9 |url= https://books.google.com/books?id=rT05AAAAIAAJ&pg=PA343 |access-date=2009-05-18}}</ref> was selected to indicate the role the individual transputers would play: numbers of them would be used as basic building blocks in a larger integrated system, just as [[transistor]]s had been used in earlier designs.

Originally the plan was to make the transputer cost only a few dollars per unit. Inmos saw them being used for practically everything, from operating as the main CPU for a computer to acting as a [[channel controller]] for [[disk drive]]s in the same machine. In a traditional machine, the processing capability of a disk controller, for instance, would be idle when the disk was not being accessed. In contrast, in a transputer system, spare cycles on any of these transputers could be used for other tasks, greatly increasing the overall performance of the machines.

The transputer had large on-chip memory, making it essentially a [[Computational RAM|processor-in-memory]]. Even one transputer would have all the circuitry needed to work by itself, a feature more commonly associated with [[microcontroller]]s. The intent was to allow transputers to be connected together as easily as possible, with no need for a complex [[Bus (computing)|bus]], or [[motherboard]]. Power and a simple [[clock signal]] had to be supplied, but little else: [[random-access memory]] (RAM), a RAM controller, bus support and even a [[real-time operating system]] (RTOS) were all built in. In this way, the last of the transputers were single [[#ST20|Reusable Micro Cores (RMC)]] in the then emerging [[System on a chip|SoC]] market.

=== Architecture ===
The original transputer used a very simple and rather unusual architecture to achieve a high performance in a small area. It used [[microcode]] as the main method to control the data path, but unlike other designs of the time, many instructions took only one cycle to execute. Instruction [[opcode]]s were used as the entry points to the microcode [[read-only memory]] (ROM) and the outputs from the ROM were fed directly to the data path. For multi-cycle instructions, while the data path was performing the first cycle, the microcode decoded four possible options for the second cycle. The decision as to which of these options would actually be used could be made near the end of the first cycle. This allowed for very fast operation while keeping the architecture generic.<ref>Stakem, Patrick H. The Hardware and Software Architecture of the Transputer, 2011, PRB Publishing, ASIN B004OYTS1K</ref>

The [[clock rate]] of 20&nbsp;MHz was quite high for the era and the designers were very concerned about the practicality of distributing such a fast clock signal on a board. A slower external clock of 5&nbsp;MHz was used, and this was multiplied up to the needed internal frequency using a [[phase-locked loop]] (PLL). The internal clock actually had [[clock signal#4-phase clock|four non-overlapping phases]] and designers were free to use whichever combination of these they wanted, so it could be argued that the transputer actually ran at 80&nbsp;MHz. [[Dynamic logic (digital electronics)|Dynamic logic]] was used in many parts of the design to reduce area and increase speed. Unfortunately, these methods are difficult to combine with [[automatic test pattern generation]] scan testing so they fell out of favour for later designs.

Prentice-Hall published a book<ref>{{cite book|url=http://www.transputer.net/ibooks/72-trn-006-04/trefm04.pdf |archive-url=https://ghostarchive.org/archive/20221009/http://www.transputer.net/ibooks/72-trn-006-04/trefm04.pdf |archive-date=2022-10-09 |url-status=live|title=Transputer Reference Manual|publisher=[[Prentice-Hall]]|date=1988|isbn=0-13-929001-X}}</ref> on the general principles of the transputer.

=== Links ===
The basic design of the transputer included [[serial link]]s known as "os-link"s<ref name="tanaka">
Kazuto Tanaka; Satoshi Iwanami; Takeshi Yamakawa; Chikara Fukunaga; Kazuto Matsui; Takashi Yoshida.
[http://www.comp.tmu.ac.jp/morbier/work/componenttanaka.pdf "The Design and Performance of SpaceWire Router-network using CSP"].
p. 2.
</ref><ref>
[https://books.google.com/books?id=uibU5GzqHjEC "High-Performance Computing and Networking: International Conference and Exhibition, Amsterdam, the Netherlands, April 21-23, 1998 Proceedings"].
B C O'Neill; G Coulson; K L Wong; R Hotchkiss; J H Ng; S Clark; and P D Thomas.
"An Interface Device to Support a Distributed Parallel System for the StrongARM Microprocessor".
p. 1031.
</ref> that allowed it to communicate with up to four other transputers, each at 5, 10, or 20&nbsp;Mbit/s &ndash; which was very fast for the 1980s. Any number of transputers could be connected together over links (which could run tens of metres) to form one computing ''farm''. A hypothetical desktop machine might have two of the "low end" transputers handling [[input/output]] (I/O) tasks on some of their serial lines (hooked up to appropriate hardware) while they talked to one of their larger cousins acting as a [[central processing unit|CPU]] on another.

There were limits to the size of a system that could be built in this fashion. Since each transputer was linked to another in a fixed point-to-point layout, sending messages to a more distant transputer required that messages be relayed by each chip in the line. This introduced a delay with every "hop" over a link, leading to long delays on large nets. To solve this problem Inmos also provided a zero-delay switch that connected up to 32 transputers (or switches) into even larger networks.

=== Booting ===
Transputers could boot from memory, as is the case for most computers, but could also be booted [[network booting|over its network links]]. A special pin on the chips, BootFromROM, indicated which method it should use. If BootFromROM was asserted when the chip was reset, it would begin processing at the instruction two bytes from the top of memory, which was normally used to perform a backward jump into the boot code. If this pin was not asserted, the chip would instead wait for bytes to be received on any network link. The first byte to be received was the length of the code to follow. Following bytes were copied into low memory and then jumped into once that number of bytes had been received.

The general concept for the system was to have one transputer act as the central authority for booting a system containing a number of connected transputers. The selected transputer would have the BootFromROM permanently asserted, which would cause it to begin running a booter process from ROM on startup. The other transputers would have the BootFromROM tied low, and would simply wait. The loader would boot the central transputer, which would then begin sending boot code to the other transputers in the network, and could customize the code sent to each one, for instance, sending a [[device driver]] to the transputer connected to the hard drives.

The system also included the 'special' code lengths of 0 and 1 which were reserved for [[PEEK and POKE]]. This allowed inspection and changing of RAM in an unbooted transputer. After a peek, followed by a memory address, or a poke, with an address and single word of data, the transputer would return to waiting for a bootstrap. This mechanism was generally used for debugging.

=== Scheduler ===
Added circuitry scheduled traffic over the links. Processes waiting for communications would automatically pause while the networking circuitry finished its reads or writes. Other processes running on the transputer would then be given that processing time. It included two [[priority level]]s to improve [[real-time computing|real-time]] and [[multiprocessor]] operation. The same logical system was used to communicate between programs running on one transputer, implemented as ''virtual network links'' in memory. So programs asking for any input or output automatically paused while the operation completed, a task that normally required an operating system to handle as the arbiter of hardware. Operating systems on the transputer did not need to handle scheduling; the chip could be considered to have an OS inside it.

=== Instruction set ===
To include all this function on one chip, the transputer's core logic was simpler than most CPUs. While some have called it [[reduced instruction set computer]] (RISC) due to its rather sparse nature, and because that was then a desirable marketing [[buzzword]], it was heavily [[microcode]]d, had a limited register set, and complex memory-to-memory instructions, all of which place it firmly in the [[complex instruction set computer|CISC]] camp. Unlike register-heavy [[Load/store architecture|load/store RISC]] CPUs, the transputer had only three data registers, which behaved as a stack. In addition a workspace pointer pointed to a conventional memory stack, easily accessible via the instructions <code>Load Local</code> and <code>Store Local</code>. This allowed for very fast [[context switch]]ing by simply changing the workspace pointer to the memory used by another process (a method used in a number of contemporary designs, such as the [[TMS9900]]). The three register stack contents were not preserved past certain instructions, like Jump, when the transputer could do a context switch.

The transputer instruction set consisted of 8-bit instructions assembled from [[opcode]] and [[operand]] [[nibble]]s. The ''upper'' nibble contained the 16 possible primary instruction codes, making it one of the very few commercialized [[minimal instruction set computer]]s. The ''lower'' nibble contained the one immediate constant operand, commonly used as an offset relative to the workspace (memory stack) pointer. Two [[prefix]] instructions allowed construction of larger constants by prepending their lower nibbles to the operands of following instructions. Further instructions were supported via the instruction code ''Operate'' (<code>Opr</code>), which decoded the constant operand as an extended zero-operand opcode, providing for almost endless and easy instruction set expansion as newer implementations of the transputer were introduced.

The 16 'primary' one-operand instructions were:

{| class="wikitable"
|-
! Mnemonic
! Description
|-
|J
|Jump – add immediate operand to instruction pointer
|-
|LDLP
|Load local pointer – load a workspace-relative pointer onto the top of the register stack
|-
|PFIX
|Prefix – general way to increase lower nibble of following primary instruction
|-
|LDNL
|Load non-local – load a value offset from address at top of stack
|-
|LDC
|Load constant – load constant operand onto the top of the register stack
|-
|LDNLP
|Load non-local pointer – load address, offset from top of stack
|-
|NFIX
|Negative prefix – general way to negate (and possibly increase) lower nibble
|-
|LDL
|Load local – load value offset from workspace
|-
|ADC
|Add constant – add constant operand to top of register stack
|-
|CALL
|Subroutine call – push instruction pointer and jump
|-
|CJ
|Conditional jump – depending on value at top of register stack
|-
|AJW
|Adjust workspace – add operand to workspace pointer
|-
|EQC
|Equals constant – test if top of register stack equals constant operand
|-
|STL
|Store local – store at constant offset from workspace
|-
|STNL
|Store non-local – store at address offset from top of stack
|-
|OPR
|Operate – general way to extend instruction set
|}

All these instructions take a constant, representing an offset or an arithmetic constant. If this constant was less than 16, all these instructions coded to one byte.

The first 16 'secondary' zero-operand instructions (using the OPR primary instruction) were:
{| class="wikitable"
|-
! Mnemonic
! Description
|-
|REV
|Reverse – swap two top items of register stack
|-
|LB
|Load byte
|-
|BSUB
|Byte subscript
|-
|ENDP
|End process
|-
|DIFF
|Difference
|-
|ADD
|Add
|-
|GCALL
|General call – swap top of stack and instruction pointer
|-
|IN
|Input – receive message
|-
|PROD
|Product
|-
|GT
|Greater than – the only comparison instruction
|-
|WSUB
|Word subscript
|-
|OUT
|Output – send message
|-
|SUB
|Subtract
|-
|STARTP
|Start process
|-
|OUTBYTE
|Output byte – send one-byte message
|-
|OUTWORD
|Output word – send one-word message
|}

=== Development ===
[[File:Transputer Evaluation IMSB008 68.jpg|thumb|Empty ''B008'' motherboard]]
[[File:Transputer Standardmodule IMSB404 IMSB418 73.jpg|thumb|Selection of TRAMs]]

To provide an easy means of prototyping, constructing and configuring multiple-transputer systems, Inmos introduced the ''TRAM'' (TRAnsputer Module) standard in 1987. A TRAM was essentially a building block [[daughterboard]] comprising a transputer and, optionally, external memory and/or peripheral devices, with simple standardised connectors providing power, transputer links, clock and system signals. Various sizes of TRAM were defined, from the basic Size 1 TRAM (3.66 in by 1.05 in) up to Size 8 (3.66 in by 8.75 in). Inmos produced a range of TRAM [[motherboard]]s for various host buses such as [[Industry Standard Architecture]] (ISA), [[MicroChannel]], or [[VMEbus]]. TRAM links operate at 10&nbsp;Mbit/s or 20&nbsp;Mbit/s.<ref>{{cite web|url=http://www.transputer.net/tn/29/tn29.html |title=Inmos Technical Note 29: Dual-In-Line Transputer Modules (TRAMs) |publisher=Transputer.net |date=2008-07-04 |access-date=2013-10-12}}</ref>