occam

occam is the language in which concurrency is not an add-on but the way programs are put together. Designed by David May at Inmos in Bristol between 1979 and 1983, alongside - and in step with - the instruction set of the transputer microprocessor, it turned Tony Hoare’s Communicating Sequential Processes into something engineers could compile. An occam program is a tree of processes. SEQ says the processes below it run one after another; PAR says they run at the same time; ALT waits for the first of several communications to become ready. Processes share no variables and exchange values only over channels, with chan ! value to send and chan ? variable to receive, and neither side proceeds until both are there. The same program can run on one processor or be spread across hundreds of transputers joined by their serial links, and the language’s algebraic laws let the two be proved equivalent.

occam was the only language Inmos supported for its first years, which was both its glory and its handicap. It made writing multiprocessor real-time systems - sonar, particle-physics triggers, graphics engines - unusually clean, and it gave the transputer its reputation as the first microprocessor designed for parallel computing. It also asked customers to abandon C, Fortran and Pascal, and once the transputer lost the performance race in the early 1990s and Inmos disappeared into SGS-Thomson, the commercial language stopped at occam 2.1 (1994-95). It did not die, though: the University of Kent’s “occam for all” project made the compiler portable, extended the language with pi-calculus mobility as occam-π, and ran it on everything from Linux clusters to LEGO robots and the Arduino. Its ideas travelled further still, into Handel-C for hardware synthesis, David May’s own XC for XMOS chips, the JCSP and C++CSP libraries, and - by way of CSP rather than of occam directly - the channels and select of Go. The name is written in lower case, after William of Ockham, whose razor the occam User Group printed on its 1985 newsletter as “Do not add any inessential material.”

History and origins

Warwick, Hoare and Inmos (1975-1979)

David May studied mathematics and then computer science at Cambridge (1969-72), learning architecture from David Wheeler and compilers from Martin Richards, and moved to the University of Warwick to do research in robotics. Controlling robots pushed him toward distributed hardware: he built a cluster of single-board microcomputers joined by serial links and, to program it, “a language called EPL - it was a message-passing language that I developed for this robotics work.” Through this work he met Tony Hoare “in about 1975-76,” while Hoare was developing the ideas published in August 1978 as “Communicating sequential processes” in Communications of the ACM. In the same circle was Iann Barron, who had run Computer Technology Limited (May had used its Modular One minicomputers) and who in July 1978, with the Americans Richard Petritz and Paul Schroeder and £50 million of UK government money, founded Inmos.

Barron’s ambition, beyond the memory chips that paid Inmos’s bills, was a microprocessor meant from the outset to be used in numbers - a “transputer”, from transistor and computer, a programmable component that could be wired to others through its own communication links. May joined Inmos in Bristol in 1979. As he told the Computer History Museum in 2011, he was “mainly in charge of the architecture and the programming language. I mean I essentially designed the instruction set and the Occam programming language alongside it.” Hoare was a consultant to the company, and at the 1985 occam User Group meeting he explained that he had left named channels out of his 1978 paper “not because he did not like them, but because he was worried about introducing too many new ideas at the same time” - and that “he now supports the occam model in this area.”

Designing language and machine together (1979-1983)

May has compared the result to the Burroughs B5000 designed for ALGOL and the English Electric KDF9: “one of these designs that are fairly unusual in the history of computing where the machine has basically been designed quite closely in conjunction with an idea about how it’s going to be programmed.” The transputer’s microcode scheduled processes, timed them and implemented channel communication directly, so that occam’s PAR and !/? compiled to a handful of instructions rather than to operating-system calls. The language started life as “INMOS system language” and “went through a whole series of different names” before being called occam, “from Occam’s Razor.” Three ideas from May’s earlier work and from CSP defined it: parallelism and message passing built into the language; event handling and mutual exclusion through the ALT, which “was modeled on the guarded command language” of Dijkstra so that a program could “enable a number of potential sources of messages and then take the first one that occurs”; and error containment - a process that overflows or indexes out of range stops dead, so that “this didn’t prevent other processes continuing to execute, but it would stop the one that had failed, and thereby prevent data propagating outwards.”

The first journal description was May’s “OCCAM” in ACM SIGPLAN Notices 18(4) in April 1983, the year Inmos announced the transputer. This “proto-occam” or occam 1 was deliberately minimal: one data type, VAR, holding a machine word; one-dimensional arrays (VAR x[10]); channels (CHAN c); SEQ, PAR, ALT, IF, WHILE; replicators for building arrays of processes; procedures (PROC); and PLACED PAR with PROCESSOR n for distributing processes across hardware. The occam 1 compiler was itself written in occam 1.

