Newsgroups: comp.sys.amiga.advocacy
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!csn!kessner!david
From: david@kessner.denver.co.us (David Kessner)
Subject: Re: 8-bit death
Message-ID: <1991May2.013735.6365@kessner.denver.co.us>
Organization: Kessner, Inc.
References: <1991Apr30.113402.2522@sugar.hackercorp.com> <1991May1.070516.3257@kessner.denver.co.us> <1991May1.120729.13618@sugar.hackercorp.com>
Date: Thu, 2 May 91 01:37:35 GMT

In article <1991May1.120729.13618@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes:
>A 16-bit O/S is designed for the environment provided by 16-bit micros and
>minis. It takes advantage of the extra address space available to provide
>scheduling, memory management, device management, and so on. In a 16-bit
>O/S 90% of programs don't have to deal with the hardware directly for
>anything: the operating system provides the services it needs.
>
>An 8-bit O/S is designed mainly to provide the basic tools needed to load
>programs and manage files in the minimal space possible.Things like scheduling
>are irrelevent: there's no way you could run more than one functional program
>at a time in the 64K anyway.

By your definition, I could write a 16 bit OS for the 6502.  While it only has
a 64K address space, I could make it _MULTITASK_ (love that context switch
time), resource tracking, device management, etc.  In fact, the only thing
that would be difficult is running large programs (or lots of small ones),
virtual memory, and memory protection.

Now, if I could do that with a 6502 (and it's THREE 8 bit registers and 256
byte pages) imagin how much easier it would be with a different CPU with more
registers (16 bit at that), and 64K 'pages'.

Nothing you mentioned is dependant on the magic 8 or 16 bit numbers.


>A 32-bit O/S provides even more hardware transparency than a 16-bit one.Demand
>Paged virtual memory hide the limits of RAM,networking hides the limits of the
>disk. The sophisticated memory management hardware on 32-bit processors allows
>all this to work.

The things that you mention are more dependant on MMU's rather than anything
else-- like the 'number of bits'.  An MMU is requires to give you memory
protection and virtual memory.  Networking is certainly not dependant on
the 'number of bits'.


>But I *do* equate Ultrix with UNIX. In fact, anything that provides the basic
>35 system calls from V7 days is UNIX.

Ultrix (on the PDP-11) was in many respects a 16 bit operating system.  It 
only did a very strange varient of VM, overlays (which were required even
though it had virtual memory) were limited to 8K.  Programs were limited to
64K in size.  

While it is somewhat UNIX like-- it is sufficently different from what most
folks think of UNIX (like System Vr4) that it _MUST_ be thought of on it's
own accord.  Just because it has the "basic 35 system calls from V7 days"
may mean it is very much like UNIX, but that it is not identical to other
UNIX's.

Likewise, MS-DOS is very similar to CP/M-- but it is different enough to be
considered on it's own endowments.

>> Facts, man-- just the facts.  _WHY_ isnt it a 16 bit OS?
>
>See above.

Thank you.


>Peter da Silva.   `-_-'
><peter@sugar.hackercorp.com>.
-- 
David Kessner - david@kessner.denver.co.us            | do {
1135 Fairfax, Denver CO  80220  (303) 377-1801 (p.m.) |    . . .
If you cant flame MS-DOS, who can you flame?          |    } while( jones);
