Posted by s.hettrick on 11 October 2013 - 1:48pm

By Ian Cottam, IT Services Research Lead, The University of Manchester.

The next post in my series on heroes of software engineering focuses on David Howarth – and the Atlas Supervisor. This software system was so good and revolutionary that Per Brinch Hansen described it as:

“the most significant breakthrough in the history of operating systems”

What came first: the chicken or the egg? In the computer world one might ask “what came first: the compiler or the operating system?” (You might also argue that the question is irrelevant as it was a while before high level languages were suitable for such machine-level work as writing operating systems.) In my case, and I suspect many others of my age or older, it was the compiler. My first computer was the Elliott 803B, which came with no operating system whatsoever but did have an Algol 60 compiler. The compiler was just loaded into the empty memory and ran on the raw hardware - that was once the norm.

Then in the early 1960s along came a computer – the Atlas – that was not just a tiny bit faster than the previous generation, it was a hundred times faster! That was one of the factors that led its co-designers (first Manchester University and then joined by the commercial company Ferranti) to the conclusion that an operating system was needed: they called it the Supervisor. Many of today’s terms for things in the computing world were different in the 1960s, especially on this side of the Atlantic. I already wrote memory above when I would have written store back then.

Today’s hero of software engineering, David Howarth, joined Ferranti when the work on the hardware and software for Atlas had already started. He tells a story (in How We Made Atlas Useable) of how his boss suggested he work on Tony Brooker’s Compiler-Compiler (chicken-egg time again?). Howarth soon saw what would be the key to Atlas’s success, and moved to work on the Supervisor. Howarth’s boss argued that Tom Kilburn and his team at Manchester had made the hardware so good that most of the work of an operating system – or Supervisor – was done. Of course, he was wrong about the software side of things, but right about what an advance Kilburn’s hardware was.

A small team worked on the Supervisor. Two of Howarth's colleagues were Bruce Payne (Manchester University) and Mike Wyld (Ferranti). It was soon clear that Howarth was the leading light, and I have never heard anyone from those days dispute that. One anecdote is told by John Crowther, who was a senior maintenance engineer supporting the two or three Atlas computers. Crowther regularly received updates (fixes and improvements) to the Supervisor from the development team: Howarth’s contributions worked 90% of the time - no one else beat 60%. When writing in a code that is one step away from machine code, and you have no real opportunity to test, a 10% failure rate in your updates is staggeringly good. You can see John Crowther, and many other engineers, on the excellent video Atlas 50 years on made by Google last year.

The list of features that David Howarth and his team gave us is amazing, and they feature in all modern operating systems to this day. Virtual Memory (VM) via demand paging was born with Atlas and made to work via the Atlas Supervisor. VM was actually a term that IBM would later use: it was known to the Atlas team as a one-level store. The small but fast memory was logically extended by an external drum store, but paging hardware and VM support in the Supervisor made it transparent to user programs. Interestingly, one VM design was used just for the pages of the Supervisor and a separate one for user programs. I’m not sure why that was done, and it seems to be accepted now as an unnecessary complication. (I’d be pleased to hear from any Atlas folks who might read this.)

How about multiprogramming? The – again, now common place – idea that the operating system can switch its processor from one program to another so quickly that it gives the impression that all the programs are running simultaneously. System calls and library calls via what were termed extracodes. These are unimplemented machine instructions that cause a trap or interrupt into the Supervisor where they are actually implemented by appropriate routines (e.g. for data transfers). One Atlas feature is not so common in these highly interactive days: the notion of spooling data from slow devices to fast[er] ones before running a job.

As a software engineer, I’ve always felt that my profession got less credit than our hardware or electrical engineering partners. I think in David Howarth’s case this was amplified by the 100x increase in raw processing power Atlas could claim over what came before. I hope inclusion in my small set of software heroes is welcomed, these 50 years on.

Note

On a personal note: I never got to use an Atlas, although I did visit one at London University (one that John Crowther saved from a flood , but that's another story). It was around 1969 when I was debating skipping higher education and had applied for a job as an Atlas Operator. That same year, I got a book from the town library on Atlas Autocode and taught myself to write some simple numerical procedures. I don’t count that as using Atlas or real programming, but it was fun and I have never looked back, thanks to my life long love of compilers (thank you Tony Brooker) and of course operating systems (thanks to David Howarth).