Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!cbmvax!daveh From: daveh@cbmvax.commodore.com (Dave Haynie) Newsgroups: comp.sys.amiga.advocacy Subject: Re: 8-bit death Message-ID: <21216@cbmvax.commodore.com> Date: 3 May 91 15:23:19 GMT References: <1991Apr30.112820.2451@sugar.hackercorp.com> <1991May1.064455.3058@kessner.denver.co.us> <21135@cbmvax.commodore.com> <1991May3.041705.9907@kessner.denver.co.us> Reply-To: daveh@cbmvax.commodore.com (Dave Haynie) Organization: Commodore, West Chester, PA Lines: 80 In article <1991May3.041705.9907@kessner.denver.co.us> david@kessner.denver.co.us (David Kessner) writes: >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... I think what Peter was considering, rather than actually "machine size" of the OS, is a more generational thing. Computers have gone though many distinct generations, but especially considering small computers, you can break up the various systems that came out over the years into groups based on OS technology. If you do that, you find that MS-DOS adds nothing to what was available in the preeminent OS on 8 bit system, CP/M. And, in fact, it's a step backwards in many respects, because for all practical purposes it's one abstraction level closer to the hardware than CP/M was. >IMHO, the 'bits' of an OS is the largest number it can put in a CPU register. The programmer's model, which is what you're calling out here, can set an upper limit to the speed at which things will happen in an OS, but I feel pinning any number of bits on an OS is wrong. It is true that MS-DOS running on 32 bit systems is still only executing 16 bit operations, so you would call that a 16 bit OS. How about an OS like the original Mac OS, or OS/K, which work with 68000s, but being base register addressed, have 32K limits to code or data chunks. Are these 8, 16, or 32 bit operating systems? All three numbers apply, depending on where you look. These processors have a 32 bit programming model, but the OS has addressing limits reminisent of a bank-switched 8 bit OS, while the actual ALU and data bus on the CPU hardware is 16 bits wide. >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. Problem is, if you consider its history, the design makes some sense. Intel wanted an easy successor to its older part, and made an evolutionary step, not a revolutionary one. They didn't know where IBM would take the thing. If you take the 8088 on its own merits, especially in light of its use as the heart of a personal computer, you get the feeling they were both designed by monkeys. >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...) All 6502 systems had shared, active low, level sensitive interrupts. Z-80 based CP/M systems, the logical predecessor of MS-DOS systems if there was any, also had shared, active low, level sensitive interrupts. In many systems, this was done simply because you had a limited number of interrupts (guess what, if you allow expansion, you always do), more interrupt sources than inputs. Far as I know, the IBM PC is unique in the microcomputer world in getting this wrong. >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. You still want shared interrupts here. That's because each interrupt line determines priority. If you want to allow priority on your expansion bus, you're far better off having any number of shared interrupts available on each slot than slot-dedicated interrupts (Apple's contribution to NuBus) or, worse of all, non-sharable interrupts bused to each slot. Adding a vectoring capability means that vectored devices don't have to go through an interrupt server chain. It's really just an arbitration mechanism, the server chain, as on the Amiga, is software arbitration of the shared interrupt. Properly implemented vectored interrupts, such as the Zorro III bus' "Quick" interrupts, simply make the arbitration happen in hardware. You really don't want to lose the advantage of interrupt prioritization, even if you have vectors to make the arbitration process fast. >David Kessner - david@kessner.denver.co.us | do { -- 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.