[TUHS] Unix use of VAX protection modes

[Erik E. Fair via TUHS]

With regard to systems which didn't have address 0 in their user process address space (and thus dereferencing address 0 resulted in SIGSEGV), the first Unix (7th Edition) on a mc68000 was that way: the Dual Systems 83/80 S-100 (IEEE-696) bus system in November 1981.

Jeff Schriebman did the port, and founded UniSoft Systems not very far away from Dual in West Berkeley. Dual was UniSoft's first customer. Others: Apple Computer (for the Lisa - the parallel port based "Profile" hard drive was a horror), and a host of (Intel) MultiBus-based systems: Fortune, Pixel, Plexus, WiCat, CoData ...

Plop a 5 MHz mc68000 alas without an mc68451 (or other) MMU on an S-100 card, and how to protect the kernel? Split the 24-bit address space in half: bottom (from 0) for the kernel, top half (0x800000 and above) for user processes, and simple logic to test processor mode vs high (most significant) bit in any memory reference: any access of kernel address space (address msb = 0) while the processor is in user mode generates a trap or interrupt, such that the kernel can deliver SIGSEGV to the offending process. Base system configuration: 128KB RAM, 64KB for kernel, 64KB for user, literally in two S-100 DRAM cards with appropriate base addresses set in their DIP switches.

Naturally, all user software that dereferenced address 0 failed, and there was a lot of that to be cleaned up. Also, some customers told us that our hardware was wrong (nope - logic error on the part of the programmers who assumed address 0 was accessible, i.e., (*NULL); we didn't sell you a DEC PDP-11 which started this whole mess).

Also, yeah, Bourne shell's ... interesting ... notions of memory management: SEG fault? Catch it, and sbrk(2)! Doesn't work on the mc68000 because it didn't keep enough state for restarting faulted instructions unlike the DEC PDP-11 (Clem, do you want to chime in here to describe MassComp's extravagant solution to that?). Asa Romberger recounted the tale of refactoring Bourne shell for mc68000 to me while I was working for Dual and visiting UniSoft relatively frequently. The mc68010 fixed that incomplete fault state bug, and made demand-paged virtual memory possible for mc68k-family-based systems.

Virtually addressed memory came with the mc68451 MMU (but that had other awful problems which is probably so many mc68k box system manufacturers rolled their own MMUs). Before that, IIRC, Dual's Unix was swap-based: had to run each user process loaded from 0x800000 ... so put the ones you're not running in the swap partition of the system disk. Slow. It was even possible to run Unix from 8-inch floppies, which was even slower, but I knew a guy who did for a while.

I still have a lot of hate for USL because I spent a year cleaning up their bugs in System III, plus it was missing basically all BSD enhancements for better usability (the worst was not having the BSD tty line discipline, and job control). Dual never fully released it - by the time we were ready, System V was out, and we had to do it all over again.

	Erik