Before the two of us get too senile and demented to remember what went on, we thought we should contribute to Edinburgh software history by putting down what we remember of the actual software happenings in and around Moray House from 1975 to 1981. Although separate from the University’s Computer Science Department, many of the fundamental ideas from the department were used and developed during this period. One wonders what might have happened had there been someone to force Edinburgh’s vibrant computer community to put energy into publishing and promoting the impressive work going on there. Lesser efforts from elsewhere achieved fame, but Edinburgh was almost unknown.
Here, before getting into the main topic, we must acknowledge the contribution of Peter Barker, Head of Computing (later Maths & Computing) at Moray House, without whose considerable encouragement and support Mouses would have been stillborn. He had the foresight to realise what was possible when all around him were quite incapable of seeing past FORTRAN, BASIC and punched cards. In this he got no support whatsoever from either the Scottish Education Department, most of his staff, or any of the other colleges. The tacit view was that implementing an operating system was not a proper activity for a teacher training college. Peter Robertson [PSR] and Chris Whitfield [CW] did the technical development work but Peter Barker made it possible by his support, using his budget as he did, and in many other ways.
In 1975 CW was working for Moray House College of Education Computing Centre and had persuaded the college to replace an ageing IBM 1130 with a 256KB Interdata 7/32 in preference to a 16-bit Data General Nova. The 7/32 was an interesting, 32-bit, byte-addressed machine with a strong IBM 360 flavour. If memory serves, Interdata claimed it to be the world’s first 32-bit mini. The Interdata was chosen on the basis that it (i) had integers of a sensible length and (ii) was able to run IBM 360 FORTRAN programs with minimal modification. FORTRAN was very important to the Scottish schools at that point.
Very soon after the machine’s arrival, CW prompted PSR to port his IMP compiler to the new hardware so sparking a friendship that still persists.
The compiler originally ran as a cross compiler on EMAS, but CW wrote a subsystem for the Interdata's OS/32 operating system and the compiler soon supported itself in native mode. As Hamish Dewar has noted, there is a compelling fascination in watching a compiler compile itself for the first time.
One thing became obvious very quickly: that any serious development work under OS/32 was a real pain. It was really nothing more than a stretched batch system with interactive facilities amounting to no more than a number of “BASIC” terminals[2]—in every sense of the word. The only truly usable thing in the system was CW’s OS/32 subsystem, providing basic terminal facilities such as file editing, copying, printing and so forth and access to his assembly code port of ECCE.
A major OS/32-induced limitation was that there was no way of inserting a file into the batch queue, so having edited one’s source files it was necessary either to get access to the operator console or feed in a small pile of cards to compile and run them.
Perhaps the most memorable "feature" of OS/32 was the time it took to boot. If you neglected to shut it down properly or the system crashed (frequently!), it could take up to an hour to get it going again as the whole file system had to be explored and reconstructed. After the luxury of EMAS, we got so fed up with all this that we decided to write a simple, multi-user, interactive operating system of our own.
Not surprisingly, the first design objective was to have a file system that was hard to corrupt. Also following from the EMAS philosophy, the system was to be written in IMP.[3] As is traditional in these things, getting the right name was the most important technical problem. Since it was to be a Moray House System, the name “Mouses” almost wrote itself. Silly names were to be a bit of a theme in the system; PSR named one of the system processes “Potter” (not Harry), because it managed queues (memories of playing snooker instead of going to Physics lectures in his second year of University).
All the early work was done in our own time in the evenings (7pm to 9pm) and on Saturday mornings while also trying to survive janitors and schoolchildren.
On one famous occasion our activities led to a fraternal meeting of the janitors and their shop steward in the courtyard outside the computer room. While nominally the college was open until 9pm, in practice nobody was ever there so it had become accepted that it be shut by around 7.30pm most nights. By working right up to 9pm every night we had upset longstanding tradition. They apparently wanted overtime for working time they were already paid to work. We quickly got used to the merry sound of janitors standing outside the machine room door jangling keys loudly after 8pm.
The schoolchildren used to come in on Thursday evenings with their teachers to “use the computer”: running small BASIC or FORTRAN programs. One evening the operator was becoming increasingly frantic because the card reader kept jamming and tearing cards. Eventually we discovered the culprit was one enterprising student who had tried to save paper. Instead of throwing away mispunched cards, he would sellotape chad back into the holes to correct his mistakes. He was soon shown the error of his ways. On another evening, a student had a FORTRAN program that didn’t work and, as the teacher was busy with another pupil, he approached PSR for advice. The problem was confusion in the complex GOTO knitting in the small program, obscured by the “everything starts in column 6” style of layout. PSR explained the problem and showed how to use indentation to make the structure clear. A little later the boy returned beaming with a carefully indented program that had worked. Ten minutes after that, the teacher angrily informed PSR that “academic trifles” like indentation were a complete waste of time and had no place in teaching people to use computers. PSR’s considered response has got lost with the passing of time.
PSR vividly remembers working out how to start bootstrapping the system. The first, primitive supervisor was written as a single, stand-alone IMP program. CW's framework would load this and start it running under OS/32. The problem now was to gain full control of the machine, as the fledgling system was running in a protected virtual address space. Trying to use OS/32 to load a real-mode program seemed like advanced masochism, so we didn’t bother. The solution was to use the floating-point registers (another idea taken from EMAS). The 7/32 had firmware floating point and the floating-point registers were just the first 16 32-bit words of real memory. So the system loaded a tiny bootstrap[4] into these registers and went into an infinite loop. Manually stopping the processor and restarting it at location 0 executed the code in the floating-point registers (sorry, bootstrap) in unprotected, real mode. The bootstrap mapped the address of the user code from virtual to real, by reading the segment registers, and then jumped there. The supervisor, now in real mode and privileged, relocated itself down to real address 0 and we were off. Even in its earliest stages (single-user, no file system: contiguous files, hand-allocated, and identified by disc block address) the system felt more user-friendly than OS/32. It even had novelties like type-ahead and character erase.
The final file system fully met its design goal—it was almost indestructible. The look on the face of Dave McKenzie, the system manager, when PSR turned the processor off in mid-flight and got everything back up again in 30 seconds said it all. That one demonstration convinced him that the new system could be a replacement for OS/32.
One limitation of the design was that each user had a maximum of 42 files (nothing at all to do with Douglas Adams). That concentrated the mind wonderfully! Still, you could have multiple user spaces and switch between them easily, so it wasn’t as bad as it sounds—each project simply became a separate user. The very high resilience more than compensated for any minor inconvenience by ensuring high uptime and practically no data loss.
As the date conversion algorithm used by Mouses has been mentioned in other postings, we might as well correct a minor error (pace PMcL). Following a suggestion from Sidney Michaelson, PSR derived the code from the Algol version published in the Collected Algorithms of the ACM, conveniently located in the JCMB library; it was not “stolen” from the filestore—PSR still even has a fading photocopy of the relevant pages taken at the time.
The system was successful, with a 256KB machine supporting up to 8 interactive users (mainly edit/compile/run) and a background batch stream. The Interdata memory segmentation hardware was primitive. Notably, a segmentation fault was fatal. With no way to retry a failing instruction, the system had to swop the whole of a process into memory before it could execute. PSR estimated that we could have gone up to about 12 interactive users with the same response time had this not been the case.
We had both come from an EMAS background so the “modern” inventions of dynamic linking and automatic sharing of executables were implemented as a matter of course. The system also had a simple dynamic priority scheme, adjusting a process’s priority depending on its behaviour to maximise interactive performance.
In the absence of user terminal interactions, the basic time-slice unit was allowed to increase without bound, slowly and in small increments, to ensure that the need to swop whole processes (see above) did not result in large jobs thrashing. Concurrent large offline jobs could therefore yield very high resource utilisation. Detection of “interaction” was delightfully simple: the Mouses scheduler simply reset the time-slice unit to its standard value if anyone typed a “return” on any terminal.
For those unfamiliar with the era when computers had ‘lights’, the 7/32 had a set of 32 LEDs set by the microprogram when the machine halted. A pattern could also be loaded into them by a running program. For the 16 lowest-numbered processes, the Mouses scheduler turned on the corresponding light when passing control to that process. These lights demonstrated very clearly the scheduler behaviour and the fact that the processor was being kept busy.
Mouses rapidly became the system of choice at Moray House, and even further afield, although OS/32 still had to be used for compiling and running FORTRAN programs—but not for long. This difficulty was resolved by CW writing an OS/32 emulator that ran as a normal user program under Mouses.
Mouses system calls used only a single hardware supervisor call, and that was unused by OS/32. All other SVCs fired an illegal SVC trap. The OS/32 emulator intercepted these traps, and did the appropriate thing, providing, importantly, compilation and execution of FORTRAN using the standard Interdata tools. “The emulator”, as it came to be known, was so efficient that you could compile and run FORTRAN considerably faster on Mouses than under the native OS/32 system.
CW wrote many of the system components. PSR remembers returning from holiday to find he had produced a remote card reader driver and a complete batch subsystem.
The card reader interface generated one interrupt per card column and even the raw Interdata hardware had serious difficulty in responding quickly enough. The solution was a “front-end” Interdata 5/16 processor, connected to the main machine through a standard RS-232 serial port. This link was used both to load the control program into the front-end from the 7/32 and to transfer data from the card-reader. Given a programmable front-end to control the card reader it was possible to off-load card-code translation from the main system. The front-end performed appropriate translations for processing standard alphanumeric punch cards and mark sense cards, in both cases identifying a bad card and stopping on it. This most certainly made the operator’s task a great deal easier. Further, by using the 5/16’s 64Kb memory to buffer input data, the card reader could be driven in long bursts, substantially reducing the number of jams, which tended to occur when the reader was driven in a “jerky” manner.
As with the filesystem resilience, the practical fact of being able to feed in a couple of hours worth of batch work in one go then leave for his lunch, made the operator a strong supporter.
We were both pleasantly surprised at the stability of the system and only remember one significant problem. Every now and then when the system was heavily loaded, everything would suddenly stop. The system would sit there with the lights static. More often than not, after a few seconds, everything would carry on as if nothing had happened, but sometimes the only solution was to power the whole system down and reboot. The cause was eventually tracked down. We were sitting in the machine room one evening with 8 users, all compiling, and a FORTRAN batch stream running. The system stopped. Then it started again, only to stop once more. We noticed that immediately before each time it stopped, the “big disc”, a multi-platter replaceable disc drive, was shaking around like a washing machine full of wet towels on fast spin. With all the system activity, the drive was constantly being used to swop segments in and out of main memory, giving rise to dramatic seeks across the full range of the heads. With the system hanging, we went over to the drive and looked at it. There was a front panel with various controls and a small, white, replaceable, plastic “key” that you pushed in to give the drive an identification number (0..F). This seemed to be at an odd angle, so we tapped it—and the system started up again! All the shaking from frantic seeking had worked this key loose. Now and then it would move and the drive’s identification number would be changed. Pending transfers stopped but the system didn’t get any errors, as it just looked as if the disc were taking a long time to respond (who else had experience of the dreaded selector channel?). With disc activity stopped, the key would usually fall back into position and the disc would magically start working again after a timeout. The system was suitably patched with a piece of sticky tape and the problem never returned.
Eventually the system had two Imp compilers. The first, PSR’s original, was used to bootstrap everything including itself and to compile the whole system. It generated pretty good code but its run-time diagnostics left something to be desired for student use. CW constructed a production compiler for general use by completely rewriting the second pass following the existing model but changing the emphasis to good rather than the best code and requiring very good runtime diagnostics at an acceptable cost. This compiler included very comprehensive runtime checking that ensured anything that could reasonably be checked was checked. The novel aspect though was that the compiler also went to considerable trouble to omit redundant checking code. The overhead of full runtime checking on a typical large application program was about 5% on runtime and 10% on code size. It is at least arguable that around 1979-81 this was the most thorough diagnostic Imp compiler available.
Moray House had various critical FORTRAN application programs used for such things as standardising school examination marks. These were rewritten in Imp and routinely run with all diagnostics enabled to obtain better protection from data-dependent errors. While the “low overhead diagnostics” work was very interesting in its own right, the practical justification was the increased confidence in the output from these important DP applications. Anyone with doubts here should think back to the fall-out from the Scottish Qualifications Agency saga of school year 2000/2001.
Lattice Logic also used this compiler in
their very early days where it achieved a degree of notoriety by wasting a week
of Irene Buchanan’s time.
Its diagnostics, as everybody knew, were impeccable and utterly
trustworthy. Unfortunately a compiler
error caused the first local variable of each procedure not to be checked for
“unassigned”. Irene had an obscure
failure ultimately caused by an unassigned variable that the compiler had
failed to detect. This was only finally
uncovered when PSR examined an assembly code listing of the generated code
after Irene’s hours of unfruitful puzzling.
CW also made dramatic improvements in the speed of the compiler’s third pass when it was dealing with selecting the optimal size for jump instructions (the Interdata 7/32 had 16-bit, 32-bit and 48-bit jumps). PSR’s original algorithm, developed for the Interdata 7/16 compiler, processed the entire program’s jumps as a single list. CW’s version used an evolutionary development of this, building a 2-dimensional list then dealing with jumps first “by procedure” then globally. This two-stage approach reduced the time to fix the jumps in the compiler itself (on an Interdata 7/32) from around 31 seconds to under 2 seconds. It was quite entertaining to be re-introduced to this “revolutionary technique” some ten years later on a stand at Cebit; also to see a much later Computer Journal article, by an ex-Edinburgh person, of work clearly based on the older (Interdata 7/16) version which the Moray House developments had long since superseded. One can only wonder at the source of his inspiration!
Mouses was a serious operating system, designed and developed over a period of two years to be used “in anger” for real work and not as some theoretical exercise. It was liked by everyone, except the original nay-sayers in the Scottish Education hierarchy, and successfully supported the computing requirements of Moray House and the surrounding schools (via dial-up lines) for around four years until the hardware was replaced. With the benefit of hindsight it was probably one of the bigger operating system projects going on, certainly in Scotland, at the time.
Its practical performance in a college context was so good that, once the story got out, Moray House was besieged by requests from Lothian Region schools for terminal access. The superior batch performance greatly reduced the amount of work involved in running the substantial numbers of school jobs processed every day compared with both the manufacturer’s system and its IBM 1130 predecessor. It greatly facilitated the turnaround of the “mark-sense” scored multiple choice papers used for some of the college examinations. The college was ultimately able to have results up on the board (late) the same day as the examination with confidence that these results were accurate.
The reason we quote the foregoing is that, while we were immersed in the technology of Mouses and fascinated by it, the system was actually exceedingly effective in a “cost-benefit” sense. Many consider this unusual in computer system projects even today!
An IBM 4130 monstrosity running VM/CMS eventually replaced the Moray House 7/32 in 1981. This was a purely political decision with no technical or indeed practical merit as the aspiring politicians found out over the subsequent year. In essence it turned out that none of the more valuable things that Mouses had done were sensibly possible under VM/CMS. Particularly, Moray House was left to live with the consequences of being able neither to read mark-sense cards nor to supply an in-school interactive service because of IBM’s exceedingly poor support for serial terminals. The final upshot of this was that the Scottish Education Department removed IBM from their approved suppliers list for five years.
For most of its time in Moray House, the 7/32 was switched on in the morning and switched off at night. The Interdata engineers would come in regularly to tweak the phasing settings on the core memory, as these were prone to drift because of the thermal cycling. Without this maintenance the hardware rapidly stopped working. We both tried many times to get the machine left on all the time, but the Moray House authorities insisted that this was utterly impossible. IBM turned up, stated that their system was never to be turned off, and all objections vanished. The 7/32 was left in a corner, turned on all the time, to be discarded once it failed (estimated at a week or two). It lasted for almost the whole of the subsequent academic year before failing.
Postscript
A later existence, “post Mouses”, saw PSR at Lattice Logic and CW at Perkin-Elmer, which had by now acquired Interdata. In this role, CW persuaded his employer that a Pascal compiler built around the technology described above would be of advantage to them. PSR constructed this compiler yielding a combination of compilation speed and code performance that surprised especially Perkin-Elmer’s Ada developers in New Jersey.
At this point, Perkin-Elmer was porting Karlsruhe University’s portable Ada to the PE-3200 from Karlsruhe’s Vax. The portable Ada generated a huge Pascal source that had to be compiled as a single unit. Perkin-Elmer’s existing compiler was simply incapable of doing this, whereas ours swallowed it without a burp. Indeed, it could compile and optimise the 250,000 lines of contorted Pascal far faster than their linker could process the result!
The Pascal compiler played all sorts of tricks; not the least was moving procedures around to minimise jump sizes. One of the Ada developers discovered that the compiler always (he thought) put a particular routine at the start of the object file. He used this fact to control a primitive debugger. Unfortunately, the compiler actually sorted procedures by size, putting smaller functions first to minimise the size of call instructions. It would then put the most-referenced procedure first, as this allowed it to be called with a 16-bit instruction (BALR 15,10). One day the Ada developer made a trivial change to the Ada compiler and his debugger stopped working. He eventually discovered the change had made another routine the most frequently mentioned in the program, so the compiler had decided to put that one first instead.
As a side benefit of the above, after leaving Perkin-Elmer, CW spent a happy three weeks in Karlsruhe with two Perkin-Elmer programmers. Apparently, though PSR’s compiler could compile the 250,000 lines incredibly quickly, the resulting object program always failed with an unassigned variable, while recompiling with the unassigned check disabled simply produced an immediate invalid address failure. To cut a long story short, it emerged that VAX Pascal initialised the whole stack area to zero and the implementers of the portable Ada had punned on zero/NULL, assuming that all references would be NULL by default. We initialised variables to the well-loved value x’80808080’ (unassigned) with predictable consequences. The Karlsruhe team remained reluctant to agree that this dependence on a particular DEC compiler’s conventions might compromise their claimed portability somewhat.
[1] Mouses passed system messages in the floating-point registers; all messages were 32 bytes long with 8 bytes taken for routing information. This left 24 bytes, into which an IMP %string(23) variable could be placed. The system had a service to use this to send short message to users, to warn of system shutdown and the like. Enterprising students wrote code to hijack this mechanism and print random text strings to user terminals. These messages could be up to 23 characters long and many ingenious phrases were invented. “Nibble a happy warthog” was one such (22 characters plus a leading CR to overwrite the system-generated prefix). On one memorable occasion, a hapless Computer Science user was sent scurrying for the hardware engineer after receiving one of these gems masquerading as a hardware failure—but that’s another story
[2] Perkin-Elmer’s MTM (Multi Terminal Monitor) came much later.
[3] The source of the resulting system was entirely IMP but for the 78 in-line machine instructions required to interface with the hardware and was in that sense more “modern” than many later systems.
[4] Writing tiny bootstraps seems to have been a popular pastime in Edinburgh—Hamish Dewar and Chris Whitfield were leading exponents of the art.