Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: notesfiles
Path: utzoo!watmath!clyde!burl!ulysses!allegra!oliveb!hplabs!hp-pcd!orstcs!richardt
From: richardt@orstcs.UUCP (richardt)
Newsgroups: net.arch
Subject: 16+ bit Op-systems: where too?
Message-ID: <12200013@orstcs.UUCP>
Date: Tue, 30-Jul-85 01:52:00 EDT
Article-I.D.: orstcs.12200013
Posted: Tue Jul 30 01:52:00 1985
Date-Received: Sat, 3-Aug-85 03:28:13 EDT
Organization: Oregon State University - Corvallis, OR
Lines: 53
Nf-ID: #N:orstcs:12200013:000:2915
Nf-From: orstcs!richardt    Jul 29 21:52:00 1985

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