A user community forms (1984-1985)

Inmos treated occam as a product before the transputer existed. By the summer of 1984, when the occam User Group’s first newsletter appeared (edited by Martin Bolton at the University of Bristol), the occam Programming System was “fully available for the VAX under VMS”, and the occam Portakit - a specification and interpreter kit that let a site build its own occam implementation - was on sale; by 1985 universities from the Weizmann Institute to Deakin and Grenoble were porting it. Prentice-Hall published Inmos’s occam Programming Manual the same year, and D. Q. M. Fay’s “Experiences using Inmos proto-OCCAM” in SIGPLAN Notices in September 1984 is the first outside report. The group’s first technical meeting, at the Watershed in Bristol on 21 September 1984, drew about 100 people and was, as Inmos’s Michael Poole wrote, “the first special interest group of INMOS customers to be established”. On 3 December 1984, at the Royal Society, May received the British Computer Society’s award for technical innovation and demonstrated “OCCAM programs running on transputer prototypes.”

The second meeting, at St Catherine’s College, Oxford, on 29 March 1985, had nearly 150 attendees “split fairly evenly between academic and industrial organisations”. Hoare opened it, Alan Burns reported that “concurrency comes easily to students who have not had to struggle with previous inadequate language features for parallel systems”, and Peter Welch - just back at the University of Kent from an industrial fellowship at Marconi Avionics - spoke on functional styles in occam; he would lead the language’s second life. That summer Inmos listed its occam products with prices: an evaluation kit on the UCSD p-System for £175, the VAX programming system for £1,500, the Portakit for £250, and transputer evaluation boards “in the 4th quarter of this year” from £1,500. The T414, the first 32-bit transputer in volume production, launched in October 1985.

occam 2 and the Transputer Development System (1985-1988)

May’s own archive holds “the first definition of the occam2 language… I think it dates from mid-1984,” and occam 2 was released in 1987. It added what occam 1 lacked for real programs: BOOL, BYTE, INT, INT16, INT32, INT64, REAL32 and REAL64; multi-dimensional arrays; FUNCTIONs; and typed channel PROTOCOLs, including sequential protocols (INT; INT::[]BYTE) and variant protocols with tags, alongside the TIMERs, PRI PAR and PRI ALT the language already had. Inmos’s D700 Transputer Development System delivered it. Early TDS versions compiled proto-occam on the PC’s 8086; by the D700D described in Michael Poole’s Technical Note 16 (May 1988) “the compiler and all associated software run on the transputer” on an IMS B004 board plugged into an IBM PC. The TDS was one program - editor, compiler, linker and post-mortem debugger - organised around a folding editor in which blocks of code could be hidden and revealed, and it was written in occam. The occam 2 Reference Manual was published by Prentice Hall in 1988, and the same year Roscoe and Hoare’s “The laws of occam programming” (an Oxford Programming Research Group monograph of 1986) appeared in Theoretical Computer Science, giving the language an equational semantics: PAR is commutative and associative, SEQ distributes through IF, and so on, so that one program can be transformed into another with proof.

Those laws were used at once. The T800 transputer of 1987 carried a 64-bit IEEE 754 floating-point unit whose microcode, May records, “was formally verified by using an occam program transformation system to transform the microcode (represented in occam) into a high-level program that had already been verified. This was a very early use of formal methods in microprocessor design.” May presented it at Hoare’s Concurrent Programming Institute in Austin, Texas, in 1987; the T800 was, he notes, “at the time of introduction, the fastest floating point microcomputer in the world.”

Design philosophy

occam is small on purpose. Alan Burns’s remark that “there is no difficulty in getting the whole language over in a short course” captures both the razor and the pedagogy: everything is a process, and there are only a few ways to combine processes.

• Sequence is explicit. Nothing runs “after” anything else unless a SEQ says so; the programmer states an order or states the absence of one with PAR.
• No sharing. Variables belong to one process. The compiler’s usage rules reject a variable assigned in one branch of a PAR and read in another; the only way for parallel processes to interact is a channel, and a channel has exactly one sender and one receiver.
• Synchronised communication. ! and ? are a rendezvous: whichever side arrives first waits. There are no buffers unless you write a buffer process, which is a three-line WHILE TRUE loop.
• Choice is between events. ALT lists guards - channel inputs, timer inputs, SKIP, each optionally qualified by a Boolean - and commits to whichever is ready first. This is the language-level replacement for interrupts and device drivers, which May believes “should be done in the programming language.”
• Location is separate from logic. A program is written as a network of processes; PLACED PAR (and, in the later toolsets, a separate configuration language) says which transputer each runs on. Nothing else changes.
• Failure stops, and stays local. Overflow, bounds violations and STOP halt the process concerned without touching its neighbours - the property May wanted for control systems where “you lose control of a mechanical system, and something undesirable happens” if errors spread.
• Indentation is syntax. The processes under SEQ or PAR are exactly the lines indented two spaces beneath it. occam used the off-side rule from 1983, several years before Python was written; the two are alike in look, not in lineage.

