OS4000: An Old, Fast, Micro-kernel-ish Operating System

I’m of the opinion that operating systems should be based on a micro-kernel and capability security — though I don’t yet have the courage of my convictions to run, say, Genode…. This item is mainly about some early influence on the micro-kernel side from a little-known system, which I didn’t appreciate at the time. I should say something about capabilities elsewhere. The point is that, despite conventional wisdom, such a system originally from the 1970s was fast.

Back when I was doing nuclear physics in the 1980s, we had an interesting workhorse computer system used for data acquisition and interactive analysis as well as accelerator control. It also provided backbone systems of the JANET (né SERCNET, né SRCNET) pioneering national network, amongst other things. I should record a bit about about what ‘we’ had built on it, but this is a bit about the basic system, increasingly lost to history despite fairly widespread use in the UK at the time.The Wikipedia reference is the only accessible account I know, though I still have some manuals.

The operating system was OS4000, running on GEC 4000 series hardware. These British real-time minicomputer systems, from the days when such things could be produced in Blighty, were quite interesting. I was glad we had them rather than the VAXen or -11s of most foreign groups;I understood we got them as a reaction to the nascent computer group contrasting them with PDP-11s (probably before VAX got going) at a trade show.

the system around them was a significant contributor to world-leading physics.

The feature of interest is that they ran at least the moral equivalent of a micro-kernel,I’m not sure why it wouldn’t be considered one, but I never heard it said.

and did so fast. Forget the idea that micro-kernels had to be slow until L4.

I guess — but can’t confirm — that ‘4000’ was an homage to the RC4000, normally thought of as the origin of the micro-kernel idea, albeit with a reputation for being slow and unreliable. It happens I used one as a student at the former Danish nuclear physics lab,I hasten to add it was old and seemed pretty steam-driven even then, with germanium transistors. Concerning its reliability, “Zje compuder ish aall shcrewwed uupp” was the phrase we took back to Liverpool (with its amusing accent, but worse standard of English than Scandinavia, like).

not realizing its significance at the time, or the likely connexion with our systems.

As well as ‘4000’, the name of the fundamental feature of the GEC architecture was suggestive of such an origin: Nucleus. This was the pioneering micro-kernel-ish component of the system. Well, whether or not it was strictly a micro-kernel, it was at least the moral equivalent of one, given its feature set. What made it special was that it was implemented in (micro-programmed?) hardware, which was presumably partially responsible for its speed.However, Nucleus was later done in software for the 63 series, the 4000’s intended successor, and in the last in the 4000 line on an M88k VME system. The software version was sufficiently fast on 1980s hardware.

French collaborators initially thought it slow on hearing the context-switch time in microseconds and assuming that it should have been milliseconds. The 4090 system used as the front-end to the central NAS 7000 IBM 370 clone had to be slowed down so that the NAS could keep up, and one could saturate the Ethernet of the time, which was unusual as I remember.

I don’t know the implementation details, but given the speed of Nucleus, even in software, relative to first generation micro-kernel implementations, I wonder what the secret was, and whether contemporary systems missed a trick.

The overall OS4000 operating system was built on Nucleus in the normal micro-kernel fashion. So, for instance, you could restart just the filesystem if necessary, and a process could restart a crashed driver. It supported hard real time processes mixed with non-real time ones, multi-processors (though we had the only dual-processor model sold), and was used in clusters.

In some ways the system was primitive, although it was from the early 1970s. For instance, aspects of the booted system were configured and fixed at ‘sysgen’ (‘system generation’) time. Also, apart from an enhancement done at the Rutherford Lab (and only used there?), user sessions had only a single process plus an ‘AIDA’ debugging one. That didn’t seem much of a limitation, especially if you used a system like OS/370 TSO, which we also did.You could ‘shell out’ of the ‘random editor’ (i.e. not stream editor) by saving state, having the wrapper execute something else, and resuming from the saved state, I think like the TSO editor on which it was modelled.

Anyway, overall the system worked rather well as far as we were concerned; it certainly made a contemporary VAX — the most widely used competitor (“All the world’s a VAX”) — look ponderous.

As well as the micro-kernel features, there was a very basic capability system,Especially basic compared with contemporary British commercial and research systems.

with capabilities fixed at sysgen. I assume that, along with the hardware implementation, helped the SCP-2 4000 series operating system get A1/B3 Orange book certification; I guess that was the basis of 4000 use at ‘The Foreign Office’, as it used to be referred to in Cheltenham when I didn’t know it was so secret.