Farewell to two pivotal figures: The founder of Inmos, and the co-creator of MIME The IT community has suffered a double loss with the passing of two industry icons. A post in the Facebook group for former Inmos staff says that the company's founder, Professor Iann Marchant Barron, died at the age of 85 last month. The IEEE called Barron "the one-time enfant terrible of the UK computing industry." In the …
I hadn't realised that there was a connection between CTL and the Transputer. I remember being at QUB in the late 70s when the main computer centre was put out of action by a bomb, so those of us learning Fortran as part of the Engineering courses couldn't run programs. Instead we were given accounts on the Engineering Maths department CTL Mod 1 (Modular 1 Teaching System, always known as MITS). Real keyboards, connected to a live system, it's where I (and others) got hooked on programming computers. We knew little about the actual hardware at that point.
RIP Prof. Barron.
I met the Elliott 803 at college and it was pivotal in me choosing a career in computers. I never knew the connection to Barron. He was a genius for sure and the whole Transputer project had so many things that were revolutionary about it that, only now, have we finally "got it". Sadly missed.
I know you shouldn't speak ill of the dead, but according to the former Elliott employees I've spoken to, Iann Barron did not design the Elliott 803. He may have had a minor role, but that's all.
In Simon Lavington's book "Moving Targets Elliott-Automation and the Dawn of the Computer Age in Britain, 1947 – 67" page 352 it says
"Iann Barron was involved as a Vac student but played no part in the real design [of the 803]"
The design team was John Bunt, Jim Barrow, Laurie Bental, Roger Cook.
I have Laurie Bental's original hand drawn logic diagrams from when he redesigned the 803A into the 803B!
Peter Onion
Elliott 803 Curator
The National Museum of Computing.
I used a box containing a network of Transputers in something called a Computer Surface. We used it to model results from seismic modelling on a Cray. We eventually turned a system running on an IBM 3090 where we generated one image every 3 minutes, to one that generated 30 images per second. It was truly amazing.
It is a shame that no-one really understood it, it was way ahead of its time.
WTF didn't they do a version with an 8bit data bus and a 16 bit address bus?
IE like EVERY 8 bit micro running at the time.
The transputer was microcoded (but still damm fast) and its instruction set designed to build up instructions from 4 bit parcels, to however many bits was needed.
The 16/8 would have been the conceptual equivalent of the Motorola 68008 used in the QL. IOW it would have raised a lot of awareness of this new (highly scalable) architecture. It might (dare I even suggest it?) have persuaded a few folk to try this new-fangled Occam thing, perhaps.
Guess we'll never know. RIP stack machines.
We studied the Transputer as part of our Masters degree back in 1985. The thing that got talked about most was the folding text editor, hiding layers of detail, that and the "edge" problem, getting data from the real world into the Transputer array.
Apart from matrix multiplication it seemed very difficult to see what the Transputer was going to solve. IIRC it ended its days as a disc controller.
A thousand years later when graphics card manufacturers suddenly seemed to realise they were making massively parallel computers, I'd really like to know if there is a book explaining "there" to "here"
It came at a time when the major problem in computing was segmenting in DOS/Windows. I imagine if someone had stuck 16 of these on an IDE card and written some games/graphics handling software for them we would be in a different world now. The company seemed to go for MOD and big customers seriously restricting the number of people to get to play with it and make inroads into a new world.
Its easy to diss the company's handling of their product in hindsight, many wrong turns were taken in the 80s - 8088 for the IBM PC and not the 68008 is probably the worst - but these toys were new and no-one knew what games they'd be used for, and who would have predicted games would have more effect on PC development direction than millions of engineers and scientists and a few warmongers!
[Author here]
There are a bunch of things that remain difficult problems, as I understand it. (I am _not_ an expert in parallel systems or anything!)
Transputers had hardware-controlled comms links, so building meshes or grids of them was relatively easy. No modern chip has that. Instead, we have processors with lots of independent cores, but it's the OS's problem to allocate tasks to cores and use them efficiently.
A little bit of that was in hardware in Transputers. There was also the Helios OS, which I've written about recently on the Reg.
https://www.theregister.com/2021/12/06/heliosng/
... and the Occam programming language, which was designed for parallel programming.
https://www.theregister.com/2022/05/06/pi_pico_transputer_code/
[Extremely simplified big-picture hand-wavy explanation]
C is not inherently parallel and does not have direct structures for this. The OS has to handle it; transputers brought that right into the language.
But Unix isn't inherently parallel either. It was built for a non-networked minicomputer with text terminals. That's why "everything's a file" and so on.
So, now, because there is so much investment in xNix and xNix code, it's being painfully added into a traditional xNix, instead of everyone moving onto Unix's appointed successor, Plan 9, or Plan 9's successor, Inferno. They have networking right in the kernel: processes can move directly from one network node to another. You can't do something like that on Linux except extremely clumsily by migrating a VM or getting Kubernetes to manage a cluster of nodes running containers: millions of lines more code on top to fix something that was built into Plan 9's kernel...
And which was done in a mixture of hardware and the programming language in Occam on Transputers.
Some of this is being reimplemented, slowly and painfully, in Go and Rust and things... in a much more difficult, complex form, in code at least 1000x bigger and more complicated and less capable and less flexible.
Nature demonstrates that the way to build a big computer is from extremely large numbers of small slow computers with lots and lots of communications links. Instead, we're building very big, hot, power-hungry computers, with no direct support for comms between them. So it's hard to communicate from one core on one chip to another core on another chip. They don't scale very well. The only way we've found so far is big clusters, with lots of computers all chewing on different bits of the same data set and not really talking to one another much.
In a lot of ways, because late-1980s OSs and languages didn't natively do hard stuff like multiprocessor support, clustering, memory protection, all sorts of stuff that FOSS xNix and Windows NT finally solved using minicomputer technology in the early 1990s, back in those days very smart people worked hard on coming up with incredibly clever fixes for the problems of parallel computing and so on.
But it was never mainstream and didn't catch on.
Then a decade later this became easy and mainstream with modernised 1970s tech, and the industry lost 15-20Y of progress and went backwards.
They were amazingly innovative for their time.
I actually came to building PCs after seeing an INMOS engineer open one of our PC at university, slap an ISA transputer card in, install the whole toolset. It was really a reveal.
Shame INMOS never really took up. The tech. was sold to STM, which promptly binned the tech.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
