Hacking the computer with wirewraps and soldering irons: Just fix the issues as they come up, right?
The neverending battle betweeen youthful optimism and aged cyncism
Who, Me? Start your Monday with a cautionary tale from the files of Who, Me? and a warning (if one were needed) that hiring a teenager to write your operating system might not go so well.
Today's tale comes from "Matt" and takes us back to the mid 1970s and a university computer lab full of Interdata machinery.
Matt was looking for a programming job that paid better than working in the dining hall. The lab was looking for someone to come up with a virtual memory and timesharing system as much like Multics as possible for the new Interdata 7/32.
Multics (Multiplexed Information and Computing Service) was a timesharing operating system that dated back to the 1960s, and was therefore still very much in vogue at the time of our tale. It dynamically linked pretty much everything, and its influence can still be found lurking in the code of today.
Matt was faced with creating a Multics-like OS for the newly installed hardware (there were more than 50 researchers sharing the 3 or 4 computers in the lab, so timesharing was essential.)
"It didn't support paging," he recalled, "so we'd have to swap out entire segments, but it still sounded like a viable plan."
Every segment had its own simple symbol table and system calls were handled by calling into the kernel, which was mapped into segment 0."The only thing magic about the OS," remarked Matt, "was that when you called into segment 0, we'd change the protection so that segment 0 would be writable while running code within it."
Bonus nerd points for guessing the name of this operating system.
The team had a PL/I compiler ("think C with even crappier aesthetics," said Matt), which his boss had written in assembly language. The bulk of the OS, written in PL/I, was done in a semester.
"Note, by the way," added Matt, "that this place hired a single 19 year old programmer to write an entire operating system kernel from scratch, as well as a bunch of the user space commands.
"In hindsight, I have to wonder what drugs you have to be doing to think that's a viable development plan."
So how did it go?
Not entirely to plan.
"When we first started running programs on the new OS," said Matt, "I noticed that instead of getting the address of the *start* of the instruction that generated a missing segment fault, the processor gave us the address of the following instruction." No problem – the code just needed to look back to find the start. A tweak to the PL/I compiler and all would be OK, right?
- Electrocution? All part of the service, sir!
- You would expect a qualified electrician to wire a building to spec, right? Trust... but verify
- A 1970s magic trick: Take a card, any card, out of the deck and watch the IBM System/370 plunge into a death spiral
- Cruise, Kidman and an unfortunate misunderstanding at the local chemist
Er, no. "The reason that the reported fault address had been incremented to the next instruction was that the machine had actually executed the instruction," explained Matt, "using whatever noise was on the memory bus at the time the instruction executed."
Again, the compiler needed to be tweaked. "If you had an instruction like 'load r0, 800(r0)', loading register 0 from offset 800 from register 0, you were screwed," said Matt, "since if you took a fault executing this instruction, r0 would be corrupted and you couldn't restart it.
"But if you loaded a different register, you'd be fine to restart.
"Even worse would be 'add r0, 800(r1)' since it would add random noise to r0, again making it impossible to restart the instruction after loading the swapped out segment. So, that construct would have to be replaced with a load into a register, followed by a register-to-register add."
And so it went on. And the PL/I compiler itself hardly made things easy, being written entirely in assembly "and the implementer decided he'd fix the problems as they came up."
Just like the DevOps of today, we suppose.
The result was that if the OS discovered the instruction that trapped was of the verboten variety of opcodes and registers, the program would be rudely terminated with a
bad_luck signal, and the user would have to try running the program again.
"These, of course, would happen most frequently when the system was swapping badly and was already frustratingly slow," sighed Matt.
"Moral of the story: don't hire teenagers to write an entire OS. And RTFM before you start."
Some later users hacked around the problem by wiring the memory fault line into the register set select pin to make the processor switch over to a spare set of registers when a faulting instruction was executed. "This was back when this was all discrete logic, and you could hack the processor with a soldering iron and a wire-wrap gun," remembered Matt.
Interdata's later 8/32 resolved many of the issues ("and had a lot more segments as well," recalled Matt.) And as for the OS? Its time came to an end during the 1980s when, sensibly, the institution in question realised that running a slightly flaky, proprietary OS was borderline insane when something like Unix could be picked up pretty much for free.
Do you remember the glory days of bodging your way around bugs with wirewraps and a soldering iron? Or let the confidence of youth trump the cynicism of age? Make your confession with an email to Who, Me? ®