Vintage multi-core – introduction
Sometimes I think that there is nothing truly new in the world. With technology, it is often a question of the time being right. On a previous occasion, I looked at programming languages and how what we use nowadays is mostly a development of 30-40 year old technology. It occurred to me that the current enthusiasm for multi-core designs is really nothing new. I browsed some of the literature and titles like “Multi-core is here now” have been appearing for at least 5 years.
But it goes back further still. I was working on a multi-core system in 1980 …
It was my first job out of college and I worked for a company that made materials testing instruments – large machines and systems that stressed and broke things under controlled conditions. The use of computer or microprocessor control was very new. Hitherto, the machines had been controlled by racks of analog electronics, with meters and chart recorders providing results. I worked in the division that provided the computer control. Initially, the approach was to simply link a mini-computer to a traditional console. The next – and, at the time, very brave – step was to replace the entire console with a microprocessor where a keypad enabled input of parameters and selection of settings on a screen.
The project, to which I was assigned, was to facilitate the “user programmability” of the new microprocessor controlled machines – the “User Programmability Option” or “UPO”. It was decided that the best way to provide this capability would be to add an additional computer instead of potentially compromising the real-time behavior of the controlling microprocessor.
The advanced console was built around a Texas Instruments 9900 microprocessor, which was one of the first true 16-bit, single chip devices on the market. It had quite an advanced architecture, with some interesting pros and cons: it could intrinsically support multi-threading in a very simple way, with context saving accommodated in hardware; but its registers were mostly RAM based, which, at the time, was a significant performance limiter. This part of the system was programmed in Forth. I have no idea why this design decision was made, but I found the language intriguing and I think it deserves a blog post of its own sometime soon.
The UPO computer was an SBC-11. The “11” came from the internal processor, which was essentially a DEC PDP-11; a mini-computer which was very familiar to us at the time. “SBC” was short for “shoe box computer”, because that is what it looked like. We implemented user-programmability using a variant of the BASIC language, with some extensions to access capabilities of the testing machine.
The two computers were linked together by a shared memory interface, which proved an interesting challenge to get right. In a further post, next week, I will outline the design of the inter-processor communication [IPC].
After many months of work, the project was completed and the system marketed. I made numerous customer demonstrations and I think we actually sold a few. I measured the success in terms of the technical achievement: it worked!
To be continued …
Comments
Leave a Reply
You must be logged in to post a comment.
About the same time (1980-ish) I was working with Intel when they introduced the iA432. This was a device for transparent multiprocessing>=. In theory, you could put any number you liked into a 2-dimensional bus matrix, one at each crosspoint. The buses were also linked to fast multiport memory; I can’t remember whether this was separate or whether it lived inside the 432. They sent the FAEs (I was in the UK contingent) on a training course for the beast an on another one to learn Ada. Ada was the language of choice for this machine as it had concurrency built in. Trouble was that tests on the hardware showed that performance levelled off with 4 processors on a single bus and declined for anything more complex than this, because the devices spent more time talking to each other than they spent doing useful work. The device was a little too far ahead of the technology, unfortunately, and the project was quietly abandoned. Pity, really, as by now its successors would be blazing along, well ahead of the game.
As a footnote, let us not forget, either, the transputer – another brilliant device which also used Ada as a programming language and which sadly was also consigned to oblivion.
Interesting story Peter, thanks.
I have not forgotten the Transputer for sure. Another technology ahead of its time. I even have an Occam manual on the shelf right here. [Really!]