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. `-_-' >. 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);