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!burl!ulysses!mhuxr!mhuxt!houxm!mtuxo!mtunh!mtung!mtunf!ariel!vax135!petsd!peora!jer From: jer@peora.UUCP (J. Eric Roskos) Newsgroups: net.arch Subject: Re: 16+ bit Op-systems: where too? Message-ID: <1421@peora.UUCP> Date: Sat, 3-Aug-85 23:31:03 EDT Article-I.D.: peora.1421 Posted: Sat Aug 3 23:31:03 1985 Date-Received: Tue, 6-Aug-85 20:07:21 EDT References: <12200013@orstcs.UUCP> Organization: Perkin-Elmer SDC, Orlando, Fl. Lines: 55 I have a little trouble following the overall suggestion here. You say "seven boot operating systems" (?) ... you mean you want seven object images of the same OS on the disk, one for each processor? You'd need more than that... different device drivers for each distinct machine (obviously, even with 2 machines with the same instruction set, there's a lot else that can be different), etc. You'd also have to have seven object programs for each of your applications. It would be hard to do (unless all the machines ran a p-code interpreter, of course, like under the UCSD p-system, which is fairly close to what you are suggesting). Aside from all that, though, I have some basic architectural disagreements with your description of user processes. > 1) we do want a program to be considered an extension of the > operating system (a process), rather than a subroutine > which is called by the OS. UNIX treats programs as shell > extensions, MVS + RSTS + DOS 3.3 + SOS don't. I don't think that under Unix programs are considered an extension of the operating system, at all. That is indeed true on some IBM OS's (back when I last worked with IBM machines, MVS was called "VS/2", but I think it is probably still true); but not in general. Under Unix, and most other reasonably-designed operating systems (I know this is true of MS-DOS; I am not sure about the others you mentioned), the operating system is essentially a library of privileged subroutines for the user processes. Now, under Unix there are several privileged processes that cause things to be done on the OS's behalf (e.g., the swapper, the process initiator, etc.), but the OS is essentially passive. Even the scheduler is somewhat of a coroutine invoked by the user processes as a side-effect of their doing other things. (This disregards the interrupt-level routines in the device drivers, which can be thought of OS processes too, since they are there largely for efficiency -- you could do all the I/O synchronously, and then they too would be just subroutines of the user processes.) > 2) multi-tasking. Multi-user is clumsy on a micro, but multi- > tasking is a joy. (I edit in Turbo while I run MASM while...) If you do multitasking right (on a microcomputer or whatever) you get "multi-user" for free. (Except for protecting the users from each other.) > 3) pipelining + redirection. This is a very useful extension > of the process theory. Really this is a "useful extension" of the uniform-I/O principle: you can do redirection easily because I/O is the same regardless of what it is being done to (except for addressable vs. non-addressable devices). Pipes are a special kind of I/O, though, inasmuch as they include process synchron- ization, so you're right about that. -- Shyy-Anzr: J. Eric Roskos UUCP: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer US Mail: MS 795; Perkin-Elmer SDC; 2486 Sand Lake Road, Orlando, FL 32809-7642 "Vg frrzf yvxr hc gb zr."