Because the constructs correspond to CSP operators, an occam program has a mathematical meaning, and tools from Oxford and the company Formal Systems (notably the FDR refinement checker) could analyse CSP models of occam designs for deadlock and refinement. The 1995 “occam for all” proposal called it “the only parallel-processing language in widespread industrial and academic use whose semantics is sufficiently well-defined, simple and powerful” to unify parallel programming.

Key features

Processes, channels and composition

A producer and consumer in occam 2, using the KRoC course library for output (Inmos toolsets used hostio server channels instead):

#INCLUDE "course.module"

PROC producer (CHAN INT out!)
  SEQ i = 0 FOR 10
    out ! i * i
:

PROC consumer (CHAN INT in?, CHAN BYTE screen!)
  INT x:
  SEQ i = 0 FOR 10
    SEQ
      in ? x
      out.int (x, 0, screen!)
      screen ! '*n'
:

PROC main (CHAN BYTE keyboard?, screen!, error!)
  CHAN INT c:
  PAR
    producer (c!)
    consumer (c?, screen!)
:

SEQ i = 0 FOR 10 is a replicated sequence; PAR i = 0 FOR n builds n parallel copies of a process, typically wired together by arrays of channels - the idiom for pipelines, farms and grids. A PROC ends with a colon on its own line, and '*n' is occam’s escaped newline. The ?/! suffixes on channel parameters are the direction specifiers that occam 2.1’s successors made standard.

ALT, timers and priority

PROC merge.with.timeout (CHAN INT a?, b?, out!)
  TIMER tim:
  INT t, x:
  WHILE TRUE
    SEQ
      tim ? t
      PRI ALT
        a ? x
          out ! x
        b ? x
          out ! x
        tim ? AFTER t PLUS 1000000
          out ! -1
:

ALT waits for the first ready guard; PRI ALT breaks ties in textual order; tim ? AFTER turns a deadline into just another event. Guards can carry Boolean conditions (count < 100 & c ? data), so a process can switch inputs off and on. PRI PAR gives the transputer’s two hardware priority levels to a pair of processes.

Protocols and types (occam 2 and 2.1)

PROTOCOL PACKET IS INT; INT::[]BYTE:      -- a length-prefixed byte array

PROTOCOL COMMAND
  CASE
    move; INT; INT
    stop
:

DATA TYPE POINT
  RECORD
    REAL32 x, y:
:

Channels carry a declared PROTOCOL, so a receiver of COMMAND writes c ? CASE with a branch for move and one for stop, and the compiler rejects mismatched communications. occam 2.1 added named DATA TYPEs, RECORDs and PACKED RECORDs, channel RETYPES, BYTESIN, channel arrays and functions returning fixed-size arrays. Conversions are always written out (INT x, REAL32 ROUND y, INT TRUNC z); nothing is coerced silently.

Placement and configuration

In occam 1 and 2, PLACED PAR with PROCESSOR n T8 put each process on a named transputer and PLACE chan AT link bound channels to hardware links; the occam 2 toolsets of the early 1990s moved this into a separate configuration description, so the same source could be re-mapped without editing. Only channels crossing processor boundaries become link traffic; the rest are memory-to-memory copies handled by microcode.

occam-π

The Kent extensions, published by Barnes and Welch from 2003 and implemented in KRoC 1.3.x onward, keep occam’s static core but let networks change shape:

The Kent page of 2006 gave the cost of these mechanisms on an 800 MHz Pentium III: about 70 nanoseconds for a context switch or channel communication and about 20 nanoseconds to start or stop a process - figures for KRoC’s own CCSP scheduler, not for any particular application.

Evolution

occam 3, occam 2.1 and the end of Inmos (1989-1995)

