richardt@orstcs.UUCP (richardt) (07/30/85)
UNIX^tm has been ported onto 680xx's, Z800x's, 80xxx's (why we don't know...), and a number of people are working on porting it to 32xxx's. There's only one problem with UNIX on a micro: portability. UNIX is not designed for you to pull out a disk, walk to the machine 20 ft. away from you, and boot up. Even the micro implementations don't handle the problem politely. Given that we can't have (and may not want) straight UNIX on a micro, what do we wamt? for starters: 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. 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...) 3) pipelining + redirection. This is a very useful extension of the process theory. 4) windows makes a nice user interface... I didn't say mice, I said windows. Mice are an inconvenience for a hobbyist. The keyboard is a relatively natural input device. 5) a logical or semi-logical command structure (unlike unix) would be nice. 6) tree-structured directories make life FAR easier. And now for a truly revolutionary idea, if it can be pulled off: an OS which will run on all of the common 16-bit or wider processors. I'm serious. It would be nice to be able to plug my newest tool into the TI-Pro I usually work on and into the HP 68000-based machine here at school. points 1-5 are easy to implement, they're a fairly simple programming task. point 6 is another story. First, a system disk, or a very high storage disk drive becomes necessary. Why? Seven boot op-systems on one disk: NS32032, Z80001, Z8002, MC68000, MC68020, MC68010, 8086, 80186, 80286 ... correction, 9. thats roughly half a disk + applications. So, the system disk would contain: 9 boot systems, and a 4 each of Pascal, C, and Basic Compilers/Interpreters. Four of each because only one is needed for each processor family. That 9 shell/boot code figure can be cut down by using code which is self-modifying at load time. The boot disk also needs an assembler and loader for each family. Net result: at least 32 files representing one VERY packed 400K+ disk, or 2 moderately packed disks. That means carrying around 4 disks (2 boot, 1 source, and 1 code for your favorite machine), which is not an inordinate number. It also suggests a very effective programming style: write in an HLL, then compile, then kludge to maximum efficiency. But youi come out with portability that is unparalleled. This leaves one major question: Is it worth the effort to achieve a system which makes today's concept of portability look silly? orstcs!richardt "At last, I can see, where we all soon shall be" -- Judas Iscariot, Jesus Christ Superstar
jer@peora.UUCP (J. Eric Roskos) (08/04/85)
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."