Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!decwrl!waikato.ac.nz!comp.vuw.ac.nz!actrix!ping!ping From: ping@ping.actrix.gen.nz (Peter Ingham) Newsgroups: comp.sys.amiga.advocacy Subject: Re: 8-bit death Message-ID: <165.tnews@ping.actrix.gen.nz> Date: 4 May 91 13:34:34 GMT Lines: 103 Quoted from <...unknown> by david@kessner.denver.co.us (David Kessner): > >Sorry, mate. 8-bitness is in the blood. The 8088 was a bag on the side of > >the 8080, and MS-DOS was a straight copy of CP/M, and there's no way to > >get away from that. > > Same song, second verse... Ho-hum... The 8088/8086 was designed to be an upgrade path from 8-bit 8080 to 16-bit. (I mention both, as they were release at the same time. The 8086 has 16-bit external data bus, 8088 and 8-bit. Very similar to the 68000 (16 bit ext) and the 68008 (8-bit external) in concept. They (8088/8086) retained many of the features of 8080 (at the assembly level) so that much existing 8080 asm code could be ported without significant effort. These were commercial decisions taken by Intel in order to provide backwards compatibility. Intel have continued to make similar decisions since. Motorola, by way of contrast, chose to develop a _new_, non-compatible path with 68000 when replacing the 6800 & 6809. Commercially you could argue that Intel's decision was correct, many followed their direction and they have sold MPU's at a rate _FAR_ exceeding _any_ other manufacturer. Architecturally, the 68000 series is far cleaner that 80xx6. This is the price you pay for maintaining backwards compatibility. Without getting into a RISC/CISC argument here, the same thing applies. if you ignore backwards compatibility, you can get a much cleaner architecture, but you loose out (short-term) on application availability. > You have effectively babbled, saying 'this isnt true, neither is that, this > is the way it is' but still have not sais anything worthwhile. C'mon, an > Amish is less passive that you are. Back up what you are saying! > Agreed > I contend that MS-DOS/CPM and 8088/8080 are different enough to be considered > in their own light. Never mind this "It's based on this/that" BS! Tell us > what features of MS-DOS make it an 8 bit OS. Was MS-DOS a _copy_ of CP/M? NO. Was it designed to provide close to identical facilities? Yes Does (did) it add significant new functionality over & above CP/M? No (Also please Do not confuse CP/M with other O/S's such as MPM. It does not add any clarity to this discussion) Similar Functionality Spec, different implementation. While the arguments presented have made semi-interesting reading, I fail to see the point here. What is an 8-bit O/S? - surely one that runs on an 8-bit CPU. I have never seen MSDOS running on any 8-bit CPU. What is an 8-bit CPU? - surely one that uses 8-bits as the predominant data-register size. (ie: a CPU that uses 16-bit registers 95% of the time but can combine them to 32bits for some operations is a 16-bit CPU) In a previous posting, Peter da Silva has been arguing that the _facilites_ provided by an operating system define whether it is 8, 16 or 32 bit. This is patently false. It is however correct to state that MS-DOS provides the *facilities* commonly associated with several O/S's written for 8-bit systems. Is MS-DOS an Operating System?? Some would argue that it is in fact an overgrown file handler, and little more. There were some rather competent _Operating Systems_ around for 8-bit systems (eg: Flex, OS/9). There are also some very competent operating systems around for 80xx6. These include systems that provide nearly all of the *functions* described by Peter - Proper Interrrupt driven, Multi-tasking, Multi-processing, Virtual Memory (in all it's implementations), Clean API's, inbuilt distributed processing etc etc etc etc. I think we all agree that MS-DOS is not one of these. Is MS-DOS 8-bit? WHO CARES. Does it provide the features I want? NO Is there an O/S that does? YES THEN GO & BUY/USE IT. > If you cant flame MS-DOS, who can you flame? Well there's still every Mainframe IBM ever made .... -- Cheers Peter S. Ingham ping@ping.actrix.gen.nz Lower Hutt, New Zealand