The computer at the bottom of a canal – Negroni Venture Studios

Skip to main content

Skip to footer

The computer at the bottom of a canal

Alasdair Allan

18 July 2026

Somewhere at the bottom of the Forth and Clyde Canal, buried in the silt, there is a box of custom silicon that was right about almost everything.

Back in 1988 a Scottish hi-fi company shipped a processor that checked the type and bounds of every memory access in hardware, garbage-collected its own heap in silicon, and treated memory and disk as a single persistent object store. Retellings of the story make it out as charming folly, one where a company that made record turntables decided von Neumann was wrong.

But the story of the Rekursiv deserves to be more than just a curiosity, because almost forty years after it went into the water, its ideas are now shipping in production silicon from Arm; and also because the economics that killed it have just been reversed. Although all these years later, the fine details of the story mostly rest on the recollections of people who were there, it turns out that the hi-fi company were right about almost everything except which decade to build the hardware.

A hi-fi company builds a computer

Linn Products is the Glasgow company Ivor Tiefenbrun founded in 1972, and if you know it at all you know it for the Sondek LP12, still widely regarded by its partisans as the finest record deck ever made.

The Linn Sondek LP12

By the early eighties Linn had built a modern factory at Eaglesham, south of the city itself, and ran their business on a pair of VAX-11/750s along with a pair of 11/780s. But Tiefenbrun came to loathe the software they used. He wanted a system in which every physical object in the factory, down to each individual turntable moving through assembly, test, and even after-sales, had a shadowing software object accumulating its history (Pountain, Byte, November 1988).

So around 1981 Linn hired programmers and a University of Glasgow computer science lecturer, David Harland, and built an object-oriented language called LINGO. LINGO was a Smalltalk with some Algol in its syntax, not to be confused with the other Lingo programming language, which wouldn’t come along for another eight years.

MICRO$COPYTREE: entf 1 pagebus d=ustack<br>crtf IDXBADTYPES newtrbr _CONS<br>incmsp m.sp' newmptr<br>jf MICRO$COPYTREE ldustk d=pgrorr // the CDR branch<br>m.fp 1 uaddbr newmptr<br>readustk<br>pagebus d=ustack<br>idx2 newsr newbr loadaddr<br>idxget nocheck incmsp m.sp' newmptr<br>jf MICRO$COPYTREE ldustk d=memout // the CAR branch<br>js RTN$CONS<br>rtf

Microcode for a recursive tree-copy instruction. Note the instruction calling itself, something forbidden to a conventional CPU (Source: Pountain, 1988).

LINGO worked; but it also ran far too slowly on the VAX to automate anything. Tiefenbrun’s response was pure Tiefenbrun. The hardware was the problem, not the software: so Linn would build hardware.

While stranded on a delayed train home from a seminar, Harland, and another computer engineer Bruno Beloff, sketched the repartitioning of their prototype into custom chips they christened "Rekursiv," which is why Harland later joked that "the Rekursiv [was] British Rail’s fault."

A few years later, in 1984, Tiefenbrun formed Linn Smart Computing, installed his brother Marcus as managing director and Harland as technical director, and funded it with Linn’s own money plus roughly £10 million from the Department of Trade and Industry.

LSI Logic fabricated the chips. Four gate arrays in 1.5 micron CMOS, 299 pins each, named NUMERIK, LOGIK, OBJEKT and KLOK. A company that sold the Sondek, the Ittok, and the Asak was never going to name the chips anything else.

Objects all the way down

What made the Rekursiv strange was not that it ran object-oriented programs. It was that a programmer – or, come to that, the compiler – could never see an address. Every object carried a 40-bit number issued at creation, and the OBJEKT chip translated numbers to physical locations through a hashed pager table, checking the type and the bounds of every single access in hardware as it went. Run off the end of an array? The machine refused. Forge a reference? The machine refused. Since only OBJEKT ever knew where anything physically lived, objects could be relocated freely without touching a reference, so garbage collection went into the silicon too: a two-space compacting collector that walked the live objects and slid them into the other half of DRAM while execution carried on above, oblivious.

Persistence worked the same way. Memory and disk were one object store, and if a needed object wasn’t in DRAM the processor simply stalled, mid-instruction, while an external disk processor fetched it, then carried on as if nothing had happened. Because paging sat below the level of instruction execution, a single microcoded instruction could be arbitrarily complex, and could even call itself. That’s the recursion in the name. There was no fixed instruction set at...