The transputer is a series of microprocessors from the 1980s, intended for parallel computing. To support this, each transputer had its own integrated memory and serial communication links to exchange data with other transputers. They were designed and produced by Inmos, a semiconductor company based in Bristol, United Kingdom.Allen Kent, James G. Williams (eds.) (1998) "Encyclopedia of Computer Science and Technology", , "The Transputer Family of Products", by Hamid R. Arabnia.
For some time in the late 1980s, many considered the transputer to be the next great design for the future of computing. While the transputer did not achieve this expectation, the transputer architecture was highly influential in provoking new ideas in computer architecture, several of which have re-emerged in different forms in modern systems.Stoker, & White, A. . (2000). Mechatronic cine-film copying using transputer control. Mechatronics (Oxford), 10(7), 773–807. https://doi.org/10.1016/S0957-4158(99)00043-4
Background In the early 1980s, conventional central processing units (CPUs) appeared to have reached a performance limit. Up to that time, manufacturing difficulties limited the amount of circuitry that could fit on a chip. Continued improvements in the fabrication process had largely removed this restriction. Within a decade, chips could hold more circuitry than the designers knew how to use. Traditional complex instruction set computer (CISC) designs were reaching a performance plateau, and it wasn't clear it could be overcome.Fuller, Samuel H. & Millett, Lynette I., Editors (2011). The Future of Computing Performance, CSTB, National Academic Press, p. 84. Retrieved on November 2, 2016.
It seemed that the only way forward was to increase the use of parallelism, the use of several CPUs that would work together to solve several tasks at the same time. This depended on such machines being able to run several tasks at once, a process termed multitasking. This had generally been too difficult for prior microprocessor designs to handle, but more recent designs were able to accomplish it effectively. It was clear that in the future, this would be a feature of all operating systems (OSs).
A side effect of most multitasking design is that it often also allows the processes to be run on physically different CPUs, in which case it is termed multiprocessing. A low-cost CPU built for multiprocessing could allow the speed of a machine to be raised by adding more CPUs, potentially far more cheaply than by using one faster CPU design.
The first transputer designs were due to computer scientist David May and telecommunications consultant Robert Milne. In 1990, May received an Honorary DSc from University of Southampton, followed in 1991 by his election as a Fellow of The Royal Society and the award of the Patterson Medal of the Institute of Physics in 1992. Tony Fuge, then a leading engineer at Inmos, was awarded the Prince Philip Designers Prize in 1987 for his work on the T414 transputer.
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 "transistor" and "computer", 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 transistors 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 drives 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 processor-in-memory. Even one transputer would have all the circuitry needed to work by itself, a feature more commonly associated with microcontrollers. The intent was to allow transputers to be connected together as easily as possible, with no need for a complex 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 Reusable Micro Cores (RMC) in the then emerging 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 opcodes 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.Stakem, Patrick H. The Hardware and Software Architecture of the Transputer, 2011, PRB Publishing, ASIN B004OYTS1K
The clock rate of 20 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 MHz was used, and this was multiplied up to the needed internal frequency using a phase-locked loop (PLL). The internal clock actually had 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 MHz. 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 on the general principles of the transputer.
Links The basic design of the transputer included serial links known as "os-link"sKazuto Tanaka; Satoshi Iwanami; Takeshi Yamakawa; Chikara Fukunaga; Kazuto Matsui; Takashi Yoshida. "The Design and Performance of SpaceWire Router-network using CSP". p. 2."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. that allowed it to communicate with up to four other transputers, each at 5, 10, or 20 Mbit/s – which was very fast for the 1980s. Any number of transputers could be connected together over links (which could run tens of metres over differential wiring) 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 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 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 levels to improve 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 microcoded, had a limited register set, and complex memory-to-memory instructions, all of which place it firmly in the CISC camp. Unlike register-heavy 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 Load Local and Store Local. This allowed for very fast context switching 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 TI-990) series. The three register stack contents were not preserved past certain instructions, like Jump, when the transputer could do a context switch.