Inmos was sold to SGS-Thomson in April 1989, the same year work began on the T9000, a superscalar transputer with hardware virtual channels that was “delayed, suffered badly from silicon bugs, and eventually canned years late,” as Ivimey-Cook put it. In parallel, Geoff Barrett of the Architecture Group drafted occam 3 - known during development as occam91 - with modules, remote-call channels, shared channels and libraries; the 203-page draft of 31 March 1992 was circulated “for community comment” and never implemented in full, though “many of the ideas from occam 3 have inspired occam-pi language features.” What the company actually shipped was occam 2.1, defined in 1994 as a modest extension of occam 2 and documented in the reference manual of 12 May 1995, later donated by SGS-Thomson to the user group. In December 1994 the Inmos name was retired; the transputer line petered out with the T400/T425/T450 parts, and the derived ST20 core lived on in STMicroelectronics set-top-box chips (and, reportedly, GPS receivers). Occam’s fortunes had been tied to a single processor, and the processor was gone.

Retargeting: SPoC and KRoC (1994-1999)

Breaking that tie began in the user community. At WoTUG-17 in 1994, Debbage, Hill, Wykes and Nicole of Southampton presented SPoC, an occam-to-C translator built with a compiler-generator, which let occam run “on industry-standard platforms, as typified by the Unix work-station”; one industrial report describes 26,000 lines of C generated from occam for a DSP-based radar level gauge. The larger effort was “occam for all”, an EPSRC project under Peter Welch at Kent with Barry Cook at Keele, supported by British Aerospace, GEC-Marconi Avionics and Formal Systems, and with Inmos “donating compiler sources and technical advice.” Its Kent Retargetable occam Compiler took Inmos’s own occam 2.1 compiler as a front end and translated its transputer code for other processors, linking “a small (< 2K bytes) kernel that provides the process scheduling and message-passing functionality of transputer micro-code.” KRoC 0.3 beta appeared for Sun SPARC in September 1995; the 0.9 beta supported SPARC and DEC Alpha and quoted a context-switch overhead “around 600 nano-seconds on a Sparc-20 and 230 nano-seconds on a 233 MHz Alpha.” PowerPC and, from around 1999, Intel x86 on Linux followed, the latter on James Moores’s CCSP run-time.

occam-π, the Transterpreter and small hardware (2000-2011)

Fred Barnes’s doctoral and postdoctoral work at Kent turned KRoC/Linux into the vehicle for occam-π: version 1.2.3 in June 2000, the 1.3.0 pre-releases from January 2001, 1.3.3 on 30 July 2004 and 1.4.0 on 14 January 2006 (Linux and FreeBSD on i386, and Windows under Cygwin), released under the GPL and LGPL. Alongside it came occamdoc, the pony networking layer for distributed occam-π, an SDL raster library, a MySQL binding, and the RMoX experimental operating system written in occam-π. Christian Jacobsen and Matt Jadud’s Transterpreter (CPA 2004) interpreted KRoC’s Extended Transputer Code in a few kilobytes of portable C and put occam-π on the LEGO Mindstorms RCX (SIGCSE 2005), then on the Surveyor SRV-1 and Fluke robots, and - starting with “First work on compiling the Transterpreter for the Arduino” on 25 June 2009 - on the Arduino. The concurrency.cc group wrapped that in the Plumbing library, in which Arduino pins, timers and PWM are occam-π processes, and reported it at CPA 2011. Tock, a Haskell-based occam compiler written by Adam Sampson and colleagues at Kent, and Barnes’s experimental nocc (published on GitHub 2013-16) explored new front ends.

Dormancy and a 2026 revival

KRoC’s Subversion history begins on 13 August 2005; the repository moved to GitHub in March 2013 and tagged kroc-1.6.0 on 24 April 2013, its last release. Activity peaked at roughly 700-800 commits a year in 2008-2010, fell to a few dozen after 2011, and ended with a Python 3 build attempt on 27 March 2020 that was reverted two days later; the code still assumes a 32-bit i386 target. WoTUG - the occam User Group renamed, by the mid-1990s, the World occam and Transputer User Group - held its 40th conference, Communicating Process Architectures 2018, in Dresden; none is listed since. In April 2026 Jim Moores - whose name matches the James Moores of the 1999 CCSP paper - started Razor, a fork of KRoC “being modernised for contemporary 64-bit systems” with x86-64 and aarch64 targets on Linux and macOS, the occ21 compiler moved off K&R C and the tools on Python 3; it was last pushed at the end of June 2026 and has not yet published a release.

Current relevance

