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: <1991May3.041705.9907@kessner.denver.co.us>
Organization: Kessner, Inc.
References: <1991Apr30.112820.2451@sugar.hackercorp.com> <1991May1.064455.3058@kessner.denver.co.us> <21135@cbmvax.commodore.com>
Date: Fri, 3 May 91 04:17:05 GMT


Peter S. Writes:
>Tell me what features make it a 16-bit one. MS-DOS 1.X was a straight copy of
>CP/M-80, so how about starting there and tell me why a straight copy isn't
>the same sort of software. If you can't do that, tell me which of the handful
>of features added in 2.X make the difference.

As Dave Haynie said in his response (quoted later on), the OS is difficult
to quantify in nice neat numbers like 8 or 16 'bits', however...

IMHO, the 'bits' of an OS is the largest number it can put in a CPU register.
This is directly related to the speed of handling some OS functions like
calculating track/sector/etc offsets into a file system, generating CRC's
for error detection, etc.

In this light, MS-DOS is a 16 bit OS.  Plain and simple.

Now, you might want to throw other 'required features' into this definition,
but things like Multitasking, shared libraries, etc should not be a factor
in this-- since a 6502 could easily handle shared libraries...

>Yes, but it's not known to MS-DOS. Have you decided to include the ROM BIOS
>in your definition of MS-DOS? The HP-150 at work I'm using as a smart terminal
>has a completely different BIOS: does that mean it doesn't run MS-DOS?

Yes, I include the BIOS in the general scheme of MS-DOS.  Why?  For several
reasons:

	The operating system (and/or device drivers) should deal with any
	hardware differences between machines-- and that is the role of the
	BIOS.

	The BIOS is highly standardized.  In fact, they are (almost)
	interchangeable between machines-- as long as the machines have the
	same CPU and chipset there is a big chance that the 'other' BIOS will
	work.  The biggest difference is POST code and setup menus.

	The BIOS plays just a large of a role in the MS-DOS world as MS-DOS
	itself does.  When you do application programming, you try to call
	BIOS functions rather than MS-DOS functions (their faster, usually),
	etc.

	The BIOS is used by MS-DOS and MS-DOS only-- and the software that
	runs under it.  UNIX/XENIX use the BIOS for loading the kernal and
	then switch it out ASAP.  (According to Phenix, OS/2 uses a BIOS
	extention called ABIOS but my reference is old, 1989.  At any rate
	OS/2 isnt the topic here.)

I think of the BIOS as part of MS-DOS that comes with the machine.  Like
motherboard-ROM-Based-MS-DOS-drivers.


>Why don't you include the hardware as well? Or the application?

I don't (usually) include the hardware because it is only partially related
to the OS.  For instance, MS-DOS on a 386 is _not_ a 32 bit OS although it
does have 32 bit applications.  Especally in the Intel arena, the
destinction between 16 and 32 bit hardware is very clear-- the same can be
said for software.  Autocad 10 is clearly 16 bit (it runs on a 286), while
Autocad-386 is clearly 32 bits (and the 2-5x speed improvement is clear).

I know you asked that sarcastically, but the answer was worth stating.

>Right. The application has to take over because the O/S doesn't take advantage
>of it.

And this makes it a 8 bit OS?

