Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site peora.UUCP Path: utzoo!watmath!clyde!bonnie!akgua!akguc!codas!peora!jer From: jer@peora.UUCP (J. Eric Roskos) Newsgroups: net.arch Subject: Unix w/o Memory Mgt.; what the IBM PC could have been Message-ID: <1825@peora.UUCP> Date: Fri, 6-Dec-85 09:34:21 EST Article-I.D.: peora.1825 Posted: Fri Dec 6 09:34:21 1985 Date-Received: Sat, 7-Dec-85 20:58:30 EST Organization: CONCURRENT Computer SDC, Orlando, Fl. Lines: 43 In several of the recent postings on IBM PC's, it's been argued that Unix can/can't run without memory management; counterexamples have usually been based on unix look-alikes, however. In fact, Western Electric briefly provided a Unix without a need for any memory management, called "Mini-Unix", which ran on the PDP 11/03. This was done by swapping whole process images to disk each time a context switch was done, in order to avoid having to do any relocation. Drawbacks of this Unix were that it tended to be slow on context switches, and you could overwrite parts of the kernel via an errant user process. I don't know what became of this project; the point is that Unix can be made to run very well without memory management hardware if you incur the extra overhead, and forego the kernel protection. Actually, using old-fashioned technologies it would be possible to write a clean, fast OS for the IBM PC; but as soon as the PC came out, people went for the 64K restriction as a way to differentiate compilers, which pretty much eliminated any chance of ever implementing such a system. The problem was that people tried to jump from machines like the Apple II (which was sort of like a PDP-8) to a "micro-mainframe" (everyone wanted a VAX) without taking the intermediate step. -------- [Please try to minimize "not enough technical content" flames. If you want to discuss this topic, I can explain the old ideas; though I suspect most people familiar with "mainframe" machines know them, and I don't want to write long tutorials of little interest, when writing them takes *so long*. Basically, you could have partitioned the memory, using the segment registers as base registers, assumed a fixed 64K bound on process size, and written your compilers using the small memory model. The system would not be secure (since assembly-language routines could just change the segmentation registers and bypass the whole thing), but it would be possible to demonstrate that programs written in a HLL would be reasonably safe, as long as they didn't modify their code. The result would have been something like a single-CPU, multitasking 8080. Such approaches may seem impossible to the "do your own thing" hacker, but were quite common in early machines; they simply required discipline in programming.] -- UUCP: Ofc: jer@peora.UUCP Home: jer@jerpc.CCC.UUCP CCC DNS: peora, pesnta US Mail: MS 795; CONCURRENT Computer Corp. SDC; (A Perkin-Elmer Company) 2486 Sand Lake Road, Orlando, FL 32809-7642