occam is dormant as a production language and alive as a teaching and research one. The occam 2.1 and occam 3 manuals, the OUG newsletters, Inmos technical notes and the whole KRoC source tree are freely available through wotug.org, transputer.net and GitHub; KRoC builds on 32-bit Linux and runs in community Docker images (thron/doccam, unlvcs/occam, omegahm/kroc); the Transterpreter still targets the Arduino; and Razor is bringing the compiler to 64-bit machines. Transputer emulators and surviving hardware run the original Inmos toolsets. The WoTUG and Communicating Process Architectures proceedings - dozens of volumes from IOS Press - are the literature of a school of thought whose libraries (JCSP for Java, C++CSP, PyCSP, CHP for Haskell) carry occam’s process model into languages people use daily.

The language’s direct descendants are on chips. David May co-founded XMOS in 2005, and XC, the language for its XCore processors, is “based on the features for parallelism and communication in occam” - par, channels, select, ports and timers - “and the syntax and some sequential features of C.” Handel-C, from Ian Page’s group at Oxford, was in Ivimey-Cook’s phrase “a version of occam, dressed up in C syntax,” compiled directly to FPGA hardware. And May’s argument from the 1980s - that “the Occam thing really… contains the three ingredients that you should teach everybody from, in CS-101… concurrency or parallelism, it’s sequential stuff, and it’s event handling” - reads, in the multicore era, less like a lost cause than an early draft.

Why it matters

occam is the clearest demonstration that a formal model of concurrency can be a practical programming language. Hoare’s CSP became, through May, a notation in which PAR and ! and ? and ALT are as ordinary as if and while, and in which the compiler enforces the discipline - no shared variables, one sender per channel - that makes the model’s proofs apply to real code. The transputer showed the model could be executed by microcode in nanoseconds, and the verification of the T800’s floating-point unit showed the same laws could check hardware. Every later language built on CSP-style channels - Handel-C and XC in silicon, the JCSP family in libraries, and, through CSP rather than through occam itself, Newsqueak, Limbo and Go at Bell Labs and Google - inherits something occam worked out first: that a program should be composed of processes, that communication should be synchronised and typed, and that choosing between events belongs in the language rather than in an interrupt handler.

Its limits are equally instructive. Occam’s fate was bound to one company’s processor, its static process networks needed a decade of research to loosen, and its refusal to look like C cost it users who would have taken its ideas in a familiar syntax - which is exactly what XC and Go later provided. The language itself survives where its virtues matter most: in classrooms, on tiny robots, and in the heads of the people who designed the chips and languages that followed.

Further reading

• David May, “OCCAM”, ACM SIGPLAN Notices 18(4), April 1983, pp. 69-79 - the first paper
• Inmos Limited, occam Programming Manual, Prentice-Hall, 1984; occam 2 Reference Manual, Prentice Hall, 1988
• SGS-Thomson Microelectronics, occam 2.1 Reference Manual, 12 May 1995 (wotug.org/occam/documentation), and Geoff Barrett, occam 3 Reference Manual, draft of 31 March 1992
• C. A. R. Hoare, “Communicating sequential processes”, Communications of the ACM 21(8), 1978; Communicating Sequential Processes, Prentice Hall, 1985
• A. W. Roscoe and C. A. R. Hoare, “The laws of occam programming”, Theoretical Computer Science 60(2), 1988
• Michael Poole, Occam program development using the IMS D700D transputer development system, Inmos Technical Note 16, May 1988 (transputer.net)
• The occam User Group newsletters, 1984-85 (transputer.net/obooks/oug)
• Ruth Ivimey-Cook, “Legacy of the transputer”, WoTUG-22, IOS Press, 1999
• F. R. M. Barnes and P. H. Welch, “Prioritised dynamic communicating and mobile processes”, IEE Proceedings - Software 150(2), 2003; “Communicating mobile processes”, 25 Years of CSP, LNCS 3525, 2005
• C. L. Jacobsen and M. C. Jadud, “Towards concrete concurrency: occam-pi on the LEGO Mindstorms”, SIGCSE 2005; with O. Kilic and A. T. Sampson, “Concurrent event-driven programming in occam-π for the Arduino”, CPA 2011; I. Armstrong, D. Pirrone-Brusse, A. Smith and M. C. Jadud, “The Flying Gator: towards aerial robotics in occam-π”, CPA 2011
• David May, oral history interviewed by Kevin Krewell, Computer History Museum, 16 August 2011; David May’s occam and transputer pages at people.cs.bris.ac.uk/~dave/
• KRoC (github.com/concurrency/kroc), Razor (github.com/jimmoores/razor), occam-pi.org and wotug.org