>Peter da Silva.   `-_-'
><peter@sugar.hackercorp.com>.


In article <21135@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes:
>>In _every_ respect, the 8088/8086 is a _16_ bit CPU.  
>
>No, the 8088 is, of course, an 8 bit CPU from the hardware viewpoint.  Every
>chip can be viewed from the hardware prespective (what pins are on the actual
>chip), the chip architecture point of view (ALU size, etc.) or the software
>point of view (eg, programmer's model).

Ok, ok.  Point Taken!  :)

I goofed in combining the 8088 into that statement and not considering the 
external hardware point of view.

I say 'external hardware' because it's just that-- to the rest of the computer
hardware, the 8088 is a 8-bit CPU.  Internally the ALU and registers are
16 bit.  From the software point of view (which is the view MS-DOS has) the
8088 and 8086 are identical (with a few very small differences) and are 16
bits...


>>I'm sure that in the late 1970's this seemed to be the reasonable thing to
>>do, however hindsight shows it in a different light.  
>
>It was obviously not reasonable to anyone but Intel.  They felt it was 
>reasonable because it made the 8086/8 assembly code very similar to 8080/5
>assembly code.  

Yes, but every computer/chip maker has had those bad design choices.  C=
has the 1541 disk interface (no offence), IBM has the PCjr, etc.  Intel
has those 64K segments.  Luckly, on the 386 Intel has made those segments
4gigabytes in size so this is no-longer an issue to those of us that run
UNIX or 32-bit MS-DOS applications...

I like how you said 'very similar' and not 'identical'.  The 8088 should
be evaluated by it's own merits and not those of it's predicesors.  While
knoledge of the 8080/5 may provide insight into the workings of the 8088
it cannot be considered the last word.  After all, if you want to evaluate
a human you don't look at the monkey-- you look at a human!  (Although it
can be difficult to tell the two apart at times.)

In the same, MS-DOS should be evaluated by looking at MS-DOS-- not CP/M.


>>I really must say, however, that the addressing of the CPU has no effect
>>on the number of bits that the OS "is".  
>
>Only because it's impossible to represent the "size" of any OS as a single
>number.  At the very least, you need separate numbers for the addressing and
>operation size of an OS.  That makes MS-DOS a 20/16 bit OS, the Amiga OS a
>32/32 bit OS, Mac OS (at least System 6 and below) a 24/32 bit OS, etc. 
>according to this particular model.  But even that's an artificial measure
>for the most part.  

Exactly-- only I didnt include the numbers for the addressing size of the OS.
It is difficult to judge this number in the MS-DOS arena, however, since of
EMS/XMS (for that matter, are these 'part' of the OS?).  If we consider the
BIOS part of MS-DOS, and there are EMS drivers in the BIOS, then does the 
addressing size of the OS go up to 24 bits?  It's just a thought, however,
and I'll accept the 20/16 figures for MS-DOS...

They are only artifical numbers because these numbers do not greatly effect
the features of the OS.  After all, an 8-bit CPU can easily have all the
features of UNIX-- with two constraints, it has something like an MMU and
the kernal is not 'too' big for the memory space of the CPU.  

What the numbers do indicate is the amount of overhead the OS has-- and
is _loosely_ related to speed.  An 8 bit CPU can deal with 32 bit numbers
just fine-- it just takes several instructions to do what a 32 bit CPU 
could do in one or two.  This is the real 'bit measurement', IMHO.  If
MS-DOS were a 8 bit OS, when it added two 16 bit numbers it would add the
lower 8 bits, then the upper 8 (accounting for a carry).  This can be
extended to reflect the real world-- on a 386, when MS-DOS and MS-DOS
software adds two 32 bit numbers, it adds the lower 16 bits, then the
upper 16 bits even thought the CPU is perfectly capable of adding all
32 bits in one shot.


>>It is also a common mis-conception that the PC's intterupts are somewhat
>>lacking.  Well, the only thing they lack is a limit of 15 intterupt sources
>>on the ISA bus.  
>
>No, actually, it is well documented FACT that the PC's interrupts are brain
>damaged.  The whole point is that they are positive edge sensitive interrupts,
>and therefore can't be shared. The whole industry has pretty much decided that
>level sensitive, active low, shareable interrupts are a much better idea, long
>before the PC showed up.

This is more of a function of the hardware than MS-DOS.  For instance, the
386 provides 256 hard-vectored interrupts (very much like the 68000 series),
but the ISA bus (to the best of my knoledge) does not allow you to access
them.  If the hardware did allow you to use them, MS-DOS will let you use it
(although setting up these intterupts is different, and the BIOS should reflect
this change).  EISA is just such a beast, and even offers level-sensitive 
intterupts _AS_WELL_AS_ the normal ISA intterupts (Damn compatability).

I only mention the 386 because I know it more than the 286 or 8088 when it
comes to intterupts...  I would imagin that the 286 and 8088 offer something
similar-- perhapse with less ability.  It's the ISA bus and the Periferal
Intterupt Controller that is the weak link.

MS-DOS does not allow the sharing of intterupts-- even if the hardware
supported it.  It is because of common programming practace than of anything
else.  (My only experience with sharing intterupts is from the C-64, so with
that in mind...)  When the software shares intterupts, the new intterupt
handler wedges itself into the 'intterupt chain'.  When the handler is called,
it checks to see if its device caused the intterupt, if not it jumps to the
next handler in the chain.  Since for so long the hardware has not supported
sharing intterupts, neither does the software.  It does not jump to the next
handler in the chain-- although it remembers the previous handler and restores
it when the new handler is removed.  

MS-DOS and ISA/EISA aside-- I question the benifits of shared intterupts when
the CPU supports 256 intterupts, and more importantly, 256 intterupt vectors.
Using non-chared intterupts and more of those 256 intterupts the intterupt
latency can be reduced (since the CPU is not jumping from handler to handler
trying to find the right one).


>CP/M was specific to any Z-80 computer it had been ported to.  MS-DOS is 
>specific to any 8088 computer, as long as that computer is an exact clone of
>the IBM PC.  See the difference?  CP/M was processor dependent, but not
>system dependent.  MS-DOS, for all intents and purposes, is system dependent,
>as the owners of Tandy 1200s or Mindsets could well attest to.

Yes, and no.  CP/M is more widely ported, true, and that's because of it's
early history in a time where there was not a lot of hardware standards--
much like the history of UNIX.  

MS-DOS and the IBM PC were introduced at the climax of all of that and, for
better or worse, became a standard that everyone else copied.  This standard
really became evident in the latter half of the 80's where there were really
only two _major_ Hardware and OS standards in the busness PC world.  At this
point there was not much reason to make MS-DOS available on several CPU's.
In addition, IBM's proprietary selfishness made any early cross-platform
'hooks' non-existant.

Now that several million (3 million?) PC clones are sold each year, the 
point is moot, however.  How does that go, "A sucker is born every..."


>Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests"
>   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
>      "That's me in the corner, that's me in the spotlight" -R.E.M.
-- 
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);
