don@chopin.udel.edu (Donald R Lloyd) (04/16/91)
In article <m0jSNab-0003OuC@reed.edu> kuch@reed.bitnet (Jerry Kuch) writes: >I think the meaning that was intended is from the past, not the present. Of >course the 64 is no big deal today...8 bit micros are effectively DEAD! Find >a valid surviving computer that is in the C64's market now? The 8 bit micro >field is not current! Hanging on by its fingernails as it bleeds to death, >maybe... > "The rumors of my death have been greatly exaggerated..." CBM sold something in the neighborhood of 750,000 C64's last year. That's certainly not a thriving market, but it's far from a dead one. James Dionne, CBM's president (in the U.S.), said at the World of Amiga show not long ago that the 64 is "A machine that just won't die." Tell the millions of XT-clone users out there that the 8-bit market is dead. (Actually, IMHO, even a fast 486 qualifies as an 8-bit machine when it's running MS-DOS :-). Not intended as a flame or insult, just mild disagreement :-). -- Gibberish May the Publications Editor, AmigaNetwork is spoken fork() be Amiga Student On-Campus Consultant, U of D here. with you. DISCLAIMER: It's all YOUR fault.
kls30@duts.ccc.amdahl.com (Kent L Shephard) (04/18/91)
In article <16928@chopin.udel.edu> don@chopin.udel.edu (Donald R Lloyd) writes: - stuff deleted - > CBM sold something in the neighborhood of 750,000 C64's last year. That's >certainly not a thriving market, but it's far from a dead one. James Dionne, >CBM's president (in the U.S.), said at the World of Amiga show not long ago >that the 64 is "A machine that just won't die." > Tell the millions of XT-clone users out there that the 8-bit market is dead. >(Actually, IMHO, even a fast 486 qualifies as an 8-bit machine when it's >running MS-DOS :-).~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~ MS-DOS IS a 16 bit OS not eight bit. THe 8088 IS a 16 bit cpu with an 8 bit data bus. The 386sx is to the 386dx as a 8088 is to an 8086. That is 16 bits vs 32 bits and 8 bits vs 16 bits. Now tell me that a 386sx is a 16 bit cpu. Kent -- /* -The opinions expressed are my own, not my employers. */ /* For I can only express my own opinions. */ /* */ /* Kent L. Shephard : email - kls30@DUTS.ccc.amdahl.com */
peter@sugar.hackercorp.com (Peter da Silva) (04/21/91)
In article <e1Gj02be06fI01@JUTS.ccc.amdahl.com> kls30@DUTS.ccc.amdahl.com (Kent L. Shephard) writes: > That is 16 bits vs 32 bits and 8 bits vs 16 bits. Now tell me that > a 386sx is a 16 bit cpu. It's not the CPU, it's the software. Anything you run MS-DOS on is basically a CP/M box. A VW Beetle with a V-8. MS-DOS is an 8-bit operating system. As is MacOS (a VW Beetle with a great sound system). Xenix-286 and other swapping UNIX variants are 16-bit operating systems. As is AmigaOS. VMUNIX is a 32-bit operating system. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
blissmer@expert.cc.purdue.edu (Kevin) (04/22/91)
>MS-DOS is an 8-bit operating system. As is MacOS (a VW Beetle with a great >sound system). > Hmm. Are you REAL sure about that. I thought the MacOS was _always_ 16 bit and will be 32 bit (on 32 bit machines) with 7.0. It makes little sense to me that Apple would write an 8 bit OS for a 16 bit machine (the Mac 128). It does make sense to me that IBM would write an 8 bit OS for an 8 bit machine (the IBM XT). I just pulled out a tech note on 7.0 and it does say that 7.0 will be a 32 bit clean OS. I'm not claiming to be an OS gura, but it seems to me that Apple wouldn't lie to their developers. I could be wrong though...
peter@sugar.hackercorp.com (Peter da Silva) (04/22/91)
In article <10944@mentor.cc.purdue.edu> blissmer@expert.cc.purdue.edu (Corey) writes: > >MS-DOS is an 8-bit operating system. As is MacOS (a VW Beetle with a great > >sound system). > Hmm. Are you REAL sure about that. I thought the MacOS was _always_ 16 bit The 68000 is a 32-bit processor, but the Mac O/S was designed with the same sort of address space limitations as CP/M. It's even more primitive a design than the rather nice ProDOS that the Apple-/// used. It's got a glorious graphics library, but the basic underlying operating system is basically CP/M. > and will be 32 bit (on 32 bit machines) with 7.0. It makes little sense to me > that Apple would write an 8 bit OS for a 16 bit machine (the Mac 128). It > does make sense to me that IBM would write an 8 bit OS for an 8 bit machine > (the IBM XT). Programming-model-wise, the 80x86 (x<3) is 16-bit, the 680x0 (any x) is 32-bit. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
torrie@cs.stanford.edu (Evan Torrie) (04/22/91)
peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <10944@mentor.cc.purdue.edu> blissmer@expert.cc.purdue.edu (Corey) writes: >> >MS-DOS is an 8-bit operating system. As is MacOS (a VW Beetle with a great >> >sound system). >> Hmm. Are you REAL sure about that. I thought the MacOS was _always_ 16 bit >The 68000 is a 32-bit processor, but the Mac O/S was designed with the same >sort of address space limitations as CP/M. The only address space limitation in the original Mac OS was a 24-bit limit on pointers (and hence program addresses), since the upper 8 bits of a pointer address were used for memory management. [This is now fixed in System 7.0, following on from A/UX which fixed it 2-3 years ago]. There was at one point a 32K limit on resources in the Resource Manager, which meant segments of code could only be 32K. But this was fixed, I believe in the Mac Plus ROM of '86. -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu Today's maxim: All socialists are failed capitalists
peterk@cbmger.UUCP (Peter Kittel GERMANY) (04/22/91)
In article <e1Gj02be06fI01@JUTS.ccc.amdahl.com> kls30@DUTS.ccc.amdahl.com (Kent L. Shephard) writes: > >MS-DOS IS a 16 bit OS not eight bit. THe 8088 IS a 16 bit cpu with an >8 bit data bus. The 386sx is to the 386dx as a 8088 is to an 8086. >That is 16 bits vs 32 bits and 8 bits vs 16 bits. Now tell me that >a 386sx is a 16 bit cpu. But if you stress this argument, then the Amiga (also the A500) is even a 32-bit system! The 68000 processor does most of its internal computation in 32 bits, only has a 16-bit bus the outer world. (Ok, address space is only 24 bits, but don't be too picky :-) -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
peter@sugar.hackercorp.com (Peter da Silva) (04/22/91)
In article <1991Apr22.021234.23673@neon.Stanford.EDU> torrie@cs.stanford.edu (Evan Torrie) writes: > The only address space limitation in the original Mac OS was a 24-bit limit > on pointers (and hence program addresses), since the upper 8 bits of a pointer > address were used for memory management. [This is now fixed in System 7.0, > following on from A/UX which fixed it 2-3 years ago]. Well, there was also the 128K available memory limit, which made the 32K code size limit (due to 68000 addressing modes) reasonable. Plus, didn't a whole bunch of stuff stop working when you went over 1M... and that's only 20 bits. Anyway, the amount of memory available for the O/S in the original Mac was pretty much the same as it was for 8-bit "operating systems" like CP/M. Thus you had a single-tasking, flat file system (when PRO Dos, on the Apple ///, already had directories), and so on. If they'd waited 1 year, they could have released it with 512K and gone to multitasking, but Jobs just had to get it out for 1984 for political reasons. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
torrie@cs.stanford.edu (Evan Torrie) (04/23/91)
peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <1991Apr22.021234.23673@neon.Stanford.EDU> torrie@cs.stanford.edu (Evan Torrie) writes: >> The only address space limitation in the original Mac OS was a 24-bit limit >> on pointers (and hence program addresses), since the upper 8 bits of a pointer >> address were used for memory management. [This is now fixed in System 7.0, >> following on from A/UX which fixed it 2-3 years ago]. >Well, there was also the 128K available memory limit, Yes, but this was a hardware limit, not an OS limit. There were no changes necessary to the OS when the memory went to 512K and then 4MB. >Plus, didn't a whole >bunch of stuff stop working when you went over 1M... and that's only 20 bits. As far as I know, Microsoft Excel 1.0 was the only program which exhibited this behaviour (if you put it above the first 1MB of memory). This was somehow related to Microsoft's peculiar, non-standard PCODE system at the time. Other vendors programs weren't so affected (admittedly, Microsoft had some reason to do this - it allowed them to run Excel in 512K of memory while similar spreadsheets required 1MB). >Anyway, the amount of memory available for the O/S in the original Mac was >pretty much the same as it was for 8-bit "operating systems" like >CP/M. Yes, but the OS was not an 8-bit OS - only the particular implementation of the hardware at that time. >Thus >you had a single-tasking, flat file system (when PRO Dos, on the Apple ///, >already had directories), and so on. Yes, both of these were bad decisions, given that they'd already had experience with both of these in the Lisa. The flat file system was particularly poor. Luckily, they managed to graft HFS on top reasonably successfully (and HFS continues to be one of the better file systems around). They weren't so lucky with multitasking. -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu "Dear Fascist Bully Boy, Give me some money, or else. Neil. P.S. May the seed of your loins be fruitful in the womb of your woman..."
kls30@duts.ccc.amdahl.com (Kent L Shephard) (04/23/91)
In article <1991Apr21.152513.23054@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <e1Gj02be06fI01@JUTS.ccc.amdahl.com> kls30@DUTS.ccc.amdahl.com (Kent L. Shephard) writes: >> That is 16 bits vs 32 bits and 8 bits vs 16 bits. Now tell me that >> a 386sx is a 16 bit cpu. > >It's not the CPU, it's the software. Anything you run MS-DOS on is basically >a CP/M box. A VW Beetle with a V-8. > >MS-DOS is an 8-bit operating system. As is MacOS (a VW Beetle with a great ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ WRONG. If MS-DOS was an 8-bit OS you would not have 16-bit anything built in. In fact you do. CPM was 8-bit MS-DOS is 16-bits. The compilers for the OS are 16-bit. The initial cpu that MS-DOS ran on was 16-bit. >sound system). > >Xenix-286 and other swapping UNIX variants are 16-bit operating systems. As >is AmigaOS. Just because MS-DOS doesn't allow swapping and virtual memory directly does not mean it is not 16-bit. What is your definition of a 16-bit OS? Mine is one that directly supports 16-bit integers, data formats, if it is segmented - allows at least 16-bit segments for memory addressing. The same goes for a 32-bit OS. > >VMUNIX is a 32-bit operating system. So is NeXT Os 2.0 which, BTW is what my other machine runs. >-- >Peter da Silva. `-_-' ><peter@sugar.hackercorp.com>. -- /* -The opinions expressed are my own, not my employers. */ /* For I can only express my own opinions. */ /* */ /* Kent L. Shephard : email - kls30@DUTS.ccc.amdahl.com */
daveh@cbmvax.commodore.com (Dave Haynie) (04/23/91)
In article <e1Gj02be06fI01@JUTS.ccc.amdahl.com> kls30@DUTS.ccc.amdahl.com (Kent L. Shephard) writes: >In article <16928@chopin.udel.edu> don@chopin.udel.edu (Donald R Lloyd) writes: >MS-DOS IS a 16 bit OS not eight bit. THe 8088 IS a 16 bit cpu with an >8 bit data bus. The 386sx is to the 386dx as a 8088 is to an 8086. >That is 16 bits vs 32 bits and 8 bits vs 16 bits. Now tell me that >a 386sx is a 16 bit cpu. That all depends on whether you're a hardware, software, or CPU architect type. From the software viewpoint, the '386SX is a 32 bit CPU with some hard modes restricted to 16 bit only operations (8086 and 80286 compatibility modes, for instance). The '486, and 68000->68040 all appear to be 32 bit systems from the software view. From the hardware view, the '386sx and 68000 are 16 bit CPUs, the '386DX, '486, and 68020->68040 are 32 bits CPUs, and the 8088 and 68008 are 8 bit CPUs. From the CPU architecture view, the 68000 is a 16 bit CPU with 32 bit registers. What difference does it all make? Depends on what you're doing. Since all 680x0s run 32 bit instructions, all 680x0 code can take advantage of a 32 bit bus, and therefore a 32 bit [hardware] CPU will go close to twice as fast as as a 16 bit [hardware] CPU, all else being equal. You get "close to", because some operations are only byte or word wide even on a 32 bit system. The same would apply to a '386sx versus '386dx, under UNIX or any other 32 bit OS. Thing is, who's running their PC in a '386 native mode? Not the vast majority of people out there, most things are 8088 emulation mode. So the '386sx was a clever idea on Intel's part -- it could run nearly as fast on most things as the '386 or AMD's speedy '286s, but for real '386 stuff, although it would be much slower, it would still work. > Kent -- 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.
jbickers@templar.actrix.gen.nz (John Bickers) (04/24/91)
Quoted from <02J7020m07rC01@JUTS.ccc.amdahl.com> by kls30@duts.ccc.amdahl.com (Kent L Shephard): > >MS-DOS is an 8-bit operating system. As is MacOS (a VW Beetle with a great > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > WRONG. If MS-DOS was an 8-bit OS you would not have 16-bit anything > built in. In fact you do. CPM was 8-bit MS-DOS is 16-bits. The I suspect the original poster was refering to MS-DOS being embarassingly small and puny. The idea is probably that if the thing is barely a step above the C= 64's disk drive wedge thing, then it deserves to be labelled accordingly. I'm sure there must be real microcomputer 16-bit OSs that so far outpower MS-DOS that it would be an insult to them to be considered in the same general class just because of the bit-width they happen to care most about. > /* Kent L. Shephard : email - kls30@DUTS.ccc.amdahl.com */ Hoping I've got the right newsgroup... -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Patterns multiplying, re-direct our view" - Devo. ***
kent@vf.jsc.nasa.gov (04/26/91)
In article <2584.tnews@templar.actrix.gen.nz>, jbickers@templar.actrix.gen.nz (John Bickers) writes: > Quoted from <02J7020m07rC01@JUTS.ccc.amdahl.com> by kls30@duts.ccc.amdahl.com (Kent L Shephard): >> >MS-DOS is an 8-bit operating system. As is MacOS (a VW Beetle with a great >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> WRONG. If MS-DOS was an 8-bit OS you would not have 16-bit anything >> built in. In fact you do. CPM was 8-bit MS-DOS is 16-bits. The > > I suspect the original poster was refering to MS-DOS being > embarassingly small and puny. Actually, MS-DOS started out as a 8 bit operating system since the orignal PC as 8 bit based. Just because you have a 16 bit ore 32 bit 286 or 386 that does not mean the OS or the application programs are executing 32 wide instructions. A lot of programs are faster only because the clock speed of the 286 and 386 machines are faster.... the programs still execute 8 bit instructions..... #define TRUE 1 #define FLAME_SUPPRESSION_SYSTEM TRUE I'm ready for your responses..... -- Mike Kent - Lockheed Engineering and Sciences Company at NASA JSC 2400 NASA Rd One, Houston, TX 77058 (713) 483-3791 KENT@vf.jsc.nasa.gov
peter@sugar.hackercorp.com (Peter da Silva) (04/27/91)
In article <1991Apr22.175525.2785@neon.Stanford.EDU> torrie@cs.stanford.edu (Evan Torrie) writes: > >Well, there was also the 128K available memory limit, > Yes, but this was a hardware limit, not an OS limit. Yeh, but that hardware limit hurt the OS (32K segments? on a 68000?) > >Plus, didn't a whole > >bunch of stuff stop working when you went over 1M... and that's only 20 bits. > > As far as I know, Microsoft Excel 1.0 was the only program which > exhibited this behaviour (if you put it above the first 1MB of > memory). I don't think so. They had a number of titles that had problems when memory went over 1M. I can't list them, but I was quite interested in the Mac at the time (I still think it's the best machine for computerphobes) and I was dismayed at the lists that showed up in magazines. > Yes, but the OS was not an 8-bit OS - only the particular > implementation of the hardware at that time. Well, it was written to fit into the same constraints. It looked a lot like CP/M to me. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (04/27/91)
In article <02J7020m07rC01@JUTS.ccc.amdahl.com> kls30@DUTS.ccc.amdahl.com (Kent L. Shephard) writes: > Just because MS-DOS doesn't allow swapping and virtual memory directly > does not mean it is not 16-bit. What is your definition of a 16-bit > OS? Mine is one that directly supports 16-bit integers, data formats, if > it is segmented - allows at least 16-bit segments for memory addressing. CP/M allows all those things. My definitions: "8-bit O/S" written for memory on the order of 64K, single user, single tasking. "16-bit O/S" written for memory > 64K, multitasking. "32-bit O/S" written for memory >> 64K, sophissticated VM. > So is NeXT Os 2.0 which, BTW is what my other machine runs. Wish I had that sort of disposable income. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (04/27/91)
In article <2584.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: > I'm sure there must be real microcomputer 16-bit OSs that > so far outpower MS-DOS that it would be an insult to them to be > considered in the same general class just because of the bit-width > they happen to care most about. There are 8-bit micro OSes that do that: MP/M, OS/9, ... Just because it's an 8-bit micro doesn't mean you have to put up with an 8-bit O/S. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
cpmwc@marlin.jcu.edu.au (Matthew W Crowd) (04/27/91)
In article <1991Apr26.085327.1@vf.jsc.nasa.gov> kent@vf.jsc.nasa.gov writes: >In article <2584.tnews@templar.actrix.gen.nz>, jbickers@templar.actrix.gen.nz (John Bickers) writes: >> Quoted from <02J7020m07rC01@JUTS.ccc.amdahl.com> by kls30@duts.ccc.amdahl.com (Kent L Shephard): >>> >MS-DOS is an 8-bit operating system. As is MacOS (a VW Beetle with a great >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> WRONG. If MS-DOS was an 8-bit OS you would not have 16-bit anything >>> built in. In fact you do. CPM was 8-bit MS-DOS is 16-bits. The >> >> I suspect the original poster was refering to MS-DOS being >> embarassingly small and puny. > >Actually, MS-DOS started out as a 8 bit operating system since the >orignal PC as 8 bit based. Just because you have a 16 bit ore 32 bit 286 or >386 that does not mean the OS or the application programs are executing 32 wide >instructions. A lot of programs are faster only because the clock speed of the >286 and 386 machines are faster.... the programs still execute 8 bit >instructions..... > >#define TRUE 1 >#define FLAME_SUPPRESSION_SYSTEM TRUE > > I'm ready for your responses..... > >-- >Mike Kent - Lockheed Engineering and Sciences Company at NASA JSC > 2400 NASA Rd One, Houston, TX 77058 (713) 483-3791 > KENT@vf.jsc.nasa.gov This is wrong, MS-DOS is a 16bit operating system, 386's are the ones who don't benefit while running MS-DOS. matt.
peter@sugar.hackercorp.com (Peter da Silva) (04/28/91)
In article <1991Apr27.155155.12730@marlin.jcu.edu.au> cpmwc@marlin.jcu.edu.au (Matthew W Crowd) writes: > This is wrong, MS-DOS is a 16bit operating system, 386's are the ones > who don't benefit while running MS-DOS. Nope, MS-DOS is a straight copy of CP/M-80. Originally named QDOS (Quick and Dirty Operating System) by its author's at Seattle Computer (they were well aware that it was a kludge, only useful until they could afford to do it over from scratch), it was just plain adopted by Microsoft after IBM asked them to do an O/S for the IBM-PC. You see, IBM bought the PC from Seattle. Microsoft was purely a language house at the time, with absolutely no experience in operating systems. They really had no alternative. What I never could understand was why IBM went to Microsoft at all, when there were other, better, companies out there. DRI blew them off, we know that, but DRI wasn't the only fish in the sea. In any case, MS-DOS is a bug for bug copy of CP/M. If that doesn't make it an 8-bit operating system for you, you're listening to too much propoganda. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
dinda@cat55.cs.wisc.edu (Peter Dinda) (04/28/91)
In article <1991Apr28.122439.13393@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >Nope, MS-DOS is a straight copy of CP/M-80. Originally named QDOS (Quick and >Dirty Operating System) by its author's at Seattle Computer (they were well >aware that it was a kludge, only useful until they could afford to do it over >from scratch), it was just plain adopted by Microsoft after IBM asked them to >do an O/S for the IBM-PC. You see, IBM bought the PC from Seattle. > >Microsoft was purely a language house at the time, with absolutely no >experience in operating systems. They really had no alternative. > >What I never could understand was why IBM went to Microsoft at all, when there >were other, better, companies out there. DRI blew them off, we know that, but >DRI wasn't the only fish in the sea. > >In any case, MS-DOS is a bug for bug copy of CP/M. If that doesn't make it an >8-bit operating system for you, you're listening to too much propoganda. >-- WRONG. MS DOS is a 16 bit REAL MODE operating system. You may be getting confused since something like OS/2 1.x is a 16 bit PROTECTED MODE OS, while OS/2 2.x is a 32 bit PROTECTED MODE OS. The simplest processor that can run MS DOS (the Intel 8088) is a 16 bit processor with an 8 bit data bus. MS DOS, or for that matter, QDOS, is not a direct copy of CP/M - even the command interpreters accept different commands. Finally, MS DOS has now been rewritten 4 times - pretty much elliminating any resemblence to CP/M, even in the file system, etc. Take this from someone who has programmed for MS DOS and used CP/M. Peter A. Dinda #include <stddisclaimer.h>
david@kessner.denver.co.us (David Kessner) (04/29/91)
In article <1991Apr28.122439.13393@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <1991Apr27.155155.12730@marlin.jcu.edu.au> cpmwc@marlin.jcu.edu.au (Matthew W Crowd) writes: >> This is wrong, MS-DOS is a 16bit operating system, 386's are the ones >> who don't benefit while running MS-DOS. > >Nope, MS-DOS is a straight copy of CP/M-80. Originally named QDOS (Quick and >Dirty Operating System) by its author's at Seattle Computer (they were well >aware that it was a kludge, only useful until they could afford to do it over >from scratch), it was just plain adopted by Microsoft after IBM asked them to >do an O/S for the IBM-PC. You see, IBM bought the PC from Seattle. > >In any case, MS-DOS is a bug for bug copy of CP/M. If that doesn't make it an >8-bit operating system for you, you're listening to too much propoganda. Now, I will be the _LAST_ person to extole the virtues of MS-DOS, but lets get our facts straight, will we? MS-DOS is a _16_ bit operating system. While it may be similar to CPM I doubt that it is a "staight copy" since CPM was strictly a 8 bit OS, and MS-DOS clearly has support for the _16_BIT_REGISTERS_ that the CPU has. Any BIOS/DOS reference book will provide you with enough _facts_ to show you that it does indeed use 16 bit numbers in the 16 bit CPU registers. That is _my_ definition of a 16 bit operating system-- the number of bits in the registers that it actually _uses_. Notice how this definition totally ignores any reference to the amount of RAM useable, disk space, multi-tasking, etc-- as it should do. The original PC used the 8088 CPU. This CPU is the same as the 8086-- both have 16 bit registers, but the 8088 has a 8 bit data bus where the 8086 has a 16 bit data bus. The software is the same for both. It's like the relationship between the 68000 and the 68008-- same CPU, different data bus size. Now, while MS-DOS is a 16 bit OS, it is _not_ a 32 bit OS. When running on a 386/486 MS-DOS does not utilize some of the features of the CPU-- like the MMU, 32 bit registers, or 'protected mode' (the full-blown mode that you would expect from a modern CPU). The long and short of it is, MS-DOS is _not_ an 8 bit OS running on a 16 bit CPU. It may _resemble_ an 8 bit OS, but it is not. It is 16 bits. Now, even though it is a 16 bit OS, it does not mean that Bill Gates didn't give it the "Look and Feel like CP/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);
kls30@duts.ccc.amdahl.com (Kent L Shephard) (04/29/91)
In article <1991Apr26.221002.24745@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <02J7020m07rC01@JUTS.ccc.amdahl.com> kls30@DUTS.ccc.amdahl.com (Kent L. Shephard) writes: >> Just because MS-DOS doesn't allow swapping and virtual memory directly >> does not mean it is not 16-bit. What is your definition of a 16-bit >> OS? Mine is one that directly supports 16-bit integers, data formats, if >> it is segmented - allows at least 16-bit segments for memory addressing. > >CP/M allows all those things. > >My definitions: "8-bit O/S" written for memory on the order of 64K, single >user, single tasking. "16-bit O/S" written for memory > 64K, multitasking. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ As long as it is written for 64K or greater it is a 16bit OS. Multitasking has nothing to do with whether an OS is 8,16, or 32bits. If you exclude the multitasking constraint MS-DOS is a 16 bit OS. As long as an OS uses all the features of a CPU, that is 16 bit uses 16 bit data and 32 bit uses 32 bit data etc. that determines the size of the OS. You are confusing features of an OS with what it takes for one to be functional. >"32-bit O/S" written for memory >> 64K, sophissticated VM. Actually 32 bits would require you to address 4 gigabytes of memory. Sophisticated VM is not a requirement. Like I said you confuse req. with features. > >> So is NeXT Os 2.0 which, BTW is what my other machine runs. > >Wish I had that sort of disposable income. >-- >Peter da Silva. `-_-' ><peter@sugar.hackercorp.com>. -- /* -The opinions expressed are my own, not my employers. */ /* For I can only express my own opinions. */ /* */ /* Kent L. Shephard : email - kls30@DUTS.ccc.amdahl.com */
jburnes@swbatl.sbc.com (Jim Burnes - 235-0709) (04/30/91)
Ok guys! Let me be the first to propose that MSDOS is not an operating system at all. It is a very much souped up basic i/o system with a unix-like file system kludged onto it. (ohh....wait ...its not really a unix file system...they went and changed the path delimiter to a backslash.. how clever! ..big 8-) ) Seriously. Lets get our semantics in order here. Operating systems are more based on resource allocation for their classifications. CPUs are more based upon both their internal logic width and their addressable memory size. Let me also say that the 8086 is not properly a full 16bit CPU. Its more like a hopped up 8085 with wider arithmetic instructions. See any 16bitx16bit multiplies in there? I don't think so. (i might be wrong here) Worst of all is its unbelievably brain damaged addressing scheme. OK! I know you're out there...somebody who want to explain why INTEL did it that way. Well...stop right there....its fucked up! OK? 8-) Phew...(as he wipes the spittle from his mouth)...ahem...anyway back to MSDOS. I've programmed UNIX, AmigaDOS and MSDOS and (drum roll please) CP/M right to the metal. I can tell you even MDSOS 3.3 has the same damn internal data structures as CP/M. The ones that are new to the later versions of MSDOS are different of course. I've programmed low level BIOS functions/DOS functions/dissasembled and single-stepped through AMIBIOS so I can tell you how thoroughly screwed up MSDOS is. (used SOFTICE for single stepping ....get it!) PS: For fun sometime, try writing any type of real-time control system that runs under MessyDos. Try writing an interrupt driven device driver sometime. Go ahead I dare you. OK..nuf hubris here. I say MSDOS is a 8/16bit segmented architecture OS with extensions that let it run in 386 virtual machine environment. Eeewwww! (Now to return all you hackers to your Zen-Meditative-Harmonic- Balance-with-the-machine lets mention some nice OS's) AmigaDos (except for some slow file system access and lack of protected memory) PLAN-9 Amoeba QNX (even 4.3 Reno BSD) MINIX386/68k Sprite (There...now don't you feel better) MSDOS...just say No! (thankyou Mrs. Bush) J. Burnes -- ------------------------------------------+----------------------------- Jim Burnes - System Engineer ! When the world is SouthWestern Bell Advanced Technology Labs! running down... Internet: jburnes@swbatl.swbell.com ! Make the best of what's
peter@sugar.hackercorp.com (Peter da Silva) (04/30/91)
In article <1991Apr28.162045.15585@daffy.cs.wisc.edu> dinda@cat55.cs.wisc.edu (Peter Dinda) writes: > WRONG. I love it how these college freshmen are so bloody sure of themselves. Especially when they haven't been paying attention. > MS DOS is a 16 bit REAL MODE operating system. You may be getting > confused since something like OS/2 1.x is a 16 bit PROTECTED MODE OS, while > OS/2 2.x is a 32 bit PROTECTED MODE OS. I'm not confused, bucko. You are. Look at what you wrote: full of intel marketing terms for privileged mode, user mode, and so on. > The simplest processor that > can run MS DOS (the Intel 8088) is a 16 bit processor with an 8 bit data > bus. As far as the programming model (the only one that counts) is concerned, the 8088 is an 8-bit processor with 4 bank-select registers built in. There were companies doing operating systems for bank-selected 8-bit micros that would have blown your socks of: Cromix from Cromemco, a UNIX-like O/S on multiple bank-switched Z80s. OS/9 from Microware, still available for the Radio Shack color computer, and still a 16-bit O/S for all it's running on a 6809. > MS DOS, or for that matter, QDOS, is not a direct copy of CP/M - even > the command interpreters accept different commands. Oh, the shell defines the O/S? Look at the system calls in MS-DOS 1.x some time. Bug-for-bug compatible with CP/M. > Finally, MS DOS has now > been rewritten 4 times - pretty much elliminating any resemblence to CP/M, > even in the file system, etc. Oh? It's not an extent-based file system, with 8+3 filenames, CR/LF as the line terminator, and so on? It's not still purely single-tasking? They now provide real interrupt-driven device drivers? From where I sit, the 2.0 system calls are nothing more than a frill. No. Actually, MS-DOS is worse than CP/M. CP/M never got caught into the trap of becoming specific to one piece of hardware. > Take this from someone who has programmed for MS DOS and used CP/M. Take this from someone who has programmed both MS-DOS and CP/M, who did a Forth-based multitasker that ran fine under CP/M in 1983, and who has used and programmed under more different operating systems than you can spell. Sheesh. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (04/30/91)
In article <1991Apr28.203012.2793@kessner.denver.co.us> david@kessner.denver.co.us (David Kessner) writes: > Now, I will be the _LAST_ person to extole the virtues of MS-DOS, but lets > get our facts straight, will we? OK, you go read the message I just wrote to Peter Dinda. You been eating up the propoganda just fine too... > MS-DOS is a _16_ bit operating system. While it may be similar to CPM I > doubt that it is a "staight copy" since CPM was strictly a 8 bit OS, and > MS-DOS clearly has support for the _16_BIT_REGISTERS_ that the CPU has. Oh right! The 16-bit registers! I'd suggest you look at the 1802, a 4/8 bit microprocessor that comes with 16 16-bit registers. For that matter, what do you think HL is? As for being a copy of CP/M... that was not only intentional it was stated as a virtue of the machine by IBM back in 1981. All us CP/M hackers were puking, but the business community ate it up by god. > That is _my_ definition of a 16 bit operating system-- the number of bits > in the registers that it actually _uses_. Fine. Then I've *written* a 16-bit operating system. So I'm qualified to speak on such issues, and MS-DOS isn't one. > Now, even though it is a 16 bit OS, it does not mean that Bill Gates didn't > give it the "Look and Feel like CP/M". :) Bill Gates didn't give it anything. He didn't write line 1 of the code in QDOS. He just took an existing program (written at Seattle Computer) and filed off the serial numbers. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (04/30/91)
In article <2brN02no07bc01@JUTS.ccc.amdahl.com> kls30@DUTS.ccc.amdahl.com (PUT YOUR NAME HERE) writes: > As long as it is written for 64K or greater it is a 16bit OS. As another poster has noted, MS-DOS really isn't an O/S at all. But if you include "64K or greater" that makes TRS-DOS, Apple-DOS, CP/M, and so on 16-bitters. (hell, the Apple ROMS did include a 16-bit p-machine) > Multitasking has nothing to do with whether an OS is 8,16, or 32bits. If > you exclude the multitasking constraint MS-DOS is a 16 bit OS. If you exclude the passenger seats a motorcycle is a car, right? > You are confusing features of an OS with what it takes for one to be > functional. No, I'm not confusing anything at all. > >"32-bit O/S" written for memory >> 64K, sophissticated VM. > Actually 32 bits would require you to address 4 gigabytes of memory. ">>" means "much greater than". By your logic, an 8-bit O/S could only address 256 bytes, right? -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
david@kessner.denver.co.us (David Kessner) (05/01/91)
In article <1991Apr30.112820.2451@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <1991Apr28.162045.15585@daffy.cs.wisc.edu> dinda@cat55.cs.wisc.edu (Peter Dinda) writes: >> WRONG. >I love it how these college freshmen are so bloody sure of themselves. What makes _YOU_ so sure? >> MS DOS is a 16 bit REAL MODE operating system. You may be getting >> confused since something like OS/2 1.x is a 16 bit PROTECTED MODE OS, while >> OS/2 2.x is a 32 bit PROTECTED MODE OS. > >I'm not confused, bucko. You are. Look at what you wrote: full of intel >marketing terms for privileged mode, user mode, and so on. I would not call it marketing hype. More like a difference in religion and it's terms. In the Motorola processors, privileged/user modes are used to allow the OS to execute several instructions that normal programs should not be allowed to use-- because they can effect the integrity of the computer. The 286/386/486's have a similar mechanism for this-- that is _loosely_ tied to 'protected mode'. What protected mode _really_ means is that the MMU is turned on fully-- and that _MEMORY_PROTECTION_ is turned on, hence the name "Protected mode". Since the 8088/8086 did not contain anything even closely resembling an MMU, it does not have a protected mode. (While I imply that the 286 _does_ have an MMU, I will agree that it only resembles an MMU in the most broad sence of the word.) It's not a marketing term-- mearly another name for what is taken for granted on most 32 bit CPU's. Intel users could not take it for granted since they never had it before (and judging by all the MS-DOS software out there, they still dont have it :). >As far as the programming model (the only one that counts) is concerned, >the 8088 is an 8-bit processor with 4 bank-select registers built in. There >were companies doing operating systems for bank-selected 8-bit micros that >would have blown your socks of: Cromix from Cromemco, a UNIX-like O/S on >multiple bank-switched Z80s. OS/9 from Microware, still available for the >Radio Shack color computer, and still a 16-bit O/S for all it's running >on a 6809. In _every_ respect, the 8088/8086 is a _16_ bit CPU. Eveything from the instruction set to it's registers indicate this. MS-DOS fully utilizes all of the 8088 features, so I will classify it as a 16 bit OS. What the 8088 is not is a 24 or 32 bit CPU. It is strictly a 16 bit device, even down to the address calculation section of the chip. In this section, all addresses are calulated to 16 bits, then at the last moment it is added to the segment prefix, yeilding a 20 bit result (ok, there is one >16 bit thing in it). Anyway, Intel choose to use segments to give it a 1 meg address range rather than increase the registers and what-not to 24 or 32 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. And as we all know, this has been proved by most to be _stupid_. I really must say, however, that the addressing of the CPU has no effect on the number of bits that the OS "is". Weither the OS is multi-tasking, multi-user, how much memory it supports, if it has virtual memory, or even if it supports hard drives has _NOTHING_ to do with how many bits the OS is... >Oh? It's not an extent-based file system, with 8+3 filenames, CR/LF as the >line terminator, and so on? It's not still purely single-tasking? They now >provide real interrupt-driven device drivers? Hmmm... Yes, MS-DOS has been re-written several times-- but no-one is saying that it is a _good_ rewrite. 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. They are fully 'hard' vectored, etc, etc... The 'device' drivers are intterupt driven-- and all third-party drivers that I know of are intterupt driven. The only driver that is not is the DOS/BIOS serial drivers-- but _NO_ONE_ uses that driver, choosing to use their own custom drivers (this has been common practice since about 1983). >No. Actually, MS-DOS is worse than CP/M. CP/M never got caught into the trap >of becoming specific to one piece of hardware. Wasn't CP/M specific to Z80 (and the like) CPU's? I don't know which is worse, Z80 or MS-DOS... No-one ever said that MS-DOS is anything close to GOOD... In fact, it is common knoledge that MS-DOS isn't worth the rust it is stored on, but... The original dis-agreement was if MS-DOS is 8 or 16 bits-- and you know my opinions on that! >> Take this from someone who has programmed for MS DOS and used CP/M. > >Take this from someone who has programmed both MS-DOS and CP/M, who did >a Forth-based multitasker that ran fine under CP/M in 1983, and who has >used and programmed under more different operating systems than you can >spell. Then you ought know better! Both you and I know that the 8088 CPU's have 16 bit registers, and in the case of the 8086/80186/80286 they have 16 bit data paths. MS-DOS utilizes those registers (all 16 bits) to do it's calulations and what-not. It doesn't matter if it emulates CP/M's bugs. The fact that it uses 16 bit registers and numbers is well known/documented, and should be proof enough to it's "Number of bits". C'mon Peter, I've heard more intelligent things come from you before! >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);
david@kessner.denver.co.us (David Kessner) (05/01/91)
Sorry, Peter, for posting twice... I replied to a previous post of yours before this one (intended for me) came through... In article <1991Apr30.113402.2522@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >> Now, I will be the _LAST_ person to extole the virtues of MS-DOS, but lets >> get our facts straight, will we? > >OK, you go read the message I just wrote to Peter Dinda. You been eating up >the propoganda just fine too... I did. Wasn't impressed. >> MS-DOS is a _16_ bit operating system. While it may be similar to CPM I >> doubt that it is a "staight copy" since CPM was strictly a 8 bit OS, and >> MS-DOS clearly has support for the _16_BIT_REGISTERS_ that the CPU has. > >Oh right! The 16-bit registers! I'd suggest you look at the 1802, a 4/8 bit >microprocessor that comes with 16 16-bit registers. Then _YOU_ define your view of a 16 bit OS. (I missed the first few messages in this thread, so I probably didn't read it if you posted it.) >For that matter, what do you think HL is? I guess I do better on ink-blots... Considering I have no idea what you are talking about here, I havn't the foggiest idea what HL is. >As for being a copy of CP/M... that was not only intentional it was stated >as a virtue of the machine by IBM back in 1981. All us CP/M hackers were >puking, but the business community ate it up by god. I know that it was initally based on CP/M... But it is not CP/M. It's easy to prove. Look at the calls to DOS/BIOS-- they are specific to the 80x86's registers/segments. There is an obvious difference that would make MS-DOS and CP/M in the same family-- but not twins. There is enough differnce to not equate the two (like how you don't equate Ultrix with UNIX). >> That is _my_ definition of a 16 bit operating system-- the number of bits >> in the registers that it actually _uses_. > >Fine. Then I've *written* a 16-bit operating system. So I'm qualified to >speak on such issues, and MS-DOS isn't one. Facts, man-- just the facts. _WHY_ isnt it a 16 bit OS? You know what I think it is 16 bits... You agree with the facts I provide (ie, 16 bit registers)... But you don't come to the same conclusion. Why? >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);
peter@sugar.hackercorp.com (Peter da Silva) (05/01/91)
In article <1991May1.064455.3058@kessner.denver.co.us> david@kessner.denver.co.us (David Kessner) writes: > In article <1991Apr30.112820.2451@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > >In article <1991Apr28.162045.15585@daffy.cs.wisc.edu> dinda@cat55.cs.wisc.edu (Peter Dinda) writes: > >> WRONG. > >I love it how these college freshmen are so bloody sure of themselves. > What makes _YOU_ so sure? Experience, kid. > >> MS DOS is a 16 bit REAL MODE operating system. You may be getting > >> confused since something like OS/2 1.x is a 16 bit PROTECTED MODE OS, while > >> OS/2 2.x is a 32 bit PROTECTED MODE OS. > >I'm not confused, bucko. You are. Look at what you wrote: full of intel > >marketing terms for privileged mode, user mode, and so on. > I would not call it marketing hype. More like a difference in religion and > it's terms. [stuff about motorola vs. intel] Motorola calls it Supervisor mode, mate. Which is closer to the normal terms for the thing. > In _every_ respect, the 8088/8086 is a _16_ bit CPU. It's a bag on the side of the 8080. Everything from the instruction set to its registers (and the direct mapping from its registers to the 8080's) indicates this. > In this section, > all addresses are calulated to 16 bits, then at the last moment it is added > to the segment prefix, yeilding a 20 bit result (ok, there is one >16 bit > thing in it). Just like an 8080 with external banking. > It is also a common mis-conception that the PC's intterupts are somewhat > lacking. There you go, quibbling about hardware again. I'm talking about MS-DOS. You know, the software? It doesn't take advantage of any of that stuff. It is STILL not possible to reliably use the serial port under DOS. You STILL have to write your own device drivers. Bleagh. > drivers are intterupt driven ... The only driver that is not is the DOS/BIOS > serial drivers-- -- and the keyboard and the parallel port and the screen (remember all the snow problems on the screen because the DOS drivers weren't synchronised with the vertical blank?) -- > but _NO_ONE_ uses that driver, choosing to use their own custom > drivers (this has been common practice since about 1983). That's the point. Thank you for making it for me. And people write their own custom handlers for the keyboard interrupt and so on as well. > >No. Actually, MS-DOS is worse than CP/M. CP/M never got caught into the trap > >of becoming specific to one piece of hardware. > Wasn't CP/M specific to Z80 (and the like) CPU's? I don't know which is > worse, Z80 or MS-DOS... CP/M ran on the Z80, the 8080, and the 8085. There were versions of CP/M for the 8086 and 68000 as well. It ran on machines from homebrew S100 bus boxes with TV-typewriters for terminals to 30-or-more user multi-CPU timeshared office systems. It was basically *the* business system for its day, which is why Seattle Computer and later IBM deliberately copied it for their box. > The original dis-agreement was if MS-DOS is 8 or 16 bits-- and you know my > opinions on that! 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. > Then you ought know better! Both you and I know that the 8088 CPU's have ... etc, etc, etc. The Cosmac 1802 has 16 16-bit registers, with a RISC-like addressing mode, hardware support for threads, and so on. But it's still a 4/8 bit CPU. For that matter the Z80 has 16-bit registers (HL, IX, IY). Look at the programming model. Not the manufacturers specs. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (05/01/91)
In article <1991May1.070516.3257@kessner.denver.co.us> david@kessner.denver.co.us (David Kessner) writes: > Then _YOU_ define your view of a 16 bit OS. (I missed the first few > messages in this thread, so I probably didn't read it if you posted it.) 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. 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. > I guess I do better on ink-blots... Considering I have no idea what you are > talking about here, I havn't the foggiest idea what HL is. It's the 16-bit memory access register in the 8080 family. > I know that it was initally based on CP/M... But it is not CP/M. It's > easy to prove. Look at the calls to DOS/BIOS-- they are specific to the > 80x86's registers/segments. There is an obvious difference that would make > MS-DOS and CP/M in the same family-- but not twins. There is enough differnce > to not equate the two (like how you don't equate Ultrix with UNIX). But I *do* equate Ultrix with UNIX. In fact, anything that provides the basic 35 system calls from V7 days is UNIX. > Facts, man-- just the facts. _WHY_ isnt it a 16 bit OS? See above. > You know what I think it is 16 bits... You agree with the facts I provide > (ie, 16 bit registers)... But you don't come to the same conclusion. Why? Because I don't agree with your definition. I look at the capabilities and programming model. Where the software was born, not where it lives now. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
daveh@cbmvax.commodore.com (Dave Haynie) (05/02/91)
In article <1991May1.064455.3058@kessner.denver.co.us> david@kessner.denver.co.us (David Kessner) writes: >In article <1991Apr30.112820.2451@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >>In article <1991Apr28.162045.15585@daffy.cs.wisc.edu> dinda@cat55.cs.wisc.edu (Peter Dinda) writes: >>I love it how these college freshmen are so bloody sure of themselves. >What makes _YOU_ so sure? Scars acquired over years of working "in the business" are a reasonable assurance. >>As far as the programming model (the only one that counts) is concerned, >>the 8088 is an 8-bit processor with 4 bank-select registers built in. >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). >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. >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. >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. >>No. Actually, MS-DOS is worse than CP/M. CP/M never got caught into the trap >>of becoming specific to one piece of hardware. >Wasn't CP/M specific to Z80 (and the like) CPU's? I don't know which is >worse, Z80 or MS-DOS... 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. >>Peter da Silva. `-_-' >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.
kls30@duts.ccc.amdahl.com (Kent L Shephard) (05/02/91)
In article <1991Apr30.113840.2593@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <2brN02no07bc01@JUTS.ccc.amdahl.com> kls30@DUTS.ccc.amdahl.com (PUT YOUR NAME HERE) writes: >> As long as it is written for 64K or greater it is a 16bit OS. > >As another poster has noted, MS-DOS really isn't an O/S at all. But if you >include "64K or greater" that makes TRS-DOS, Apple-DOS, CP/M, and so on >16-bitters. (hell, the Apple ROMS did include a 16-bit p-machine) > >> Multitasking has nothing to do with whether an OS is 8,16, or 32bits. If >> you exclude the multitasking constraint MS-DOS is a 16 bit OS. > >If you exclude the passenger seats a motorcycle is a car, right? > You confuse features and function. A 16bit OS DOES NOT have to have multitasking to be 16bit. >By your logic, an 8-bit O/S could only address 256 bytes, right? By my definition - not logic - an 8bit OS must address at LEAST 256 bytes, more is good but 256 bytes is minimum. For a 16 bit 64k is minimum. It must also support the relavent data type. MS-DOS does both, ie. 640k memory and 16bit data types. >-- >Peter da Silva. `-_-' ><peter@sugar.hackercorp.com>. -- /* -The opinions expressed are my own, not my employers. */ /* For I can only express my own opinions. */ /* */ /* Kent L. Shephard : email - kls30@DUTS.ccc.amdahl.com */
david@kessner.denver.co.us (David Kessner) (05/02/91)
In article <1991May1.115856.13525@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >It's a bag on the side of the 8080. Everything from the instruction set to >its registers (and the direct mapping from its registers to the 8080's) >indicates this. >Just like an 8080 with external banking. >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... 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! 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. >-- and the keyboard and the parallel port and the screen (remember all the >snow problems on the screen because the DOS drivers weren't synchronised with >the vertical blank?) -- So what? This has _NOTHING_ do do with the topic of "How many bits is MS-DOS?" (But it does show how bad MS-DOS is...) The keyboard is not intterupt driven? Then someone should tell the guys at Phenix Technologies! In their book on the BIOS, the keyboard ISR is located at INT 09h (the Keyboard Device service routine is at INT 16h). Tis true that the printer driver is not normally intterupt driven, but all print spoolers are-- including the 'print' command that comes standard with MS-DOS. The only reason there was snow on the early displays was because the card was not designed well-- they were mostly CGA displays and some 'almost compatables' made by AT&T. This is not a problem in current machines. The only time I have seen snow on a VGA screen was when I was doing color cycling on an 800x600x256 color screen without syncing it to the refreash-- but this mode is way beyond the drivers anyway, so custom drivers are required anyway. >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);
dinda@cat53.cs.wisc.edu (Peter Dinda) (05/02/91)
In article <1991Apr30.112820.2451@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <1991Apr28.162045.15585@daffy.cs.wisc.edu> dinda@cat55.cs.wisc.edu (Peter Dinda) writes: >> WRONG. > >I love it how these college freshmen are so bloody sure of themselves. > >Especially when they haven't been paying attention. As a young gentleman who is a hop, skip, and jump away from both a BSEE and BSCS, who has programmed privately for DOS and DOS/Windows and commercially (for IBM) for multithreaded OS/2, I take offense at your personal insult. Being a gentleman, I will not return it in kind. > >> MS DOS is a 16 bit REAL MODE operating system. You may be getting >> confused since something like OS/2 1.x is a 16 bit PROTECTED MODE OS, while >> OS/2 2.x is a 32 bit PROTECTED MODE OS. > >I'm not confused, bucko. You are. Look at what you wrote: full of intel >marketing terms for privileged mode, user mode, and so on. Umm, Intel, built the processors that OS/2 and DOS run on. I think they have the right to name what the modes are! Unlike something like a PDP-11 or VAX-11, 286 and 386 machines provide four levels of protection - not just a user and priveleged mode. > >> The simplest processor that >> can run MS DOS (the Intel 8088) is a 16 bit processor with an 8 bit data >> bus. > >As far as the programming model (the only one that counts) is concerned, >the 8088 is an 8-bit processor with 4 bank-select registers built in. There Sorry, the 8088 has a 16 bit ALU - most machines are characterized on the basis of two things - the ALU and the Data Bus Widths. The 8088 has an 8 bit Data Bus, but all internal processing is done 16 bits at a time. The register pairs can be used either as full 16 bit registers, or split in half to act as twice as many 8 bit registers. ES, DS, CS, and SS are used to point to current segments and a segment plus offset scheme is used - this is kind of like the Base plus offset addressing found in an IBM 370 - but I forget, that's also an 8 bit system in your POV. >were companies doing operating systems for bank-selected 8-bit micros that >would have blown your socks of: Cromix from Cromemco, a UNIX-like O/S on >multiple bank-switched Z80s. OS/9 from Microware, still available for the >Radio Shack color computer, and still a 16-bit O/S for all it's running >on a 6809. > >> MS DOS, or for that matter, QDOS, is not a direct copy of CP/M - even >> the command interpreters accept different commands. > >Oh, the shell defines the O/S? Look at the system calls in MS-DOS 1.x >some time. Bug-for-bug compatible with CP/M. Sorry, note by use of the word "even" - the system calls for CP/M were never implemented as software interupts, now were they? And CP/M didn't provide for Device Drivers did it? You didn't have to patch DOS 1.x to add new devices! > >> Finally, MS DOS has now >> been rewritten 4 times - pretty much elliminating any resemblence to CP/M, >> even in the file system, etc. > >Oh? It's not an extent-based file system, with 8+3 filenames, CR/LF as the >line terminator, and so on? It's not still purely single-tasking? They now >provide real interrupt-driven device drivers? > >From where I sit, the 2.0 system calls are nothing more than a frill. > >No. Actually, MS-DOS is worse than CP/M. CP/M never got caught into the trap >of becoming specific to one piece of hardware. Ah, yes. CP/M ran on something other than 8080 derivatives - good urban legend. DOS stays around because its what users demand and buy. If it were up to IBM and Microsoft, Intel based PCs would be using OS/2 right now. And with all your credentials you still have time to insult other readers of comp.sys.amiga.advocacy. My My, you must be good.
david@kessner.denver.co.us (David Kessner) (05/02/91)
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);
jbickers@templar.actrix.gen.nz (John Bickers) (05/02/91)
Quoted from <1991May1.064455.3058@kessner.denver.co.us> by david@kessner.denver.co.us (David Kessner): > the instruction set to it's registers indicate this. MS-DOS fully > utilizes all of the 8088 features, so I will classify it as a 16 bit OS. When one calls an MS-DOS "interrupt" (haw, reminds me of the C= 64), isn't the interrupt number a byte? That's a fundamental part of the OS that is only 8 bits. > David Kessner - david@kessner.denver.co.us | do { -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
peter@sugar.hackercorp.com (Peter da Silva) (05/02/91)
In article <1991May2.010922.6096@kessner.denver.co.us> david@kessner.denver.co.us (David Kessner) writes: > 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. 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. > The keyboard is not intterupt driven? Then someone should tell the guys > at Phenix Technologies! In their book on the BIOS, the keyboard ISR is > located at INT 09h (the Keyboard Device service routine is at INT 16h). 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? Why don't you include the hardware as well? Or the application? > Tis true that the printer driver is not normally intterupt driven, but all > print spoolers are-- including the 'print' command that comes standard with > MS-DOS. Right. The application has to take over because the O/S doesn't take advantage of it. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (05/02/91)
In article <1991May2.012127.28779@daffy.cs.wisc.edu> dinda@cat53.cs.wisc.edu (Peter Dinda) writes: > As a young gentleman who is a hop, skip, and jump away from both > a BSEE and BSCS, who has programmed privately for DOS and DOS/Windows and > commercially (for IBM) for multithreaded OS/2, I take offense at your > personal insult. Being a gentleman, I will not return it in kind. That's OK, I'll take it as read. I think you've proved my point. You've so little experience with operating systems other than UNIX or DOS and derivitives that you don't understand what I'm getting at. > Umm, Intel, built the processors that OS/2 and DOS run on. I think they > have the right to name what the modes are! Sure they do, and they have every right to call their bank-select registers "segment" registers, even though they're crippled by comparison with real segments. And I have every right to point out that using them that way indicates a lack of experience. > Unlike something like a > PDP-11 or VAX-11, 286 and 386 machines provide four levels of protection - > not just a user and priveleged mode. Yes, and the Honeywell/GE machines Multics ran on provided what... 6 levels? > Sorry, the 8088 has a 16 bit ALU - most machines are characterized on > the basis of two things - the ALU and the Data Bus Widths. The 8088 has > an 8 bit Data Bus, but all internal processing is done 16 bits at a time. > The register pairs can be used either as full 16 bit registers, or split > in half to act as twice as many 8 bit registers. Uh, huh. And the 6809 (clearly an 8-bit machine) has a 16-bit ALU and an 8-bit data bus, 16-bit registers and PC. That makes it every bit as 16-bit as the 80x86 (x<2). The 1802 has an 8-bit ALU, 8-bit data bus, and 16 16-bit registers. But all three of these chips have the same limitations in their programming model: you can't point to more than 16 bits of address at a time. > Sorry, note by use of the word "even" - the system calls for CP/M were never > implemented as software interupts, now were they? Hey, UNIX system calls have been implemented as everything from call-gates to interrupts and illegal iunstruction traps. That doesn't mean that System V on a 68000 and System V on an 80386 are different operating systems. > And CP/M didn't provide > for Device Drivers did it? You didn't have to patch DOS 1.x to add new > devices! You have to re-link the kernel to add new devices in UNIX. So I guess by your logic it's an 8-bit O/S. After all, it's just the same as relinking CP/M (not patching, unless your vendor ripped you off and didn't give you a copy of BIOS.ASM). > Ah, yes. CP/M ran on something other than 8080 derivatives - good > urban legend. You can buy a 68000-based CP/M box today: it's called the Atari ST. > DOS stays around because its what users demand and buy. If > it were up to IBM and Microsoft, Intel based PCs would be using OS/2 right > now. Microsoft has abandoned OS/2, didn't you notice? (OS/2: bigger than UNIX and does half as much. Would *you* buy half an O/S?) > And with all your credentials you still have time to insult other readers > of comp.sys.amiga.advocacy. My My, you must be good. There, I know you couldn't resist trading insults after all. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (05/02/91)
In article <1991May2.013735.6365@kessner.denver.co.us> david@kessner.denver.co.us (David Kessner) writes: > By your definition, I could write a 16 bit OS for the 6502. Yes, you could. In fact Apple was doing that very thing on the Apple ///, when they decided to dump it. Using banking a 6502 can address just as much memory as an 8088, in 16K (12K on the ][) chunks instead of 64K ones. > Nothing you mentioned is dependant on the magic 8 or 16 bit numbers. What's magic. I'm talking about memory limitations. The IBM-PC originally shipped with the same 64K CP/M ran under. > The things that you mention are more dependant on MMU's rather than anything > else-- like the 'number of bits'. It's, like all other distinctions, a tag. There are commonalities among 8-bit CPUs, 16-bit ones, and 32-bit ones. > >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. Ultrix ran on the VAX. Were you thinking of Version 7 UNIX? Swapping UNIX systems are indeed 16-bit. Not surprising... the PDP-11 is a 16-bit machine. But Ultrix is DEC's name for their VAX UNIX. They never shipped a UNIX for the PDP-11. Why don't you check your facts and try again? > 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. MUST be. I see. because some marketing bozo at AT&T had a bright idea one day earlier versions of the O/S, even from AT&T, are different. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
david@kessner.denver.co.us (David Kessner) (05/03/91)
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);
david@kessner.denver.co.us (David Kessner) (05/03/91)
In article <1991May2.105802.26053@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >> Nothing you mentioned is dependant on the magic 8 or 16 bit numbers. > >What's magic. I'm talking about memory limitations. The IBM-PC originally >shipped with the same 64K CP/M ran under. > >> The things that you mention are more dependant on MMU's rather than anything >> else-- like the 'number of bits'. > >It's, like all other distinctions, a tag. There are commonalities among 8-bit >CPUs, 16-bit ones, and 32-bit ones. So, using your definitions for 8, 16, and 32 bit OS's (not quoted here), why should we use 'bits' as the unit of measurement-- since it is more than a little misleading. Perhapse another term should be 'generation', 'level', etc. For instance, a Level 1 OS would be nothing more than a program loader where a level 42 would do everything UNIX does now, with support for multi-CPU's, 64-bit address space, etc... This would be _MUCH_ better since your definitions have absolutely nothing to do with the number of bits in anything. >>>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. > >Ultrix ran on the VAX. Were you thinking of Version 7 UNIX? Swapping UNIX >systems are indeed 16-bit. Not surprising... the PDP-11 is a 16-bit machine. > >But Ultrix is DEC's name for their VAX UNIX. They never shipped a UNIX for >the PDP-11. Why don't you check your facts and try again? Why don't _YOU_ check your facts. I have programmed a PDP-11/23 and a MicroPDP-11/something, both running _Ultrix_. And I mean Ultrix. It says Ultrix when it boots, on the manuals, on the order forms, and many other places. C'mon, give me a break! >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);
peterk@cbmger.UUCP (Peter Kittel GERMANY) (05/03/91)
In article <1991May2.104907.25975@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <1991May2.012127.28779@daffy.cs.wisc.edu> dinda@cat53.cs.wisc.edu (Peter Dinda) writes: > >> Sorry, the 8088 has a 16 bit ALU - most machines are characterized on >> the basis of two things - the ALU and the Data Bus Widths. The 8088 has >> an 8 bit Data Bus, but all internal processing is done 16 bits at a time. >> The register pairs can be used either as full 16 bit registers, or split >> in half to act as twice as many 8 bit registers. > >Uh, huh. And the 6809 (clearly an 8-bit machine) has a 16-bit ALU and an >8-bit data bus, 16-bit registers and PC. That makes it every bit as 16-bit >as the 80x86 (x<2). The 1802 has an 8-bit ALU, 8-bit data bus, and 16 16-bit >registers. But all three of these chips have the same limitations in their >programming model: you can't point to more than 16 bits of address at a time. Considering the ALU size can really be misleading. Someone told me that the Z80 only has a 4-bit ALU, though this processor provides some 16-bit commands (it's fast enough to break the 16-bit values into 4-bit nibbles and process them fast enough). Now what would you then call the Z80 and the CP/M running on it? 4-bit? (Ok, I know this only from hearsay, please correct me if I'm wrong.) -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
peter@sugar.hackercorp.com (Peter da Silva) (05/03/91)
In article <43Eq02wy07X=01@JUTS.ccc.amdahl.com> kls30@DUTS.ccc.amdahl.com (Kent L. Shephard) writes: > You confuse features and function. A 16bit OS DOES NOT have to have > multitasking to be 16bit. 16-bit is a label. Applied to a CPU it has one meaning. Applied to an O/S there really isn't any meaning to it: CP/M runs on 8-bit and 32-bit CPUs. OS/9 does too. But CP/M is an 8-bit O/S, and OS/9 is a 16-bit O/S. > It must also support the relavent data type. MS-DOS does both, ie. > 640k memory and 16bit data types. Operating systems don't address memory. Operating systems don't support data types. CPUs and compilers do. Operating systems provide services to application programs. I'm categorising the operating systems by the services generally provided by other operating systems written for a class of CPUs. It makes as much sense as intel's calling the 8088 a 16-bit chip. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
daveh@cbmvax.commodore.com (Dave Haynie) (05/03/91)
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.
kdarling@hobbes.catt.ncsu.edu (Kevin Darling) (05/04/91)
In <21216@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: > [...] > 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. Small correction: OS9/68K (OSK) _itself_ has no limits; it works with 32-bit addresses, and any size chunk. The base 68000 cpu offset-limit handling is something the PIC/reentrant applications take care of themselves, via jump tables or using a temporary register for far offsets. And the "limit" there is 64K, not 32K... since the available 68000 register addressing offsets are +/-32K, y'see. OSK compilers automatically offset data references by $8000. Options deal with the more remote data/code. > 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. Hey, blame _Motorola_ for the 64K offset limits on a 68000 <g>. "Pure" (reentrant) code for the Amiga OS has the same data offset limitations. I must say that too many Amiga programmers shy away from the reentrant and position-independent modes of the 680x0, btw. Treating a 68K cpu like a giant 6502 makes me want to throw up :-). The fact that those addressing modes are _faster_ than the long addressing modes often used instead, is taking a long time to sink in. Yet they're what the cpu was designed for! To me, the Ami relocating loader is more Intel-like, than Motorola-like. Full agreement with the rest of your message, tho. Keep up the good work. This the first time I've ever found even a _tiny_ reason to contradict ya! deep regards - kevin <kdarling@catt.ncsu.edu>
farren@well.sf.ca.us (Mike Farren) (05/04/91)
daveh@cbmvax.commodore.com (Dave Haynie) writes: >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. Not really. That's much more a matter of choice of mnemonics, rather than architectural similarity. The 8086 differed significantly from the 8080/8085, with only some basic architectural decisions (few registers, somewhat skewed addressing modes) making it "easy" to port assembly code between the two. The 8086, ***at the time it was introduced***, was a big step up. Until that time, the only 16-bit processors you could get were the National Semiconductor IMP-16 and the Texas Instruments TI9900, both of which were weird, weird, weird, both in the hardware and the software. The 8086, in comparison, was a delight. Of course, Motorola did the 68000 a year or two later, but for quite a while, you chose an 8086 or nothing if you wanted a reasonable 16-bit processor. -- Mike Farren farren@well.sf.ca.us
ping@ping.actrix.gen.nz (Peter Ingham) (05/04/91)
Quoted from <...unknown> by jbickers@templar.actrix.gen.nz (John Bickers): > Quoted from <1991May1.064455.3058@kessner.denver.co.us> by david@kessner.denver.co.us (David Kessner): > > > the instruction set to it's registers indicate this. MS-DOS fully > > utilizes all of the 8088 features, so I will classify it as a 16 bit OS. > > When one calls an MS-DOS "interrupt" (haw, reminds me of the C= 64), > isn't the interrupt number a byte? > > That's a fundamental part of the OS that is only 8 bits. > Not quite, 808x software & hardware interrupts use 8-bit identifiers to allow the O/S to know from whence the interrupt originated. This is a Hardware design restraint rather than a feature (or lack of it) in any particular 808x OS. -- Cheers Peter S. Ingham ping@ping.actrix.gen.nz Lower Hutt, New Zealand
<DXB132@psuvm.psu.edu> (05/04/91)
In article <1991May3.220043.28760@ncsu.edu>, kdarling@hobbes.catt.ncsu.edu (Kevin Darling) says: >Hey, blame _Motorola_ for the 64K offset limits on a 68000 <g>. "Pure" >(reentrant) code for the Amiga OS has the same data offset limitations. It doesn't help, but the '020 and higher offer full 32-bit offsets... -- Dan Babcock
ping@ping.actrix.gen.nz (Peter Ingham) (05/04/91)
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. <Enable flame retardent> 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
jbickers@templar.actrix.gen.nz (John Bickers) (05/04/91)
Quoted from <160.tnews@ping.actrix.gen.nz> by ping@ping.actrix.gen.nz (Peter Ingham): > Quoted from <...unknown> by jbickers@templar.actrix.gen.nz (John Bickers): > > When one calls an MS-DOS "interrupt" (haw, reminds me of the C= 64), > > isn't the interrupt number a byte? > This is a Hardware design restraint rather than a feature (or lack of it) > in any particular 808x OS. The OS is supposed to be tied to the hardware... the smaller the CPU, the more likely this is to be. This is exactly why so many people think of MS-DOS as an 8-bit (or less) OS. > Peter S. Ingham ping@ping.actrix.gen.nz -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
ping@ping.actrix.gen.nz (Peter Ingham) (05/04/91)
Quoted from <...unknown> by daveh@cbmvax.commodore.com (Dave Haynie): > Scars acquired over years of working "in the business" are a reasonable > assurance. Providing the scars have induced knowledge and insight, rather than being the result of repeated incompetence!!!! > > >>As far as the programming model (the only one that counts) is concerned, > >>the 8088 is an 8-bit processor with 4 bank-select registers built in. > > >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 8088 is only 8-bit from the EXTERNAL hardware veiwpoint. As is the 68008. > >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. > From a commercial perspective I'd say they were absolutely right. > 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 Not quite right Dave. In the early days, MS-dos was made available on several non-clones. MS-dos was implemented to operate on top of a System-dependant BIOS. The intention was that USER programs would NOT use BIOS calls, nor access the hardware directly. I know of at least two MS-Dos implementations (both more than 6 years since release) where the "BIOS" is in fact a multi-tasking, interrupt-driven O/S, more powerfull in it's own right than MS-DOS (which it views as a task). PC-DOS, on the other hand, _IS_ clone specific. PC-DOS (as released by IBM) contained IBM additions. IBM also encouraged (through detailed documentation) the direct calling of BIOS routines, and direct access to hardware. Due to the commercial realities of 3rd-Party developers going after every last ounce of performance etc etc, they have bypassed the O/S in many cases. This was not helped by the severe lack of features and future-direction compatibility considerations in the O/S. So what happens? Everyone goes their own way, the O/S slowly becomes almost irrelevant and you end up with a marketplace based around a Hardware Interface (the "Clone") rather than a software model of a virtual hardware environment. Some user software (eg: Multiplan 3.0) has been released as both MS-DOS *AND* PC-DOS compatible. (ie: avoids System-specifics). > system dependent. MS-DOS, for all intents and purposes, is system dependent, > as the owners of Tandy 1200s or Mindsets could well attest to. As above, don't confuse MS-DOS, with PC-DOS/ PC-Clone requirements. Imagine what the Amiga environment would be like in 5 years time if Commodore had a generally incompetent O/S, had/did not provide for future expansion, etc etc. We would be just like the PC marketplace is today: Fragmented with many incompatible, 3rd-party, proprietary add-ons Both Microsoft & IBM admitted this with the OS/2 strategy. Here they tried to get the world to follow them into a better non-hardware specific environment. But it has a cost, memory and performance. It seems the world is not prepared to pay that price ... Remember, today IBM is the largest Clone builder around. They are now trapped the same as everyone else. They tried to change direction and the world ignored them ... Wait 'till Commodore are forced to change the underlying hardware definition of the Amiga range (ie: the chipset). Then we'll see how many developers have been listening!!! -- Cheers Peter S. Ingham ping@ping.actrix.gen.nz Lower Hutt, New Zealand
kdarling@hobbes.catt.ncsu.edu (Kevin Darling) (05/05/91)
DXB132@psuvm.psu.edu writes: >In article <1991May3.220043.28760@ncsu.edu>, kdarling@hobbes.catt.ncsu.edu >(Kevin Darling) says: >> >>Hey, blame _Motorola_ for the 64K offset limits on a 68000 <g>. "Pure" >>(reentrant) code for the Amiga OS has the same data offset limitations. > >It doesn't help, but the '020 and higher offer full 32-bit offsets... Yah, but still wish they'd started off that way. Ah well. The only other slight disappointment I ever had was with the 68008... I think it should've been able to use non-aligned data/code. Many years back I homebrewed a 68008 coprocessor for my old CoCo I. It had its own 8K static RAM, but also full access to the coco's ram and i/o space during internal 6809 cycles (the AVMA multiprocessor line on the '09 was perfect for this). Sure could clear the screen fast! <g> But the word-alignment thingie kept me from having more, and easy, fun. them were the hacking days, eh? - kev <kdarling@catt.ncsu.edu>
peter@sugar.hackercorp.com (Peter da Silva) (05/05/91)
In article <1991May3.041705.9907@kessner.denver.co.us> david@kessner.denver.co.us (David Kessner) writes: > IMHO, the 'bits' of an OS is the largest number it can put in a CPU register. I have never, in my experience, seen an O/S with registers. That's hardware. But then, if you wish: > In this light, MS-DOS is a 16 bit OS. Plain and simple. Same is true for CP/M. HL on the 8080 is 16 bits wide. IX and IY on the Z80 are too. Or how about MCP, the O/S I worked on in my last job... the 1802 has *16* 16-bit registers! That's 12 (or is that 13) more than the 8088. > Yes, I include the BIOS in the general scheme of MS-DOS. Microsoft doesn't. > 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. That doesn't handle the differences between the IBM-PC, HP150, Victor 9000, TI-PRO, etc... or more recently the Data General 1... > The BIOS is highly standardized. In fact, they are (almost) > interchangeable between machines-- as long as the machines have the ...exact same bugs and features as the IBM-PC/XT or /AT (including crummy UARTS that don't support synchronous I/O)... > 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. I'm not discussing bugs and other implementation shortcoming in MS-DOS here. Just the software architecture. > And this makes it a 8 bit OS? Yes. The fact that it doesn't provide a hardware-independent application program interface for these resources. All an O/S is, at the bottom level, is a resource manager. So that's what I look at: what resources it manages and how complete the interface. > 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... No, they're a hybrid between 8-bit and real 16-bit CPUs. > 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. Yes, and on those merits it really sucks. Motorolas 16/32 and 8/16 bit CPUs of the same era (68000, 6809) both blow it out of the water. > In the same, MS-DOS should be evaluated by looking at MS-DOS-- not CP/M. Why? CP/M was one of its competitors. > This is more of a function of the hardware than MS-DOS. Well look at the fate of computers that did a better job. If MS-DOS had been a real 16-bit O/S instead of a port of an 8-bit one the HP150, Victor 9000, TI PRO, and so on would have been successes. > (Damn Compatibility) Compatibility is only a problem if what you're compatible with causes problems. > 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. There were not a lot of hardware standards when the PC came out, either. > If you cant flame MS-DOS, who can you flame? Damn good question. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (05/05/91)
In article <1991May3.043704.10066@kessner.denver.co.us> david@kessner.denver.co.us (David Kessner) writes: > So, using your definitions for 8, 16, and 32 bit OS's (not quoted here), why > should we use 'bits' as the unit of measurement-- Don't ask me. I didn't start it. > Perhapse another term should be 'generation', 'level', etc. I myself prefer dividing things between: "monitor" ROM resident, usually loads programs from tape. Provides the services of simple I/O, execution control. "program loader" loaded from disk (usually), provides a file system, program loading, execution control, simple I/O. "operating system" adds real device drivers and device independence, memory and CPU time management. "protected O/S" adds resource tracking and protection. "multiuser O/S" adds privileged programs of some sort, permissions, etc. "VM O/S" adds virtual memory to one of the above. DOS doesn't even qualify as an O/S to me. Neither does Mac OS, or any PC system software prior to the Amiga. > Why don't _YOU_ check your facts. I have programmed a PDP-11/23 and a > MicroPDP-11/something, both running _Ultrix_. And I mean Ultrix. It says > Ultrix when it boots, on the manuals, on the order forms, and many other > places. C'mon, give me a break! Yes, I've been told that DEC sold V7 under that name. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (05/05/91)
In article <24582@well.sf.ca.us> farren@well.sf.ca.us (Mike Farren) writes: >daveh@cbmvax.commodore.com (Dave Haynie) writes: > >>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. > >Not really. That's much more a matter of choice of mnemonics, rather than >architectural similarity. The 8086 differed significantly from the 8080/8085, >with only some basic architectural decisions (few registers, somewhat skewed >addressing modes) making it "easy" to port assembly code between the two. > >The 8086, ***at the time it was introduced***, was a big step up. Until that >time, the only 16-bit processors you could get were the National Semiconductor >IMP-16 and the Texas Instruments TI9900, both of which were weird, weird, >weird, both in the hardware and the software. The 8086, in comparison, was >a delight. Of course, Motorola did the 68000 a year or two later, but for >quite a while, you chose an 8086 or nothing if you wanted a reasonable >16-bit processor. The 6809 was a 16-bit processor (internal) and was as nice a chip as you can even find today. The only difference between it and the 8088 was that the 8088 has a method of bank selecting memory on-chip while the 6809 required extra hardware (i.e. segment registers). >-- >Mike Farren farren@well.sf.ca.us -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
peter@sugar.hackercorp.com (Peter da Silva) (05/05/91)
In article <1991May3.220043.28760@ncsu.edu> kdarling@hobbes.catt.ncsu.edu (Kevin Darling) writes: > I must say that too many Amiga programmers shy away from the reentrant and > position-independent modes of the 680x0, btw. Another plus for high level code. Recompile with Manx. > Treating a 68K cpu like a > giant 6502 makes me want to throw up :-). You mean like a giant PDP-11. > To me, the Ami relocating loader is more Intel-like, than Motorola-like. Gah. Intel's the one with segments on the brain. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (05/05/91)
In article <24582@well.sf.ca.us> farren@well.sf.ca.us (Mike Farren) writes: > The 8086, ***at the time it was introduced***, was a big step up. How about the time the PC came out? > Of course, Motorola did the 68000 a year or two later, but for > quite a while, you chose an 8086 or nothing if you wanted a reasonable > 16-bit processor. When the PC was done there were a number of choices: 68000, 8086, Z8000, etc... I think the F-11 (PDP-11 on a chip) was out. Hold. 1981 edition of the Osborne 16-bit micro handbook. Includes some real oddballs, like the 2900 bit-slicers. I'd hesitate to call some of these 16-bitters (the 2900s are 1-bitters) but it includes the DG Nova as well as the 8086, 68000, and Z8000. And the TMS9900. The first 16-bit CPU it lists is the PACE/INS8900. 4 GP registers. Interesting, hardware stack with an overflow interrupt. Only 10 words deep, though. Only 16-bit external addressing, like the 6809. Overall I'd rate the 6809 as a better "16 bit" CPU. General Instruments CP1600... looks pretty much like a baby PDP-11. 8 general purpose registers, with R7 as the PC. Only one bit of addressing mode, so the upper registers postincrement and predecrement on indirect reads and writes. Cute. Not a bad design. Still only 16 bits of memory addressing, but at least as good as the 6809. TMS9900 Weird. Single chip Nova. Another stripped down minicomputer like the TMS9900 and the F-11. 4 GP registers. Pretty normal. 8086. First with >16 bit address space, albeit via bank selecting. Really weird selection of registers... every bit as psycho as I recall. Z8000. 68000. And then the bit-slice stuff. NO mention of the 6809 in either the 8- or 16- bit handbooks, but it's at least as 16-bit as most of the micros in this book from a programmer's standpoint. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
jerry@polygen.uucp (Jerry Shekhel) (05/06/91)
peter@sugar.hackercorp.com (Peter da Silva) writes: > >Microsoft has abandoned OS/2, didn't you notice? > >(OS/2: bigger than UNIX and does half as much. Would *you* buy half an O/S?) > All right. This "half-an-OS" garbage is beginning to irritate me. Microsoft is a business; they dropped it because it wasn't selling. That doesn't mean it wasn't a superior OS. In this industry, people don't always buy the better product, and you should know that, Mr. Experience. Your statement that OS/2 is bigger than UNIX is complete bull, as is your statement about OS/2 functionality. You have obviously never seen it or been exposed to the richness of its API. >Peter da Silva. `-_-' ><peter@sugar.hackercorp.com>. -- +-------------------+----------------------+---------------------------------+ | JERRY J. SHEKHEL | POLYGEN CORPORATION | When I was young, I had to walk | | Drummers do it... | Waltham, MA USA | to school and back every day -- | | ... In rhythm! | (617) 890-2175 | 20 miles, uphill both ways. | +-------------------+----------------------+---------------------------------+ | ...! [ princeton mit-eddie bu sunne ] !polygen!jerry | | jerry@polygen.com | +----------------------------------------------------------------------------+
daveh@cbmvax.commodore.com (Dave Haynie) (05/07/91)
In article <1991May3.220043.28760@ncsu.edu> kdarling@hobbes.catt.ncsu.edu (Kevin Darling) writes: >In <21216@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes: >I must say that too many Amiga programmers shy away from the reentrant and >position-independent modes of the 680x0, btw. There's nothing wrong with either, when used for the right reasons. And everything wrong with both, when used for the wrong reasons. >Treating a 68K cpu like a giant 6502 makes me want to throw up :-). Me too. I would rather see it treated like the 32 bit CPU that it is, maybe like a VAX. >The fact that those addressing modes are _faster_ than the long addressing >modes often used instead, Assuming you have small chunks of code. Going through wacky jump tables because you don't have a way to deal with proper linear addresses in large programs seems to me to be, well, rather Intel-like. >Yet they're what the cpu was designed for! No, they're one option, among many. A simple tradeoff between instruction time and code size. And of course, now we have real 32 bit buses and ALUs in these things, not that 68000 hybrid nonsense. And in any case, once you need the code size, they get in the way just as surely as 8088 segments. Pure code is good for a 3K "C:" tool that I want on the resident list, and base register addressing doesn't get in the way. For a 1MB CAD or DTP program, it will get in the way, and I have no need to make the thing resident. -- 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.denver.co.us (David Kessner) (05/07/91)
In article <1991May5.022646.19235@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <1991May3.041705.9907@kessner.denver.co.us> david@kessner.denver.co.us (David Kessner) writes: >>IMHO, the 'bits' of an OS is the largest number it can put in a CPU register. > >I have never, in my experience, seen an O/S with registers. That's hardware. You know exactly what I mean! The OS obviously has to store it's numbers in registers... >> In this light, MS-DOS is a 16 bit OS. Plain and simple. > >Same is true for CP/M. HL on the 8080 is 16 bits wide. IX and IY on the Z80 >are too. Or how about MCP, the O/S I worked on in my last job... the 1802 >has *16* 16-bit registers! That's 12 (or is that 13) more than the 8088. So be it. But _you_ are the only one that wishes to bother talking about CP/M, etc, etc. >> Yes, I include the BIOS in the general scheme of MS-DOS. > >Microsoft doesn't. Well Microsoft still things of a 286 based machine as the ideal multi-media machine! >> 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. > >That doesn't handle the differences between the IBM-PC, HP150, Victor 9000, >TI-PRO, etc... or more recently the Data General 1... The BIOS was limited by a bad inital design. Early on, a lot of programmers learned that the BIOS didn't do many things very well-- namely video/graphics, serial I/O, and a few other things. Then there were many programmers that insisted on going around the OS and access the hardware directly. The BIOS cannot mask the hardware differences when the BIOS is not used. The machines you mentioned have serious compatability problems at the hardware level-- usually in the video circutry. This is a case of a bad design influencing bad programmers yeilding a mess. Otherwise, the BIOS offers a very good hardware independance-- noteably with hard drives, keyboard controllers, simple video, etc. Other things are so standardized that it doesnt make much of a difference. >> The BIOS is highly standardized. In fact, they are (almost) >> interchangeable between machines-- as long as the machines have the > >...exact same bugs and features as the IBM-PC/XT or /AT (including crummy >UARTS that don't support synchronous I/O)... Well, yes. The BIOS is basically the same as it was way back when, with only minor improvements. The UARTs are really not so crummy, but they are strictly async. (In the ten years I have worked with computers, from home computers to mainframes, I have never needed a sync port for a PC). >> 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. > >I'm not discussing bugs and other implementation shortcoming in MS-DOS here. >Just the software architecture. You wanted to know why I thought of the BIOS as part of MS-DOS... And I told you... >> And this makes it a 8 bit OS? > >Yes. The fact that it doesn't provide a hardware-independent application >program interface for these resources. All an O/S is, at the bottom level, >is a resource manager. So that's what I look at: what resources it manages >and how complete the interface. I'll say it again: Your requirements for a 8/16/32 bit OS have nothing to do with 8/16/32 bit numbers. Either change you requirements, or change your terminology (ie, from 8-bit-OS to ??????)-- because what you are saying now does not make sense. >> In the same, MS-DOS should be evaluated by looking at MS-DOS-- not CP/M. > >Why? CP/M was one of its competitors. Great. So I'll look at a FORD and pay for a CHEVY... >> This is more of a function of the hardware than MS-DOS. > >Well look at the fate of computers that did a better job. If MS-DOS had been >a real 16-bit O/S instead of a port of an 8-bit one the HP150, Victor 9000, >TI PRO, and so on would have been successes. No. If MS-DOS/BIOS had been designed properly, and the programmers did not go around the OS and access the hardware directly, then those machines would have been successes. Also, the machines you mentioned were all made when there was still some degree of BIOS incompatability (due in part to IBM's laywers). These problems have been ironed out in todays machines... I don't know about the Data General machine, so I don't include it in the above statement. >> If you cant flame MS-DOS, who can you flame? > >Damn good question. Current suggestions have been OS/2, Windows, and just about anything from Microsoft/IBM... >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);
david@kessner.denver.co.us (David Kessner) (05/07/91)
In article <1991May5.024025.19463@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >Don't ask me. I didn't start it. Well who the hell did? Twasn't me (I didnt even join the discussion for a week or so after it started)... >> Perhapse another term should be 'generation', 'level', etc. > >I myself prefer dividing things between: > > "monitor" ROM resident, usually loads programs from tape. Provides > the services of simple I/O, execution control. > > "program loader" loaded from disk (usually), provides a file system, > program loading, execution control, simple I/O. > > "operating system" adds real device drivers and device independence, > memory and CPU time management. > > "protected O/S" adds resource tracking and protection. > > "multiuser O/S" adds privileged programs of some sort, permissions, > etc. > > "VM O/S" adds virtual memory to one of the above. > >DOS doesn't even qualify as an O/S to me. Neither does Mac OS, or any PC >system software prior to the Amiga. MS-DOS largely fits into the relm of "program loader". It does have some indications/hints of being an "operating system" (device drivers, third party of course, some device independance, etc) but largely fails in that respect. While not perfect, you table is _MUCH_ better than 8/16/32 bit... >> Why don't _YOU_ check your facts. I have programmed a PDP-11/23 and a >> MicroPDP-11/something, both running _Ultrix_. And I mean Ultrix. It says >> Ultrix when it boots, on the manuals, on the order forms, and many other >> places. C'mon, give me a break! > >Yes, I've been told that DEC sold V7 under that name. Ultrix -- UNIX with bugs. >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);
david@kessner.denver.co.us (David Kessner) (05/07/91)
In article <2945.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: >Quoted from <1991May1.064455.3058@kessner.denver.co.us> by david@kessner.denver.co.us (David Kessner): > >> the instruction set to it's registers indicate this. MS-DOS fully >> utilizes all of the 8088 features, so I will classify it as a 16 bit OS. > > When one calls an MS-DOS "interrupt" (haw, reminds me of the C= 64), > isn't the interrupt number a byte? > > That's a fundamental part of the OS that is only 8 bits. Huh? The 68000, 68030 (not sure of the 040), 386, etc all offer 256 different intterupts (READ: 8 bits). The C-64 (and the 6502/6510) had _THREE_, and that's if you include the RESET line! In any OS, there will be several areas that are only 8 bits, simply because it does not make sense to use more. For instance, keeping a count of the number of disk drives, serial ports, or printer ports would be pointless to use anything more than 8 bits-- when was the last time you has 255 serial ports on your 286/68000 based machine? The intterupts in MS-DOS are referenced with 8 bit numbers, because the 8088/8086 used 8 bit numbers-- the OS utilized the hardware. This has NEVER been a limitation. Even on a fully stocked machine, there are large amounts of these intterupts that are not being used simply because you can only put so much on a machine! Keep in mind that these intterupt numbers are only loosely the same as the 16 intterupt lines available on the ISA slot. The CPU allows for 256 intterupts. MS-DOS allows for 256 intterupts. The ISA bus only allows 16 of them through hardware (there are dozens of software intterupts, however). EISA, to the best of my knoledge, fixes this. In short: So? This is supposed to be a problem? >*** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** -- 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);
es1@cunixb.cc.columbia.edu (Ethan Solomita) (05/07/91)
In article <1075@stewart.UUCP> jerry@stewart.UUCP (Jerry Shekhel) writes: > >All right. This "half-an-OS" garbage is beginning to irritate me. Microsoft >is a business; they dropped it because it wasn't selling. That doesn't mean >it wasn't a superior OS. In this industry, people don't always buy the better >product, and you should know that, Mr. Experience. > Yes, the problem with OS/2 was that it wasn't selling. You say it's a superior OS? Superior to what? MS-DOS? Of course it was! Superior to Unix? NO. OS/2 basically gave you nothing beyond what Unix gives you, and so people simply decided to go the Unix route rather than a proprietary IBM route. What would you do? Unix HAS succeeded. OS/2? -- Ethan "Brain! Brain! What is Brain?"
kls30@duts.ccc.amdahl.com (Kent L Shephard) (05/07/91)
In article <2945.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: >Quoted from <1991May1.064455.3058@kessner.denver.co.us> by david@kessner.denver.co.us (David Kessner): > >> the instruction set to it's registers indicate this. MS-DOS fully >> utilizes all of the 8088 features, so I will classify it as a 16 bit OS. > > When one calls an MS-DOS "interrupt" (haw, reminds me of the C= 64), > isn't the interrupt number a byte? > > That's a fundamental part of the OS that is only 8 bits. WRONG. The Intel 80x86 limits you to 256 vectors for interrupts. That does not mean that the OS is eight bits. The hardware only supports that many vectored interrupts. So since the hardware only supports a vector of 1 byte, you'll say that the 80x86 machines are only 8 bit because that is how long the interrupt vector is. How many cpus have vector tables as long as the number of bits in their data types. I seriously doubt if you can name me a 32bit machine that uses all 32 bits to identify vectors in the vector table. > >> David Kessner - david@kessner.denver.co.us | do { >-- >*** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** >*** "Endless variations, make it all seem new" - Devo. *** -- /* -The opinions expressed are my own, not my employers. */ /* For I can only express my own opinions. */ /* */ /* Kent L. Shephard : email - kls30@DUTS.ccc.amdahl.com */
david@kessner.denver.co.us (David Kessner) (05/08/91)
In article <1991May7.145417.23345@cunixf.cc.columbia.edu> es1@cunixb.cc.columbia.edu (Ethan Solomita) writes: > Yes, the problem with OS/2 was that it wasn't selling. >You say it's a superior OS? Superior to what? MS-DOS? Of course >it was! Superior to Unix? NO. > OS/2 basically gave you nothing beyond what Unix gives >you, and so people simply decided to go the Unix route rather >than a proprietary IBM route. > What would you do? Unix HAS succeeded. OS/2? > > -- Ethan You forget the most important thing about UNIX-- It Is Not Done By IBM Or Mocrosoft! I have banished Microsoft products from my system, and only use MS-DOS to boot a term program (into a UNIX system) and to run Flight Simulator. Other than that, I want nothing to do with Bill Gates and Microsoft-- and I believe that others feel the same way. Which brings us to the ACE group. You know, Microsoft, MIPS, DEC, SCO, and Compaq(?). The group that wants to port OS/2 to the MIPS CPU (and somehow run it on top of UNIX). The group that wants to make OSF/1 and Ultrix merge, with SCO somehow fitting into the works. God, what a nightmare! Just think about it: DEC Workstation _clones_ running a mangled UNIX with OS/2! I'm glad that SCO (partally owned by Microsoft) has refused to port System Vr4. It means Microsoft cannot screw it up for the rest of us! -- 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);
david@kessner.denver.co.us (David Kessner) (05/08/91)
At last! Words of Windom! I just _had_ to reply to this one... In article <165.tnews@ping.actrix.gen.nz> ping@ping.actrix.gen.nz (Peter Ingham) writes: >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. Tis true, but which is the better choice? From the hardware/software aspect of it, clearly Motorola made the better chioce-- but Intel (and others like AMD, who make 286's, 386's etc) have probably made more money. ><Enable flame retardent> Yea. You and me, Buddy! >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. More importantly, you loose out in (short-term) programming utilities, compilers, debuggers, etc. But oh well. Motorola clearly made the better design chioce early on, they were thinking about the future. Intel was thinking in the past, compatability. >Was MS-DOS a _copy_ of CP/M? NO. Thank you. >Was it designed to provide close to identical facilities? Yes >Does (did) it add significant new functionality over & above CP/M? No >Similar Functionality Spec, different implementation. Exactly! >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) Exactly. Perhapse Peter da Silva will figure that out sometime... >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. Clearly, he is talking about something else that does not have anything to do with the number of bits. >Is MS-DOS an Operating System?? Some would argue that it is in fact an >overgrown file handler, and little more. Ah, yes. But it is a 16 bit file handler/program loader! :) >There are also some very competent operating systems around for 80xx6. >. . . . . . . . >I think we all agree that MS-DOS is not one of these. <Big Grin> > Peter S. Ingham ping@ping.actrix.gen.nz -- 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);
jbickers@templar.actrix.gen.nz (John Bickers) (05/08/91)
Quoted from <1075@stewart.UUCP> by jerry@polygen.uucp (Jerry Shekhel): > peter@sugar.hackercorp.com (Peter da Silva) writes: > >Microsoft has abandoned OS/2, didn't you notice? > All right. This "half-an-OS" garbage is beginning to irritate me. Microsoft > is a business; they dropped it because it wasn't selling. That doesn't mean I thought IBM _took_ it from Microsoft because they thought Microsoft was botching it. The IBM version coming out now is apparently way ahead of the old one (I say apparently, because that's just what the local OS/2 enthusiasts say - I wouldn't touch it myself, unless I was paid to - nothing that runs on an Intel CPU can be worthwhile). > Your statement that OS/2 is bigger than UNIX is complete bull, as is your > statement about OS/2 functionality. You have obviously never seen it or Does OS/2 multitask as nicely as Unix, have all those crontab and uucp facilities, the user/group/world file protection stuff, etc? > been exposed to the richness of its API. Things like run-time libraries, etc? :) > | JERRY J. SHEKHEL | POLYGEN CORPORATION | When I was young, I had to walk | -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
jbickers@templar.actrix.gen.nz (John Bickers) (05/08/91)
Quoted from <1991May7.090333.1449@kessner.denver.co.us> by david@kessner.denver.co.us (David Kessner): > In article <2945.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: > > When one calls an MS-DOS "interrupt" (haw, reminds me of the C= 64), > > That's a fundamental part of the OS that is only 8 bits. > The 68000, 68030 (not sure of the 040), 386, etc all offer 256 different > intterupts (READ: 8 bits). The C-64 (and the 6502/6510) had _THREE_, and So? I meant the way you call the OS. In the C= 64 it involved either ROM jumping or using fixed tables of vectors into the ROMs. In the PClone, it appears to involve using fixed tables of vectors into the ROMs. I could be wrong here. Is there some other decent way to call an MS-DOS function besides using that vector table? All I ever see is the int86() etc functions in Microsoft C. > In any OS, there will be several areas that are only 8 bits, simply > because it does not make sense to use more. For instance, keeping a No doubt. But in MS-DOS this is a _fundamental_ part of the thing. > In short: So? This is supposed to be a problem? No (not any more than any other MS-DOS feature, anyhow. Sharing interrupts strikes me as being reminiscent of the C= 64 as well, and also seems like a pain in the a). This is supposed to be an example of why MS-DOS is a puny OS, therefore 8-bit (hm, doesn't the '-' in 8-bit mean "or less"? :). > David Kessner - david@kessner.denver.co.us | do { -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
stevew@en.ecn.purdue.edu (Steven L Wootton) (05/08/91)
In article <3330.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: > > Does OS/2 multitask as nicely as Unix, have all those crontab and > uucp facilities, the user/group/world file protection stuff, etc? crontab and uucp are just programs; you can add them to almost any system. crontab is tough to add to MS-DOS, but there are timed execution programs out there. UUCP is slightly easier (uupc is pretty good). If these things can be added to DOS, they can surely be added to OS/2. Why expect them to be built in? WRT file protection, wouldn't user/group/world make more sense on a multiuser machine? At last count, OS/2 is a single-user, multitasking OS. Besides, I'd rather have an ACL (ala DomainOS) than the simplistic UNIX protection scheme. Much more useful. Steve Wootton stevew@ecn.purdue.edu stevew@pur-ee.uucp stevew%ecn.purdue.edu@purccvm.bitnet
ckp@grebyn.com (Checkpoint Technologies) (05/08/91)
In article <3335.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: >Quoted from <1991May7.090333.1449@kessner.denver.co.us> by david@kessner.denver.co.us (David Kessner): >> In article <2945.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: > >> > When one calls an MS-DOS "interrupt" (haw, reminds me of the C= 64), > >> > That's a fundamental part of the OS that is only 8 bits. > >> The 68000, 68030 (not sure of the 040), 386, etc all offer 256 different >> intterupts (READ: 8 bits). The C-64 (and the 6502/6510) had _THREE_, and > > So? I meant the way you call the OS. In the C= 64 it involved either > ROM jumping or using fixed tables of vectors into the ROMs. In the > PClone, it appears to involve using fixed tables of vectors into the > ROMs. To define a few terms... An "interrupt" comes from an outside device, on the x86 by asserting the INT line and on the 68K by asserting a combination of the three IPL lines. Motorola defines "interrupts" as part of a general category called "exceptions". These include real interruptions as well as exceptions caused by program activity, like divide by zero, illegal instructions, and TRAP instructions. Intel calls all these things interrupts, and in fact have an instruction INT which simulates the effect of an external interrupt source. All this was to show how the quoted arguments are really speaking of different things. Both the 68K and the x86 allow for 256 externally identified interrupt sources, using an 8 bit "vector" to differentiate. The Intel INT instruction can simulate any one of them. The vectors generated by 68K instructions are limited to a set of vectors specifically meant for those purposes: the TRAP vectors (16 of them), the TRAPV vector, the ILLEGAL vector, the A-line and F-line vectors, and a few others I don't recall right now. The 68K defines the vector meanings far better than Intel does - especially since the x86 doesn't have a supervisor mode and any program can generate any INT it wants. (This has lead to conflicts between program-use vectors and hardware-use vectors in the past, when a new hardware device begins using a vector that software had been using. This problem can't occur on the 68K since the set of program-generatable vectors is so well defined.) > > I could be wrong here. Is there some other decent way to call an > MS-DOS function besides using that vector table? All I ever see is > the int86() etc functions in Microsoft C. The Amiga Exec uses straight JSRs rather than TRAPs. MS-DOS could have done this, and considering the absense of separate user and kernel modes it would have made good sense. But the INT call is shorter; it uses a jump table automatically, the vector table, so long as 256 routiunes is enough. But frankly, it never is, and MS-DOS ran out of them. They also put a request code in AL I believe, somewhat negating the benefit of the vector table. -- Richard Krehbiel, private citizen ckp@grebyn.com (Who needs a fancy .signature?)
daveh@cbmvax.commodore.com (Dave Haynie) (05/09/91)
In article <1991May7.194753.3339@kessner.denver.co.us> david@kessner.denver.co.us (David Kessner) writes: >Which brings us to the ACE group. You know, Microsoft, MIPS, DEC, SCO, >and Compaq(?). The group that wants to port OS/2 to the MIPS CPU (and >somehow run it on top of UNIX). The group that wants to make OSF/1 and >Ultrix merge, with SCO somehow fitting into the works. God, what a >nightmare! Just think about it: DEC Workstation _clones_ running >a mangled UNIX with OS/2! Actually, from all I've read on the ACE group, they're not trying to mix OS/2 and UNIX together, per se. They plan on two individual operating systems, UNIX and a new MIPS-based OS/2, that can run on all machines. Binary compatibility between all UNIX ports and all OS/2 ports. The only compatibility between UNIX and OS/2 is at the source level, and there only if you stick to standards, like maybe POSIX or X-Open or whatever function libraries. The most, or even only, interesting thing about this setup, is that it has all of the elements in it that made PC Clones successful. It has a big HW company (DEC) and big SW company (Microsoft) behind it. The HW can theoretically be cloned by anyone. The SW, HW, and Chips each come from separate companies, so no company can really control the way any factor moves alone. All this means is that it could be successful. I personally like the MIPS architecture, and would find such a setup less worrysome to get into than perhaps the current RISC alternative, SPARC, in which the OS comes from a company that's also the largest vendor of systems in that market. >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.
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (05/09/91)
In article <2945.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: >Quoted from <1991May1.064455.3058@kessner.denver.co.us> by david@kessner.denver.co.us (David Kessner): > >> the instruction set to it's registers indicate this. MS-DOS fully >> utilizes all of the 8088 features, so I will classify it as a 16 bit OS. > > When one calls an MS-DOS "interrupt" (haw, reminds me of the C= 64), > isn't the interrupt number a byte? > > That's a fundamental part of the OS that is only 8 bits. > >> David Kessner - david@kessner.denver.co.us | do { >-- >*** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** >*** "Endless variations, make it all seem new" - Devo. *** By this definition, the Atari ST OS (CPM/68K) is a 4-bit OS? It uses 68000 traps, which are 4 bits. -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
david@kessner.denver.co.us (David Kessner) (05/09/91)
In article <3335.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: >> > When one calls an MS-DOS "interrupt" (haw, reminds me of the C= 64), >> > That's a fundamental part of the OS that is only 8 bits. >> The 68000, 68030 (not sure of the 040), 386, etc all offer 256 different >> intterupts (READ: 8 bits). The C-64 (and the 6502/6510) had _THREE_, and > > So? I meant the way you call the OS. In the C= 64 it involved either > ROM jumping or using fixed tables of vectors into the ROMs. In the > PClone, it appears to involve using fixed tables of vectors into the > ROMs. > > I could be wrong here. Is there some other decent way to call an > MS-DOS function besides using that vector table? All I ever see is > the int86() etc functions in Microsoft C. Hmmm. The vector table that you refer to is not 'fixed'. It is a relatively simple matter to make a 'third-party' replacement for these functions-- Unlike the C-64, where you had to copy the ROM at F000-FFFF into RAM, wedge in the new routine, switch out the RAM, then hope to God that no-one is going to use that area of RAM. Anyway, your right. That intterupt table is used to call OS functions. Actually, those 256 intterupts are usually thought of as hardware intterupts, but it is a relatively simple matter to cause a SOFTWARE intterupt-- and that is just what we do. In reality, I don't think that this is any better or worse than using a traditional jump table. It is, however, better than the Atari ST's version where it makes OS calls by causing a CPU exceptions (like using a non-existant opcodes). Normally, the OS calls are done in assembly, where it is very simple to load the registers and do an 'int ??' instruction. Emulating this in C is clumsy at best. In the past two years I've written about 1500-2000 pages of code on the PC. In that, I've called OS functions about 50 times-- and used the int86() function about four times. I've found that any set of routines that uses a lot of 'int' calls can benifit greatly from a rewrite in assembly-- and I question any programmer that doesn't do this. >> In short: So? This is supposed to be a problem? > > No (not any more than any other MS-DOS feature, anyhow. Sharing > interrupts strikes me as being reminiscent of the C= 64 as well, > and also seems like a pain in the a). This is supposed to be an > example of why MS-DOS is a puny OS, therefore 8-bit (hm, doesn't > the '-' in 8-bit mean "or less"? :). I understand Dave Haynie's explanation for shared intterupts in todays 32 bit CPU's-- but I too think it is a little old-fashoned. You have 256 intterupts, use them! You cannot possibly have over 256 hardware intterups, perhapse 30-50 max, so there is no danger of using them all up... Hell, I memory serves me, it has about 50 unused intterupts-- and it's using them for OS calls at that! 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); -- 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);
jbickers@templar.actrix.gen.nz (John Bickers) (05/09/91)
Quoted from <69VT02ZW07LF01@JUTS.ccc.amdahl.com> by kls30@duts.ccc.amdahl.com (Kent L Shephard): > In article <2945.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: > > When one calls an MS-DOS "interrupt" (haw, reminds me of the C= 64), > > isn't the interrupt number a byte? > > > > That's a fundamental part of the OS that is only 8 bits. > > WRONG. The Intel 80x86 limits you to 256 vectors for interrupts. That Which part is "WRONG"? That this is a fundamental part of the OS, or that it's only 8 bits? > does not mean that the OS is eight bits. The hardware only supports that > many vectored interrupts. So since the hardware only supports a vector Who cares how many damned interrupts the hardware supports? As someone pointed out, 680x0 chips provide similar sorts of numbers too. My point is that the "OS", MS-DOS, the thing we are talking about, uses these "interrupts" as the interface to applications run on it. That limits things to 8 bits worth of hooks into the OS. More than enough for a tinny little thing like MS-DOS, running on 640K application RAM PClones, but nevertheless, only 8 bits. I believe (and my Usenet feed is at home, so I don't have manuals and things on hand, sorry) that MS-DOS does things like have 1 vector for a particular range of functions, and when you call one of that range, you have to stuff another byte-sized value into a register and then invoke the interrupt for that range. > of 1 byte, you'll say that the 80x86 machines are only 8 bit because that > is how long the interrupt vector is. Well, if Unix implementations on these widgets used the same crankpot OS interface that MS-DOS uses, I'd certainly be willing to claim that they are 8-bit implementations of Unix. > /* Kent L. Shephard : email - kls30@DUTS.ccc.amdahl.com */ -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
jbickers@templar.actrix.gen.nz (John Bickers) (05/09/91)
Quoted from <1991May8.124648.17903@en.ecn.purdue.edu> by stevew@en.ecn.purdue.edu (Steven L Wootton): > In article <3330.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: > > > > Does OS/2 multitask as nicely as Unix, have all those crontab and > > uucp facilities, the user/group/world file protection stuff, etc? > out there. UUCP is slightly easier (uupc is pretty good). If these things > can be added to DOS, they can surely be added to OS/2. Why expect them to > be built in? Having things as standard tools just seems more convenient to me than having them as extras. Sort of helps define the scope of the OS, I guess. Things a marketeer can rely on their customers having, a programmer can rely on being present, and so on. > WRT file protection, wouldn't user/group/world make more sense on a > multiuser machine? At last count, OS/2 is a single-user, multitasking OS. Well, there it is. I think the original article compared OS/2 to Unix in some way, so I was wondering if OS/2 was a multiuser OS or not. Order of magnitude's difference between OSes that have to cater for multiple users as opposed to those that do not. > Steve Wootton -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
jbickers@templar.actrix.gen.nz (John Bickers) (05/09/91)
Quoted from <mykes.2364@amiga0.SF-Bay.ORG> by mykes@amiga0.SF-Bay.ORG (Mike Schwartz): > > When one calls an MS-DOS "interrupt" (haw, reminds me of the C= 64), > > isn't the interrupt number a byte? > By this definition, the Atari ST OS (CPM/68K) is a 4-bit OS? It uses 68000 > traps, which are 4 bits. Does it really? Wow! Is this the TOS thing people talk about (CPM? Local Atari folks talk about things called TOS and GEM)? Gak. Gak. Gak. Gak. I know the Amiga uses some of those trap vectors for various GURUs, but not as the OS interface. Gee, I never thought the ST was so primitive. > **************************************************** Awed... -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
jbickers@templar.actrix.gen.nz (John Bickers) (05/09/91)
Quoted from <1991May9.045705.797@kessner.denver.co.us> by david@kessner.denver.co.us (David Kessner): > In article <3335.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: > > ROM jumping or using fixed tables of vectors into the ROMs. In the > > PClone, it appears to involve using fixed tables of vectors into the > Hmmm. The vector table that you refer to is not 'fixed'. It is a relatively Same place in memory, isn't it? Yet another case of minor obfuscation... > simple matter to make a 'third-party' replacement for these functions-- Sure. As far as MS-DOS goes, I think some of the hacks and kludges fitted onto it are rather slick. Like Btrieve, the Novell database "library" thing. Shows the lengths people will go to when the market is a decent size. > In reality, I don't think that this is any better or worse than using a > traditional jump table. It is, however, better than the Atari ST's > version where it makes OS calls by causing a CPU exceptions (like using So it's true. Well well well. How depressing for ST programmers. > clumsy at best. In the past two years I've written about 1500-2000 > pages of code on the PC. In that, I've called OS functions about 50 Bit over a year and a half for me. I've called OS functions lots of times, and used int86() and co. quite often. Mostly to diddle with the time and system info, come to think of it, so I don't do complicated things with it. > from a rewrite in assembly-- and I question any programmer that doesn't > do this. Fine. In my view, they don't pay me enough to think about Intel assembler to MS-DOS. It's a judgement thing, I guess. I don't have that level of OS stuff in any hot spots. I'd also be mildly surprised if Microsoft doesn't inline the int86()-type functions, like SAS does Amiga library functions, though I've never checked. > > No (not any more than any other MS-DOS feature, anyhow. Sharing > > interrupts strikes me as being reminiscent of the C= 64 as well, > I understand Dave Haynie's explanation for shared intterupts in todays > 32 bit CPU's-- but I too think it is a little old-fashoned. You have Uh, I don't have a problem with sharing interrupts per se - the thing is _how_ you share the interrupts. Consider chaining into an MS-DOS interrupt with adding an interrupt handler to the system on the Amiga. The latter is about as slick a procedure as I could wish for. The former is reminiscient of the C= 64. > up... Hell, I memory serves me, it has about 50 unused intterupts-- and > it's using them for OS calls at that! I don't believe there's any standard way to arbitrate who gets what interrupts, is there? I have a (very useful) list on MS-DOS interrupts, that indicates various products have standard interrupts they chain into, rather than trying to locate a "next free interrupt" and using that. Having some sort of handle on allocation and deallocation of interrupts would make it a marginally more respectable system, IMHO. Named interrupts, like the Ami's named ports, or something. > David Kessner - david@kessner.denver.co.us | do { -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
peter@sugar.hackercorp.com (Peter da Silva) (05/10/91)
In article <1991May8.124648.17903@en.ecn.purdue.edu> stevew@en.ecn.purdue.edu (Steven L Wootton) writes: > WRT file protection, wouldn't user/group/world make more sense on a > multiuser machine? At last count, OS/2 is a single-user, multitasking OS. A network is a multiuser environment. Single user PCs and networks mix like Serbs and Croats (let's be topical here). ACLs are nice, but the lack of ACLs in UNIX is hardly a reason to justify the complete lack of protection in OS/2. PS: comp.os.os2.advocacy. It's time. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
jcav@quads.uchicago.edu (john cavallino) (05/10/91)
In article <3474.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: >> By this definition, the Atari ST OS (CPM/68K) is a 4-bit OS? It uses 68000 >> traps, which are 4 bits. > > Does it really? Wow! Is this the TOS thing people talk about (CPM? > Local Atari folks talk about things called TOS and GEM)? > > Gak. Gak. Gak. Gak. > > I know the Amiga uses some of those trap vectors for various GURUs, > but not as the OS interface. > > Gee, I never thought the ST was so primitive. As I understand it, the TRAPn instructions were specifically intended by Motorola to be used to invoke the operating system. After all, there are sixteen of them, they are documented instructions, and they have individual entries in the vector table. What's REALLY wierd is the Macintosh operating system, which uses the MC680x0 A-line unimplemented instructions as the OS interface, with the routine index and various flags encoded into the instruction word. -- John Cavallino | EMail: jcav@midway.uchicago.edu University of Chicago Hospitals | USMail: 5841 S. Maryland Ave, Box 145 Office of Facilities Management | Chicago, IL 60637 B0 f++ w c+ g+ k s(+) e+ h- pv (qv) | Telephone: 312-702-6900
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA) (05/10/91)
As quoted from <3335.tnews@templar.actrix.gen.nz> by jbickers@templar.actrix.gen.nz (John Bickers): +--------------- | Quoted from <1991May7.090333.1449@kessner.denver.co.us> by david@kessner.denver.co.us (David Kessner): | > In article <2945.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: | > > When one calls an MS-DOS "interrupt" (haw, reminds me of the C= 64), | > > That's a fundamental part of the OS that is only 8 bits. | | > The 68000, 68030 (not sure of the 040), 386, etc all offer 256 different | > intterupts (READ: 8 bits). The C-64 (and the 6502/6510) had _THREE_, and | | So? I meant the way you call the OS. In the C= 64 it involved either | ROM jumping or using fixed tables of vectors into the ROMs. In the | PClone, it appears to involve using fixed tables of vectors into the | ROMs. +--------------- ??? ONE interrupt is used for system calls --- INT 21H (that, by the way, is the assembly language mnemonic to signal that interrupt). This is no different from 680x0 Unixes that use "trap #0" to make a system call in assembler. BIOS has a few interrupts it uses, specifically so that BIOS replacements can be dropped into place. Theoretically, you're not supposed to call the BIOS directly, but we all know what MS-Doesn't is like.... +--------------- | I could be wrong here. Is there some other decent way to call an | MS-DOS function besides using that vector table? All I ever see is | the int86() etc functions in Microsoft C. +--------------- This is less because MS-DOS doesn't have a rational syscall mechanism than because MS-DOS doesn't have rational syscalls.... +--------------- | No (not any more than any other MS-DOS feature, anyhow. Sharing | interrupts strikes me as being reminiscent of the C= 64 as well, | and also seems like a pain in the a). This is supposed to be an | example of why MS-DOS is a puny OS, therefore 8-bit (hm, doesn't | the '-' in 8-bit mean "or less"? :). +--------------- No, it's normal to use one (or a *small* number of) entry point to the OS. Even the Mac does it, although in a twisted fashion (they hook the 1010 and 1011 unimplemented opcode traps, then have the trap handler decipher the "instruction" to determine what routine to call). The task of keeping track of interrupts gets harder as the number of possible interrupts increases, even if they're software-only interrupts. (And I daresay indexing into a private jump table based on the contents of d0 is faster than fetching a word via a pointer from the interrupt context, masking out the highest nybble, and indexing the jump table from that....) ++Brandon -- Me: Brandon S. Allbery Ham: KB8JRR/AA 10m,6m,2m,220,440,1.2 Internet: allbery@NCoast.ORG (restricted HF at present) Delphi: ALLBERY AMPR: kb8jrr.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KB8JRR @ WA8BXN.OH
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA) (05/10/91)
As quoted from <3133.tnews@templar.actrix.gen.nz> by jbickers@templar.actrix.gen.nz (John Bickers): +--------------- | Quoted from <160.tnews@ping.actrix.gen.nz> by ping@ping.actrix.gen.nz (Peter Ingham): | > Quoted from <...unknown> by jbickers@templar.actrix.gen.nz (John Bickers): | > > When one calls an MS-DOS "interrupt" (haw, reminds me of the C= 64), | > > isn't the interrupt number a byte? | | > This is a Hardware design restraint rather than a feature (or lack of it) | > in any particular 808x OS. | | The OS is supposed to be tied to the hardware... the smaller the | CPU, the more likely this is to be. This is exactly why so many | people think of MS-DOS as an 8-bit (or less) OS. +--------------- ??? Look up the "trap" instruction in a 680x0 assembler manual and say that again. If you're thinking of the 1010 and 1011 traps, they're a rather expensive way to get an extra 8192 "interrupts".... MS-DOS is considered an 8-bit OS because the 8088 processor looks a lot like an 8-bit processor, granted --- but interrupts have a lot less to do with it than those stupid segment registers. ++Brandon -- Me: Brandon S. Allbery Ham: KB8JRR/AA 10m,6m,2m,220,440,1.2 Internet: allbery@NCoast.ORG (restricted HF at present) Delphi: ALLBERY AMPR: kb8jrr.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KB8JRR @ WA8BXN.OH
stevep@wrq.com (Steve Poole) (05/10/91)
In article <1991May2.104907.25975@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: > >Microsoft has abandoned OS/2, didn't you notice? > That's not true by a long shot. What's all this cruft doing in c.s.a.a, anyhow? My 'k' key is about broken. -- -------------------------------------------------------------------------- -- INTEL 80x86: Just say NOP -- Internet: stevep@wrq.com -- AOL: Spoole -- --------------------------------------------------------------------------
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA) (05/10/91)
As quoted from <1991May7.063757.804@kessner.denver.co.us> by david@kessner.denver.co.us (David Kessner): +--------------- | In article <1991May5.022646.19235@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: | >In article <1991May3.041705.9907@kessner.denver.co.us> david@kessner.denver.co.us (David Kessner) writes: | >>IMHO, the 'bits' of an OS is the largest number it can put in a CPU register. | >> In this light, MS-DOS is a 16 bit OS. Plain and simple. | > | >Same is true for CP/M. HL on the 8080 is 16 bits wide. IX and IY on the Z80 | >are too. Or how about MCP, the O/S I worked on in my last job... the 1802 | >has *16* 16-bit registers! That's 12 (or is that 13) more than the 8088. | | So be it. But _you_ are the only one that wishes to bother talking about | CP/M, etc, etc. +--------------- Strictly speaking, it's the number of bits in the general registers/ accumulator. HL was not a general register. Actually, even more strictly speaking, it's proper to use a hybrid designator for the processors with more than one register size, thus the 8080, Z80, and 1802 (and 6809) are 8/16-bit registers. Of course, by this rule, so is the 80x86 (AH/AL)... and the 680x0 (XXX.B instructions). The largest general register disambiguates, thus AX makes the 80x86 16-bit and d0-d7 make the 680x0 32-bit. Except for the 68000 only addressing 24 bits of memory... "Bits" in this context is as meaningless as MIPS. Why fight over it? +--------------- | >> The operating system (and/or device drivers) should deal with any | >> hardware differences between machines-- and that is the role of the | >> BIOS. | > | >That doesn't handle the differences between the IBM-PC, HP150, Victor 9000, | >TI-PRO, etc... or more recently the Data General 1... | | The BIOS was limited by a bad inital design. Early on, a lot of programmers | learned that the BIOS didn't do many things very well-- namely video/graphics, | serial I/O, and a few other things. Then there were many programmers that | insisted on going around the OS and access the hardware directly. The BIOS | cannot mask the hardware differences when the BIOS is not used. +--------------- Exactly. Take a look at the BIOS serial driver some time, and have a good laugh. The other problem is that when BIOS or DOS did manage to do what you wanted, it was dog slow doing it. +--------------- | You wanted to know why I thought of the BIOS as part of MS-DOS... And I | told you... +--------------- That's not why the BIOS is part of MS-DOS, it's why MS-DOS is such a miserable excuse for an OS. BIOS was intended as a platform on which MS-DOS or CP/M-86 could be implemented in a hardware-independent fashion by providing the most basic interface to the hardware; CP/M-86 never caught on, and MS-DOS performed so miserably, that programmers resorted to calling BIOS directly or even diddling the hardware itself. It's notable that, when programs *did* do things through MS-DOS, Concurrent CP/M's DOS compatibility mechanism could multitask them quite well... and just about all standard CP/M-86 programs could be multitasked as well, because fewer CP/M-86 programmers had to resort to BIOS or hardware to get things done. ++Brandon -- Me: Brandon S. Allbery Ham: KB8JRR/AA 10m,6m,2m,220,440,1.2 Internet: allbery@NCoast.ORG (restricted HF at present) Delphi: ALLBERY AMPR: kb8jrr.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KB8JRR @ WA8BXN.OH
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA) (05/10/91)
As quoted from <1991May7.064810.905@kessner.denver.co.us> by david@kessner.denver.co.us (David Kessner): +--------------- | In article <1991May5.024025.19463@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: | > "monitor" ROM resident, usually loads programs from tape. Provides | > the services of simple I/O, execution control. +--------------- BIOS. +--------------- | > "program loader" loaded from disk (usually), provides a file system, | > program loading, execution control, simple I/O. +--------------- What MS-DOS actually achieves. +--------------- | > "operating system" adds real device drivers and device independence, | > memory and CPU time management. +--------------- What MS-DOS aspired to be, but was too inefficient and underfeatured to achieve. What CP/M-86 achieved. +--------------- | > "protected O/S" adds resource tracking and protection. +--------------- What CCP/M-86 aspired to be, and partially succeeded at. +--------------- | >DOS doesn't even qualify as an O/S to me. Neither does Mac OS, or any PC | >system software prior to the Amiga. +--------------- Peter, I fail to understand this. Where does MacOS fall short? Or are you confusing the "OS" level with the "protected OS" or "multiuser OS" level? If it has to be pre-emptively multitasking before it can really be called an OS, you neglected to indicate this in your definitions --- and serious OS designers would disagree with you. In reality, "multitasking OS" is a step between "protected OS" and "multiuser OS", where things are protected just enough to deal with inter-process contention but not with inter-user contention. Then there's "multiprocessor OS", which extends protection to the level of concurrent processes. Except that you can have multitasking without protection (any multitasker on an 8088/80286), multiuser without user access protection (MP/M) or even true resource protection (MP/M-80!). And special-purpose applications can have a system with multitasking and advanced services but no program loading, thus missing the "OS" level while incorporating features beyond it. Another example of meaningless artificial divisions.... ++Brandon -- Me: Brandon S. Allbery Ham: KB8JRR/AA 10m,6m,2m,220,440,1.2 Internet: allbery@NCoast.ORG (restricted HF at present) Delphi: ALLBERY AMPR: kb8jrr.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KB8JRR @ WA8BXN.OH
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA) (05/10/91)
As quoted from <165.tnews@ping.actrix.gen.nz> by ping@ping.actrix.gen.nz (Peter Ingham): +--------------- | 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. +--------------- Had this been true, CP/M-86 would have dominated the Intel market long since --- CP/M-86 came with a program that would convert any CP/M-80 assembler program to CP/M-86 by tweaking assembler mnemonics. What made Intel a winner was the IBM PC --- no more, no less. Which raises a ghastly "what-if": IBM originally wanted to use the 68000 for the PC, but Motorola wasn't shipping.... ++Brandon -- Me: Brandon S. Allbery Ham: KB8JRR/AA 10m,6m,2m,220,440,1.2 Internet: allbery@NCoast.ORG (restricted HF at present) Delphi: ALLBERY AMPR: kb8jrr.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KB8JRR @ WA8BXN.OH
kdarling@hobbes.catt.ncsu.edu (Kevin Darling) (05/10/91)
jcav@quads.uchicago.edu (john cavallino) writes: > As I understand it, the TRAPn instructions were specifically intended by > Motorola to be used to invoke the operating system. Exactly. Even from the original 68K docs: "Some instructions are used specifically to generate traps. The TRAP instruction always forces an exception, and is useful for implementing system calls from user programs." By using Traps as the OS interface, you also don't need to keep OS jump tables around within user space. This can often make it much easier to implement MMU-based OS's, protection, etc. So yep, the ST actually used that feature of the 68K, at least, just as the Motorola gurus had intended. best regards - kevin <kdarling@catt.ncsu.edu>
jbickers@templar.actrix.gen.nz (John Bickers) (05/10/91)
Quoted from <1991May9.191412.15264@midway.uchicago.edu> by jcav@quads.uchicago.edu (john cavallino): > As I understand it, the TRAPn instructions were specifically intended by > Motorola to be used to invoke the operating system. After all, there are Perhaps they were thinking of dishwasher OSes, or something. Trying to compete with Intel for the dishwasher OS market... :) > entries in the vector table. What's REALLY wierd is the Macintosh [Still Pascal?] > operating system, which uses the MC680x0 A-line unimplemented instructions > as the OS interface, with the routine index and various flags encoded into > the instruction word. Well, the ST thing has desensitized me, otherwise I'd fall over backwards laughing at this one. I guess this is well hidden by Mac C compilers etc. > John Cavallino | EMail: jcav@midway.uchicago.edu -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
torrie@cs.stanford.edu (Evan Torrie) (05/11/91)
jbickers@templar.actrix.gen.nz (John Bickers) writes: >Quoted from <1991May9.191412.15264@midway.uchicago.edu> by jcav@quads.uchicago.edu (john cavallino): >> As I understand it, the TRAPn instructions were specifically intended by >> Motorola to be used to invoke the operating system. After all, there are > Perhaps they were thinking of dishwasher OSes, or something. Trying > to compete with Intel for the dishwasher OS market... :) If I recall correctly, isn't this how Unix handles system entry calls? My recollection of PDP-11 V7 Unix was that all system calls were invoked via a trap instruction, with a word afterwords encoding which call was desired. >> operating system, which uses the MC680x0 A-line unimplemented instructions >> as the OS interface, with the routine index and various flags encoded into >> the instruction word. > Well, the ST thing has desensitized me, otherwise I'd fall over > backwards laughing at this one. I guess this is well hidden by Mac > C compilers etc. Like I say, isn't this how Unix does it? -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu Murphy's Law of Intelism: Just when you thought Intel had done everything possible to pervert the course of computer architecture, they bring out the 860
dac@prolix.pub.uu.oz.au (Andrew Clayton) (05/11/91)
In article <1991May9.174637.3153@sugar.hackercorp.com>, Peter da Silva writes: > here). ACLs are nice, but the lack of ACLs in UNIX is hardly a reason to > justify the complete lack of protection in OS/2. > > PS: comp.os.os2.advocacy. It's time. ~~~~~~~~~ You're a sick man, Peter. :-) Dac --
jbickers@templar.actrix.gen.nz (John Bickers) (05/11/91)
Quoted from <1991May10.183627.29486@neon.Stanford.EDU> by torrie@cs.stanford.edu (Evan Torrie): > jbickers@templar.actrix.gen.nz (John Bickers) writes: > If I recall correctly, isn't this how Unix handles system entry calls? Ok, couple of serious points/questions here... . What is the performance of this kind of system call like for a given CPU? I imagine that on a 680x0 more processing will be done as a lead-in to the function call (like the DOSBase functions), but is the TRAP faster than a JSR (not according to my assembler manual, but I may be misreading it)? . Surely for Unix this would vary from implementation to implementation. Does it? Is this what the NeXT and A/UX use? Does AT&T Unix VR4 on the Amiga also do this? > My recollection of PDP-11 V7 Unix was that all system calls were invoked > via a trap instruction, with a word afterwords encoding which call was Perhaps that was the best way to do it on a PDP-11. What are some of the same folks doing now with Plan-9 on modern hardware? What other considerations are there? I looked up the assembler for the PDP-11, and it appears a TRAP is a bit slower than a JSR. Is there something to do with the state of the machine that is useful to OS functions when a TRAP is used instead of a JSR (for a PDP-11, or for a 680x0?)? > > Well, the ST thing has desensitized me, otherwise I'd fall over > > backwards laughing at this one. I guess this is well hidden by Mac > > C compilers etc. > > Like I say, isn't this how Unix does it? If it is, it is also well hidden by the system (as it should be) compilers. MS-DOS's aren't. In any case, I'm surprised. Is the Amiga OS the only rational one in this bunch, eh? > Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
jbickers@templar.actrix.gen.nz (John Bickers) (05/11/91)
Quoted from <1991May10.000135.7550@NCoast.ORG> by allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA): > As quoted from <3335.tnews@templar.actrix.gen.nz> by jbickers@templar.actrix.gen.nz (John Bickers): > | PClone, it appears to involve using fixed tables of vectors into the > | ROMs. > ??? ONE interrupt is used for system calls --- INT 21H (that, by the way, is Then I must be including things akin to our external libraries. I'm fairly sure that I've used a different number to do things with the display. 0x10...? > be dropped into place. Theoretically, you're not supposed to call the BIOS > directly, but we all know what MS-Doesn't is like.... Must be it. Now that I know so many microcomputer OSes do this sort of thing, I'm certainly interested in _why_ they do it. > Me: Brandon S. Allbery Ham: KB8JRR/AA 10m,6m,2m,220,440,1.2 -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
david@kessner.denver.co.us (David Kessner) (05/12/91)
In article <1991May10.003301.7881@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR/AA) writes: >Exactly. Take a look at the BIOS serial driver some time, and have a good >laugh. The other problem is that when BIOS or DOS did manage to do what you >wanted, it was dog slow doing it. I have. In fact, my serial routine C library was posted on comp.os.msdos.programmer. I wrote them simply because the BIOS was bad at that sort of thing. >That's not why the BIOS is part of MS-DOS, it's why MS-DOS is such a miserable >excuse for an OS. It's not the only reason MS-DOS is bad-- but just another in the long list. It just goes to show you that the very first design must be great otherwise everything else fails... In this case MS-DOS. But MS-DOS has other problems. >Me: Brandon S. Allbery Ham: KB8JRR/AA 10m,6m,2m,220,440,1.2 >Internet: allbery@NCoast.ORG (restricted HF at present) -- 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);
allbery@NCoast.ORG (Brandon S. Allbery KF8NH) (05/13/91)
As quoted from <3636.tnews@templar.actrix.gen.nz> by jbickers@templar.actrix.gen.nz (John Bickers): +--------------- | Quoted from <1991May10.000135.7550@NCoast.ORG> by allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA): | > As quoted from <3335.tnews@templar.actrix.gen.nz> by jbickers@templar.actrix.gen.nz (John Bickers): | > | PClone, it appears to involve using fixed tables of vectors into the | > | ROMs. | > | > ??? ONE interrupt is used for system calls --- INT 21H (that, by the way, is | | Then I must be including things akin to our external libraries. I'm | fairly sure that I've used a different number to do things with the | display. 0x10...? +--------------- That's the BIOS viden interrupt. As I said, you're "not supposed to do that". +--------------- | > be dropped into place. Theoretically, you're not supposed to call the BIOS | > directly, but we all know what MS-Doesn't is like.... | | Must be it. Now that I know so many microcomputer OSes do this sort | of thing, I'm certainly interested in _why_ they do it. +--------------- Do *which* sort of thing? One interrupt for the OS entry point? That's probably because it potentially has even more possible values than you have interrupts. Should MS-Doesn't ever break the 256-syscall barrier (this is, you understand, purely theoretical :-) , they can expand the system calls to use AX instead of AL (set AH=0 and you have the original set), thus 65536 system calls. That's probably the limit for DOS, though, until and unless they drop 8088 "real" mode. (Of course, AH is already used by some calls and programmers expect AH to be unused in others, so the All-Holy Compatibility with DOS 1.25 programs would be broken by this, so it'll never happen. :-) A better example: a 680x0 Unix I used which used one of the "trap" calls and placed the system call number in d0. Now, how many possible system calls is that? 4,294,967,296! The Unix Thought Police will get them for kernel bloat before they get anywhere near that many syscalls. :-) *How* many interrupts did you say you had, in comparison (even using the Mac-noid 1010/1011 trap)? ++Brandon -- Me: Brandon S. Allbery Ham: KF8NH on 10m,6m,2m,220,440,1.2 Internet: allbery@NCoast.ORG (restricted HF at present) Delphi: ALLBERY AMPR: kf8nh.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KF8NH @ WA8BXN.OH
allbery@NCoast.ORG (Brandon S. Allbery KF8NH) (05/13/91)
As quoted from <3626.tnews@templar.actrix.gen.nz> by jbickers@templar.actrix.gen.nz (John Bickers): +--------------- | Quoted from <1991May10.183627.29486@neon.Stanford.EDU> by torrie@cs.stanford.edu (Evan Torrie): | > jbickers@templar.actrix.gen.nz (John Bickers) writes: | > My recollection of PDP-11 V7 Unix was that all system calls were invoked | > via a trap instruction, with a word afterwords encoding which call was | | What other considerations are there? I looked up the assembler for | the PDP-11, and it appears a TRAP is a bit slower than a JSR. Is | there something to do with the state of the machine that is useful | to OS functions when a TRAP is used instead of a JSR (for a PDP-11, | or for a 680x0?)? +--------------- TRAP is slower, but JSR doesn't switch the processor to supervisor state. Yes, Unix runs the kernel in supervisor and user programs in user mode. Why do you think Unix programs core dump instead of guru-ing? +--------------- | > > Well, the ST thing has desensitized me, otherwise I'd fall over | > > backwards laughing at this one. I guess this is well hidden by Mac | > > C compilers etc. | > | > Like I say, isn't this how Unix does it? | | If it is, it is also well hidden by the system (as it should be) | compilers. MS-DOS's aren't. +--------------- Actually, 680x0 Unix usually puts the system call in d0. +--------------- | In any case, I'm surprised. Is the Amiga OS the only rational one | in this bunch, eh? +--------------- I don't consider running all programs in supervisor mode "rational". Does/did the Atari ST do this? The Mac does, and it shows. If you're going to multitask, one task shouldn't have the capability of crashing the whole system. That's the sort of thing 8088 unixes pull (because Intel left them no choice). I expect better of 680x0's.... ++Brandon -- Me: Brandon S. Allbery Ham: KF8NH on 10m,6m,2m,220,440,1.2 Internet: allbery@NCoast.ORG (restricted HF at present) Delphi: ALLBERY AMPR: kf8nh.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KF8NH @ WA8BXN.OH
tim@proton.amd.com (Tim Olson) (05/13/91)
In article <3626.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: | Quoted from <1991May10.183627.29486@neon.Stanford.EDU> by torrie@cs.stanford.edu (Evan Torrie): | > My recollection of PDP-11 V7 Unix was that all system calls were invoked | > via a trap instruction, with a word afterwords encoding which call was | | Perhaps that was the best way to do it on a PDP-11. What are some of | the same folks doing now with Plan-9 on modern hardware? The same thing. | What other considerations are there? I looked up the assembler for | the PDP-11, and it appears a TRAP is a bit slower than a JSR. Is | there something to do with the state of the machine that is useful | to OS functions when a TRAP is used instead of a JSR (for a PDP-11, | or for a 680x0?)? UNIX processes operate in two modes: user and kernel. When operating in user mode, the processes are prevented from performing certain CPU instructions which could crash the system. To switch to kernel mode, the CPU state must change from user to supervisor (to allow execution of priveledged instructions). a "JSR" instruction will not do this. Instead, some type of TRAP instruction is usually executed to affect this change. | In any case, I'm surprised. Is the Amiga OS the only rational one | in this bunch, eh? Are you sure that system calls to Amiga OS *don't* use some sort of TRAP instruction (usually hidden in a library routine). I seem to remember discussions of user-code trying to access the SR and failing on the 68010, which protects that register in user-mode. If so, then the code must be running in user-mode, and it must somehow switch to supervisor-mode at some point... -- -- Tim Olson Advanced Micro Devices (tim@amd.com)
torrie@cs.stanford.edu (Evan Torrie) (05/13/91)
allbery@NCoast.ORG (Brandon S. Allbery KF8NH) writes: >+--------------- >| In any case, I'm surprised. Is the Amiga OS the only rational one >| in this bunch, eh? >+--------------- >I don't consider running all programs in supervisor mode "rational". Does/did >the Atari ST do this? The Mac does, and it shows. Yes, although it's now changing in System 7.0 with VM. Now, processes run in user mode under VM. -- ------------------------------------------------------------------------------ Evan Torrie. Stanford University, Class of 199? torrie@cs.stanford.edu "And remember, whatever you do, DON'T MENTION THE WAR!"
peter@sugar.hackercorp.com (Peter da Silva) (05/13/91)
In article <1991May10.005049.8355@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR/AA) writes: > Peter, I fail to understand this. Where does MacOS fall short? Hi! The MacOS fails in not having a scheduler, to manage CPU time in an efficient and equitable manner. CPU time is another resource to be managed, and if the system software doesn't do so (which it doesn't on the Mac: each application is solely responsible for its use of CPU time and scheduling the next task to run) then it's not managing all the major system resources: disk space memory stream I/O devices CPU More recently, screen real estate is becoming an O/S resource... but not all systems have manageable screen hardware. They all have CPUs. The Mac system software has acceptable disk management, acceptbale memory management, acceptable stream device management, and phenomenal screen management. The system software, however, does not manage CPU time worth a damn. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
jbickers@templar.actrix.gen.nz (John Bickers) (05/13/91)
Quoted from <1991May12.180515.20191@NCoast.ORG> by allbery@NCoast.ORG (Brandon S. Allbery KF8NH): > Do *which* sort of thing? One interrupt for the OS entry point? _Any_ interrupts for an OS entry point. The library approach in the Amiga seems faster and more powerful to me. More natural. :) > That's probably because it potentially has even more possible values than you > have interrupts. Should MS-Doesn't ever break the 256-syscall barrier (this Yes, there's no doubt that the entry point can fan out ad infinitum once you're through it (like the ah could be set to something currently reserved, and some other register could be loaded with 16 bits of info, so it'd branch off ah, then branch off bx, or whatever. And so on...). The thing is, why do it like this, when you could jump straight (or almost straight, counting the little detour to give people an opportunity to intercept OS calls) into the OS? As for not using the other interrupts (0x10 for video, etc)... ha. :) > ++Brandon -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
jbickers@templar.actrix.gen.nz (John Bickers) (05/13/91)
Quoted from <1991May12.181436.20304@NCoast.ORG> by allbery@NCoast.ORG (Brandon S. Allbery KF8NH): > TRAP is slower, but JSR doesn't switch the processor to supervisor state. > Yes, Unix runs the kernel in supervisor and user programs in user mode. Why > do you think Unix programs core dump instead of guru-ing? I thought part of that had to do with using MMUs. Except for the fact that Amiga programs can blat into sensitive places (the Blitter, etc), why not control reads/writes with the MMU, and use the TRAPs for trapping what they're supposed to trap like GOMF does already? > | If it is, it is also well hidden by the system (as it should be) > | compilers. MS-DOS's aren't. > +--------------- > > Actually, 680x0 Unix usually puts the system call in d0. Nevertheless, hidden. I haven't noticed an intfoo() function in a Unix compiler yet. > | In any case, I'm surprised. Is the Amiga OS the only rational one > | in this bunch, eh? > I don't consider running all programs in supervisor mode "rational". Does/did > the Atari ST do this? The Mac does, and it shows. Does the Amiga? I'm as sure as I ever am about anything that it doesn't. > ++Brandon -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
jbickers@templar.actrix.gen.nz (John Bickers) (05/13/91)
Quoted from <1991May12.204607.22101@dvorak.amd.com> by tim@proton.amd.com (Tim Olson): > In article <3626.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: > | In any case, I'm surprised. Is the Amiga OS the only rational one > | in this bunch, eh? > > Are you sure that system calls to Amiga OS *don't* use some sort of > TRAP instruction (usually hidden in a library routine). I seem to Some must do so. This is somewhat different from being the interface to the OS, though. > -- Tim Olson -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
jerry@polygen.uucp (Jerry Shekhel) (05/13/91)
jbickers@templar.actrix.gen.nz (John Bickers) writes: > > > I thought IBM _took_ it from Microsoft because they thought Microsoft > was botching it. The IBM version coming out now is apparently way > ahead of the old one > Well, IBM and Microsoft did have some opposing views. Nevertheless, the IBM version about to be released was still mostly developed at MS. > > nothing that runs on an Intel CPU can be worthwhile). > I guess you think that SYSVR4 is not worthwhile? > > Does OS/2 multitask as nicely as Unix, have all those crontab and > uucp facilities, the user/group/world file protection stuff, etc? > It multitasks *BETTER* than UNIX. It has lightweight processes (threads), the concept of the foreground process, etc. It's a single-user OS, so there is no standard file protection stuff, but the HPFS supports extended file attributes which may be used by network systems to implement protection. Also, the file system in OS/2 is replaceable. > > Things like run-time libraries, etc? :) > It has dynamic-link libraries, more IPC mechanisms than UNIX ever dreamed of, a standard graphics library (GPI) that puts most others to shame, etc. >*** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** -- +-------------------+----------------------+---------------------------------+ | JERRY J. SHEKHEL | POLYGEN CORPORATION | When I was young, I had to walk | | Drummers do it... | Waltham, MA USA | to school and back every day -- | | ... In rhythm! | (617) 890-2175 | 20 miles, uphill both ways. | +-------------------+----------------------+---------------------------------+ | ...! [ princeton mit-eddie bu sunne ] !polygen!jerry | | jerry@polygen.com | +----------------------------------------------------------------------------+
peter@sugar.hackercorp.com (Peter da Silva) (05/14/91)
In article <1991May12.181436.20304@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KF8NH) writes: > If you're going to multitask, one task shouldn't have the capability of > crashing the whole system. That's the sort of thing 8088 unixes pull (because > Intel left them no choice). I expect better of 680x0's.... 68000 doesn't have an MMU, Brandon. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (05/14/91)
In article <3691.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: > Nevertheless, hidden. I haven't noticed an intfoo() function in > a Unix compiler yet. System V/386. The call is sysi86(). -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
allbery@NCoast.ORG (Brandon S. Allbery KF8NH) (05/14/91)
As quoted from <3686.tnews@templar.actrix.gen.nz> by jbickers@templar.actrix.gen.nz (John Bickers): +--------------- | Quoted from <1991May12.180515.20191@NCoast.ORG> by allbery@NCoast.ORG (Brandon S. Allbery KF8NH): | > Do *which* sort of thing? One interrupt for the OS entry point? | | _Any_ interrupts for an OS entry point. The library approach in the | Amiga seems faster and more powerful to me. More natural. :) +--------------- Gack. One typo in a header file and every program in existence breaks. And if you're going to switch from user to supervisor mode you end up doing a trap anyway (although I understand that the Amiga has the same no-protection braindamage as every other baby system; I give up, I'll just get a Unix box). ++Brandon -- Me: Brandon S. Allbery Ham: KF8NH on 10m,6m,2m,220,440,1.2 Internet: allbery@NCoast.ORG (restricted HF at present) Delphi: ALLBERY AMPR: kf8nh.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KF8NH @ WA8BXN.OH
allbery@NCoast.ORG (Brandon S. Allbery KF8NH) (05/14/91)
As quoted from <1991May12.210110.23707@neon.Stanford.EDU> by torrie@cs.stanford.edu (Evan Torrie): +--------------- | allbery@NCoast.ORG (Brandon S. Allbery KF8NH) writes: | >+--------------- | >| In any case, I'm surprised. Is the Amiga OS the only rational one | >| in this bunch, eh? | >+--------------- | | >I don't consider running all programs in supervisor mode "rational". Does/did | >the Atari ST do this? The Mac does, and it shows. | | Yes, although it's now changing in System 7.0 with VM. Now, processes | run in user mode under VM. +--------------- ...mainly because they have to, to get VM. Which won't prevent one program from smashing another unless they also add memory protection, which I rather suspect Apple didn't. ++Brandon -- Me: Brandon S. Allbery Ham: KF8NH on 10m,6m,2m,220,440,1.2 Internet: allbery@NCoast.ORG (restricted HF at present) Delphi: ALLBERY AMPR: kf8nh.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KF8NH @ WA8BXN.OH
allbery@NCoast.ORG (Brandon S. Allbery KF8NH) (05/14/91)
As quoted from <3691.tnews@templar.actrix.gen.nz> by jbickers@templar.actrix.gen.nz (John Bickers): +--------------- | Quoted from <1991May12.181436.20304@NCoast.ORG> by allbery@NCoast.ORG (Brandon S. Allbery KF8NH): | > TRAP is slower, but JSR doesn't switch the processor to supervisor state. | > Yes, Unix runs the kernel in supervisor and user programs in user mode. Why | > do you think Unix programs core dump instead of guru-ing? | | I thought part of that had to do with using MMUs. Except for the fact | that Amiga programs can blat into sensitive places (the Blitter, | etc), why not control reads/writes with the MMU, and use the TRAPs | for trapping what they're supposed to trap like GOMF does already? +--------------- They're both needed. If programs run in supervisor mode, they can defeat the MMU; if they run in user mode without MMU memory protection, they can still hode things up good for the system or other programs. +--------------- | > Actually, 680x0 Unix usually puts the system call in d0. | | Nevertheless, hidden. I haven't noticed an intfoo() function in | a Unix compiler yet. +--------------- Later MS-DOS C compilers come with real libraries, so int() isn't necessary for system calls. BIOS calls are another matter, but they're a prime symptom of brain-damage anyway. +--------------- | Does the Amiga? I'm as sure as I ever am about anything that it | doesn't. +--------------- So user processes run in user mode. But the system has to run in supervisor mode to manipulate the MMU... oh, that's right, the Amiga doesn't use the MMU. (Yes, I know about compatibility and the 68000.) So does the Amiga ever use supervisor mode? And if it does, how does it get there without a trap? And using a non-interrupt entry point runs the risk of somebody accidentally typo'ing a #define and making every program in existence break as a result. That's why people moved from JSR's to interrupts in the first place (I recall LDOS trumpeting their svc interface as an alternative to CALLs to invoke OS functions, waaaaay back when). ++Brandon -- Me: Brandon S. Allbery Ham: KF8NH on 10m,6m,2m,220,440,1.2 Internet: allbery@NCoast.ORG (restricted HF at present) Delphi: ALLBERY AMPR: kf8nh.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KF8NH @ WA8BXN.OH
allbery@NCoast.ORG (Brandon S. Allbery KF8NH) (05/14/91)
As quoted from <1991May13.003426.259@sugar.hackercorp.com> by peter@sugar.hackercorp.com (Peter da Silva): +--------------- | In article <1991May10.005049.8355@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KB8JRR/AA) writes: | > Peter, I fail to understand this. Where does MacOS fall short? | | The MacOS fails in not having a scheduler, to manage CPU time in an efficient +--------------- So in other words, a "real OS" by your definition must have multitasking. OS types would disagree, as I said in the message you're responding to. ++Brandon -- Me: Brandon S. Allbery Ham: KF8NH on 10m,6m,2m,220,440,1.2 Internet: allbery@NCoast.ORG (restricted HF at present) Delphi: ALLBERY AMPR: kf8nh.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery KF8NH @ WA8BXN.OH
peter@sugar.hackercorp.com (Peter da Silva) (05/14/91)
In article <1991May13.222839.8349@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KF8NH) writes: > (although I understand that the Amiga has the same no-protection > braindamage as every other baby system; I give up, I'll just get a Unix box). OK, Brandon. How would *you* build a consumer-priced machine in 1985 with memory protection. If you can, you'll be the first. The Amiga is basically the best machine that could have been built at that time for under $2000. Classifying hard design choices as "brain damage" is narrow minded and elitist. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (05/14/91)
In article <1991May13.224027.9132@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KF8NH) writes: > And using a non-interrupt entry point runs the risk of somebody accidentally > typo'ing a #define and making every program in existence break as a result. No more than you can with interrupts. What's the difference between: TRAP 2, 15 and: JSR -128(A6) You're jumping through a table in either case. You can get the magic numbers wrong in either case. And the results will be equally bad in either case. > That's why people moved from JSR's to interrupts in the first place (I recall > LDOS trumpeting their svc interface as an alternative to CALLs to invoke OS > functions, waaaaay back when). I remember LDOS. For the trash-80. No, people went to interrupts purely for the sake of memory protection. "typoing header files" is a pure red herring. > > ++Brandon > -- > Me: Brandon S. Allbery Ham: KF8NH on 10m,6m,2m,220,440,1.2 > Internet: allbery@NCoast.ORG (restricted HF at present) > Delphi: ALLBERY AMPR: kf8nh.AmPR.ORG [44.70.4.88] > uunet!usenet.ins.cwru.edu!ncoast!allbery KF8NH @ WA8BXN.OH -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (05/14/91)
In article <1991May13.224238.9296@NCoast.ORG> allbery@ncoast.ORG (Brandon S. Allbery KF8NH) writes: > So in other words, a "real OS" by your definition must have multitasking. No "quotes". No "real this". An operating system must manage all the resources of the machine. If it doesn't, it doesn't qualify as an operating system. The CPU is the most important resource of all. If the system software doesn't manage CPU time (which the Mac software doesn't, even under Multifinder) it is no more an operating system than MS-DOS. > OS types would disagree, as I said in the message you're responding to. No, OS types would agree. I would recommend Comer's "Xinu" book... the introduction contains one of the best definitions of an O/S I've ever seen. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
jbickers@templar.actrix.gen.nz (John Bickers) (05/15/91)
Quoted from <1991May13.170515.10233@sugar.hackercorp.com> by peter@sugar.hackercorp.com (Peter da Silva): > In article <3691.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: > > Nevertheless, hidden. I haven't noticed an intfoo() function in > > a Unix compiler yet. > > System V/386. The call is sysi86(). And on an Intel CPU! We all know the thing about dead bunnies and straws, eh? Is this one reason why? > Peter da Silva. `-_-' -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
elg@elgamy.RAIDERNET.COM (Eric Lee Green) (05/15/91)
From article <1991May13.224027.9132@NCoast.ORG>, by allbery@NCoast.ORG (Brandon S. Allbery KF8NH): > And using a non-interrupt entry point runs the risk of somebody accidentally > typo'ing a #define and making every program in existence break as a result. This is the second time I've seen this, and I don't understand it. First of all, the Amiga doesn't have any "system call" entry points. It has shared libraries, some of which are located on disk (e.g. the IEEE math simulation libraries for machines without a math chip) and some of which happen to be built-in to the ROM. The compilers generate calls to these libraries by using base pointer and offset (i.e., a jump table starts at the library base pointer). How could typo'ing a #define break every program in existence? When all those programs already have the correct offsets into the library jump table compiled into them? Oh, you mean if one of the OS people accidently insert a function into the jump table in the wrong place? But that'd be caught early in the test-debug cycle, long before the library was released to the general public. And nobody types in #defines for these offsets... they're automagically generated from the Commodore-supplied library description files, or linked in via a Commodore-supplied stub code library (amiga.lib). Not that it matters, anyhow. Even if you were using direct offsets (like some of the assembly language folks like to do), typo'ing would just mean that your program would crash (i.e., would call the wrong function). It wouldn't make any other program break. They already have those offsets compiled into them. So tell me, what exactly do you mean by "typo'ing a define and making every program in existence break"? Because I just don't see how it could happen, on the Amiga. -- Eric Lee Green (318) 984-1820 P.O. Box 92191 Lafayette, LA 70509 elg@elgamy.RAIDERNET.COM uunet!mjbtn!raider!elgamy!elg
jbickers@templar.actrix.gen.nz (John Bickers) (05/15/91)
Quoted from <1991May13.224027.9132@NCoast.ORG> by allbery@NCoast.ORG (Brandon S. Allbery KF8NH): > for system calls. BIOS calls are another matter, but they're a prime symptom What does BIOS stand for? > So user processes run in user mode. But the system has to run in supervisor > mode to manipulate the MMU... oh, that's right, the Amiga doesn't use the MMU. The "Amiga" does use the MMU (for things like Enforcer, etc). How does an Enforcer-like tool work under Unix? Or how do Unix source code debuggers work, for example? > And using a non-interrupt entry point runs the risk of somebody accidentally > typo'ing a #define and making every program in existence break as a result. Eh? Would you like to elaborate on this? Sounds like an incredibly stupid mistake to make, but you make it sound like it has happened in the past. Pre C= 64 days, maybe? > ++Brandon -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
david@kessner.denver.co.us (David Kessner) (05/15/91)
>> System V/386. The call is sysi86(). > > And on an Intel CPU! We all know the thing about dead bunnies and > straws, eh? Is this one reason why? > >> Peter da Silva. `-_-' >*** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** This, of course, has _NOTHING_ to do with the int86() function call. In reality, this function does "machine-specific" functions-- according to my System V 386 UNIX manual. This function is never used by any program that expects any portability amung platforms. What it is used for is determining several system configs (the amount of REAL RAM, FPU type, swap space), setting the system name (this can be done in other, better, ways), getting the hardware time of day, and several other 'system information' type things. It is plain that this function is not for calling UNIX system functions. In fact, the only thing remarkable about this function is the number '86' in the name-- for there is nothing that is inherent to the 80x86 CPU, and, while I don't have the manuals in front of me, I'd bet that Amiga UNIX has a very similar function-- sysm68k() perhapse. -- David Kessner - david@kessner.denver.co.us | 1135 Fairfax, Denver CO 80220 (303) 377-1801 (p.m.) | Reunite PANGEA! Why can't everyone have three or four line .sig's? |
kris@tpki.toppoint.de (Kristian Koehntopp) (05/15/91)
tim@proton.amd.com (Tim Olson) writes: > I seem to >remember discussions of user-code trying to access the SR and failing >on the 68010, which protects that register in user-mode. If so, then >the code must be running in user-mode, and it must somehow switch to >supervisor-mode at some point... No. AmigaOS is running in User Mode. You could probably fix this by hiding the switch to supervisor-mode in the library code. Kristian Kristian Koehntopp, Harmsstrasse 98, 2300 Kiel, +49 431 676689 (lisp 'kristian) NIL
jbickers@templar.actrix.gen.nz (John Bickers) (05/16/91)
Quoted from <1089@stewart.UUCP> by jerry@polygen.uucp (Jerry Shekhel): > > nothing that runs on an Intel CPU can be worthwhile). > I guess you think that SYSVR4 is not worthwhile? Not if it runs on an Intel CPU. In which case, as you imply, something designed specifically for the Intel could be better. > | JERRY J. SHEKHEL | POLYGEN CORPORATION | When I was young, I had to walk | -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Endless variations, make it all seem new" - Devo. ***
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (05/17/91)
In article <1991May12.180515.20191@NCoast.ORG> allbery@NCoast.ORG (Brandon S. Allbery KF8NH) writes: >As quoted from <3636.tnews@templar.actrix.gen.nz> by jbickers@templar.actrix.gen.nz (John Bickers): >+--------------- >| Quoted from <1991May10.000135.7550@NCoast.ORG> by allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA): >| > As quoted from <3335.tnews@templar.actrix.gen.nz> by jbickers@templar.actrix.gen.nz (John Bickers): >| > | PClone, it appears to involve using fixed tables of vectors into the >| > | ROMs. >| > >| > ??? ONE interrupt is used for system calls --- INT 21H (that, by the way, is >| >| Then I must be including things akin to our external libraries. I'm >| fairly sure that I've used a different number to do things with the >| display. 0x10...? >+--------------- > >That's the BIOS viden interrupt. As I said, you're "not supposed to do that". > >+--------------- >| > be dropped into place. Theoretically, you're not supposed to call the BIOS >| > directly, but we all know what MS-Doesn't is like.... >| >| Must be it. Now that I know so many microcomputer OSes do this sort >| of thing, I'm certainly interested in _why_ they do it. >+--------------- > >Do *which* sort of thing? One interrupt for the OS entry point? > >That's probably because it potentially has even more possible values than you >have interrupts. Should MS-Doesn't ever break the 256-syscall barrier (this >is, you understand, purely theoretical :-) , they can expand the system calls >to use AX instead of AL (set AH=0 and you have the original set), thus 65536 >system calls. That's probably the limit for DOS, though, until and unless >they drop 8088 "real" mode. (Of course, AH is already used by some calls and >programmers expect AH to be unused in others, so the All-Holy Compatibility >with DOS 1.25 programs would be broken by this, so it'll never happen. :-) > >A better example: a 680x0 Unix I used which used one of the "trap" calls and >placed the system call number in d0. Now, how many possible system calls is >that? 4,294,967,296! The Unix Thought Police will get them for kernel bloat >before they get anywhere near that many syscalls. :-) *How* many interrupts >did you say you had, in comparison (even using the Mac-noid 1010/1011 trap)? > >++Brandon >-- >Me: Brandon S. Allbery Ham: KF8NH on 10m,6m,2m,220,440,1.2 >Internet: allbery@NCoast.ORG (restricted HF at present) >Delphi: ALLBERY AMPR: kf8nh.AmPR.ORG [44.70.4.88] >uunet!usenet.ins.cwru.edu!ncoast!allbery KF8NH @ WA8BXN.OH In my own homebrew portable 68000 video game OS, I implement libraries similar to the Amiga's. I load the jump tables into very LOW memory, which allows me to use jmp (addr).w (absolute short), which is quite efficient, to access my libraries. -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
peter@sugar.hackercorp.com (Peter da Silva) (05/18/91)
In article <3760.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: > Quoted from <1089@stewart.UUCP> by jerry@polygen.uucp (Jerry Shekhel): > > I guess you think that SYSVR4 is not worthwhile? > Not if it runs on an Intel CPU. Who cares who makes the CPU? If you're programming in a real language and a real operating system the CPU is just another resource. What color it's painted is no more important than the company that manufactures the case. One big reason I got an Amiga is that it was the first personal computer that didn't force me into writing assembly. Now, people still do that, but that's their problem. They'll be first against the wall when the revolution comes. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (05/24/91)
In article <1991May18.105916.28180@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <3760.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: >> Quoted from <1089@stewart.UUCP> by jerry@polygen.uucp (Jerry Shekhel): >> > I guess you think that SYSVR4 is not worthwhile? > >> Not if it runs on an Intel CPU. > >Who cares who makes the CPU? If you're programming in a real language and a >real operating system the CPU is just another resource. What color it's painted >is no more important than the company that manufactures the case. > >One big reason I got an Amiga is that it was the first personal computer that >didn't force me into writing assembly. Now, people still do that, but that's >their problem. They'll be first against the wall when the revolution comes. >-- >Peter da Silva. `-_-' ><peter@sugar.hackercorp.com>. Assembler language programmers have been porting to other CPUs for years by writing translators that work on the source level. Ends up being as little work as porting a 'C' program (even between different compilers on the SAME machine). And it doesn't matter if you call BlitBitMap(), because you won't find it on any other platform... Nice try Peter :) -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
melling@cs.psu.edu (Michael D Mellinger) (05/25/91)
In article <mykes.2824@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes:
Assembler language programmers have been porting to other CPUs for years by writing
translators that work on the source level. Ends up being as little work as porting
a 'C' program (even between different compilers on the SAME machine). And it doesn't
matter if you call BlitBitMap(), because you won't find it on any other platform...
Hmmm. How about a few examples to support your statement that
translating assembler is about as much work as porting C? Me thinks
that you are incorrect.
-Mikepeter@sugar.hackercorp.com (Peter da Silva) (05/25/91)
In article <mykes.2824@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: > Assembler language programmers have been porting to other CPUs for > years by writing translators that work on the source level. Ends > up being as little work as porting a 'C' program (even between > different compilers on the SAME machine). I don't know. I generally port C programs by typing "cc". Of course I write to be portable in the first place. You can write non-portable code in any language... but why? > And it doesn't matter if > you call BlitBitMap(), because you won't find it on any other platform... I don't call BlitBitMap(). I call "DisplayImage" and hide the machine dependencies in there. Working the other way, I don't call "stat" I call "is_executable", and then the Amiga version of is_executable can call "Examine". And I'm not the only one. There's a huge library of good, portable code out there on the net so it must be possible. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (05/27/91)
In article <ia5Hrv9d@cs.psu.edu> melling@cs.psu.edu (Michael D Mellinger) writes: > >In article <mykes.2824@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: > > Assembler language programmers have been porting to other CPUs for years by writing > translators that work on the source level. Ends up being as little work as porting > a 'C' program (even between different compilers on the SAME machine). And it doesn't > matter if you call BlitBitMap(), because you won't find it on any other platform... > >Hmmm. How about a few examples to support your statement that >translating assembler is about as much work as porting C? Me thinks >that you are incorrect. > >-Mike Going back about 10 years... Most of the AtariSoft games for the PC were "compiled" from 6502 source code (C64, Apple II, Atari 800) into 8086 on the source code level. Rather than listing thousands of games that used similar techniques, I will just list a few from the last couple of years... These below were games originally written for the Apple IIGS and ported to other systems using source code translation: Zany Golf, Immortal, Ski or Die, and Budokan. I did Budokan, and did the translation from IBM assembly source to 68000 assembly by hand. While doing it, I saw that it was trivial to write an ARexx program to do 99% of the work. I would think that SED or AWK would be just as easy to do such a translator in. As far as porting 'C' goes, I am over 8 weeks porting a 'C' program from the Amiga to CDTV - using the same 'C' compiler even. And if you consider porting from Amiga, Windows, or Mac to XWindows, your 'C' code is going to be full of GUI specific code in the original version that will need a massive rewrite. I've been looking at the instruction sets for various risc processors, and writing a 68000 assembler to risc "compiler" is trivial. And 68000 assembly is so nice to write in, it is an excellent alternative to writing in 'C'. -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (05/27/91)
In article <1991May25.121511.24184@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <mykes.2824@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >> Assembler language programmers have been porting to other CPUs for >> years by writing translators that work on the source level. Ends >> up being as little work as porting a 'C' program (even between >> different compilers on the SAME machine). > >I don't know. I generally port C programs by typing "cc". Of course I >write to be portable in the first place. You can write non-portable code >in any language... but why? > >> And it doesn't matter if >> you call BlitBitMap(), because you won't find it on any other platform... > >I don't call BlitBitMap(). I call "DisplayImage" and hide the machine >dependencies in there. Working the other way, I don't call "stat" I >call "is_executable", and then the Amiga version of is_executable can >call "Examine". > >And I'm not the only one. There's a huge library of good, portable code >out there on the net so it must be possible. >-- >Peter da Silva. `-_-' ><peter@sugar.hackercorp.com>. Aren't you the same Peter da Silva who posted an article to comp.sys.amiga.programmer griping about how difficult it is to port between Manx and Lattice/SAS? :) Anyhow, even in your DisplayImage routine, you will call BlitBitMap() or whatever, and it will still need to be rewritten. -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
peter@sugar.hackercorp.com (Peter da Silva) (05/27/91)
In article <mykes.2906@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: > Aren't you the same Peter da Silva who posted an article to > comp.sys.amiga.programmer griping about how difficult it is to port > between Manx and Lattice/SAS? :) No, I'm the same Peter da Silva griping about people writing non-portable programs, so I have to do their work for them. In fact in the very message you're responding to (though you have "cleverly" refrained from quoting it) I point out that it's not the least bit difficult to write non-portable code in any language. The opposite... that it's even possible to write portable code in some languages... is not true. Ignoring people's points is not only rude, it's stupid. > Anyhow, even in your DisplayImage routine, you will call BlitBitMap() or > whatever, and it will still need to be rewritten. Yes. One O/S interface routine gets rewritten. The rest of the code just gets recompiled. It's a whole lot easier than rewriting all the code that uses BitBltBitMapLeftCornerPocketCueBall(). -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
mykes@amiga0.SF-Bay.ORG (Mike Schwartz) (05/28/91)
In article <1991May27.130057.27121@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: >In article <mykes.2906@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: >> Aren't you the same Peter da Silva who posted an article to >> comp.sys.amiga.programmer griping about how difficult it is to port >> between Manx and Lattice/SAS? :) > >No, I'm the same Peter da Silva griping about people writing non-portable >programs, so I have to do their work for them. In fact in the very message >you're responding to (though you have "cleverly" refrained from quoting it) >I point out that it's not the least bit difficult to write non-portable code >in any language. The opposite... that it's even possible to write portable >code in some languages... is not true. > Sorry, but I use Matt Dillon's DNews, which doesn't allow me to quote from one article while responding to another. Please trust that I had no intention of being clever :) Your article in csa.programmer shows clearly the problems of porting between two compilers - especially if it's not your code and if it wasn't crafted for portability. >Ignoring people's points is not only rude, it's stupid. > I have to work with other people's 'C' code far too often, as well. Unfortunately, everyone in the world isn't as "brilliant" as you or I when it comes to trying to write portable code. All the problems that you gripe about with the 'C' compilers being incompatible with eachother and the ANSII standard as well as how the language doesn't do a thing to promote portable programming practices (consider the use of the FAR, NEAR, HUGE, etc. keywords for PC compilers...). I think you are totally wrong to think that I ignored any of your points because you are feeding my "case" quite well. Do you think it's easy to port between 32-bit int compilers and 16-bit int compilers? I *know* that you're not supposed to use "int" declarations, but the stack frames are different as well. If you reply, please consider not only the "beautifully" crafted portable code that you currently write, but the code of someone else who you need to port. >> Anyhow, even in your DisplayImage routine, you will call BlitBitMap() or >> whatever, and it will still need to be rewritten. > >Yes. One O/S interface routine gets rewritten. The rest of the code just gets >recompiled. It's a whole lot easier than rewriting all the code that uses >BitBltBitMapLeftCornerPocketCueBall(). Your practice of writing "DisplayImage" the way you do is good for portability, but hurts your programs' performance, speed wise. I personally don't criticize you for choosing "portabilty" over speed, nor would I criticize someone for choosing speed over portability. >-- >Peter da Silva. `-_-' ><peter@sugar.hackercorp.com>. -- **************************************************** * I want games that look like Shadow of the Beast * * but play like Leisure Suit Larry. * ****************************************************
melling@cs.psu.edu (Michael D Mellinger) (05/29/91)
In article <mykes.2950@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes:
I have to work with other people's 'C' code far too often, as well. Unfortunately,
everyone in the world isn't as "brilliant" as you or I when it comes to trying to
write portable code. All the problems that you gripe about with the 'C' compilers
being incompatible with eachother and the ANSII standard as well as how the language
doesn't do a thing to promote portable programming practices (consider the use of
the FAR, NEAR, HUGE, etc. keywords for PC compilers...). I think you are totally wrong
to think that I ignored any of your points because you are feeding my "case" quite well.
Do you really think assembler is more portable? I won't argue that C
is the greatest language but it can be a lot more portable than
assembler. Just ftp to prep.ai.mit.edu and grab some GNU software and
see how many machines the software runs on(some of it is more portable
than others). If GNU Smalltalk or Bison were written in assembler,
how easy would it be to port them to a dozen different machines?
BTW, I just compile with the large memory model when I program on the
PC, and avoid the entire segmented problem of CPU's < 80386 machines.
Windows 32, and OS/2 2.0 will hopefully bring an end to this
brain-damaged segmented world.
Also, many software developers uses a "common core" (probably wrong
terminology) in developing their Mac and DOS software. I think it's
Aldus that claims that half of their code on the Mac and PC versions
of PageMaker is the same.
Do you think it's easy to port between 32-bit int compilers and 16-bit int compilers?
I *know* that you're not supposed to use "int" declarations, but the stack frames are
different as well. If you reply, please consider not only the "beautifully" crafted portable
code that you currently write, but the code of someone else who you need to port.
It's probably a real pain to port b/w 16 and 32 bit compilers(GNU
Emacs is a prime example of how impossible it can be). Fortunately,
even the toy computers are going to be true 32 bit soon. Hopefully,
the need to write machine dependent code will diminish as computers
become faster. Perhaps even a better language will supersede C as the
language of choice. I imagine Smalltalk on an HP Snake is faster than
assembler on a A500.
Your practice of writing "DisplayImage" the way you do is good for portability, but
hurts your programs' performance, speed wise. I personally don't criticize you for
choosing "portabilty" over speed, nor would I criticize someone for choosing speed
over portability.
How much does it hurt performance? Is the performance difference
perceivable? What happens when all the other computer companies move
on to the next generation of microprocessors that are 50+ mips(over
the next two years! -- that's over 50 times faster than 8MHz 68K)?
It's going to be hard to port CISC assembler programs to the new RISC
chips. On some computers, 98% of the software(excluding the OS) won't
take more than a weeks worth of work to get ported to a new CPU.
Software is the reason that the Mac and PC are popular. If your
computer doesn't have as much software, it's certainly not going to
help if half of it has to be rewritten.
-Mikepeter@sugar.hackercorp.com (Peter da Silva) (05/30/91)
In article <mykes.2950@amiga0.SF-Bay.ORG> mykes@amiga0.SF-Bay.ORG (Mike Schwartz) writes: > Sorry, but I use Matt Dillon's DNews, which doesn't allow me to quote from one > article while responding to another. I'm talking about the article you were responding to. > Please trust that I had no intention of > being clever :) Your article in csa.programmer shows clearly the problems of > porting between two compilers - especially if it's not your code and if it wasn't > crafted for portability. Eliding the word "especially", I'd agree. If the code wasn't written for portability you lose. If it was, C gives you a chance at writing code that will run after simply recompiling. Assembly doesn't. That's enough for me. > ...the language doesn't do a thing to promote portable programming practices Sure it does. It provides all the tools you need to hide implementation details in modules and opaque data structures, to separate system dependent modules from the portable code of the program. > (consider the use of the FAR, NEAR, HUGE, etc. keywords for PC compilers...). I write code on the 80286 every day at work, and I haven't used any of these keywords yet. Microsoft was completely wrong in implementing them in their compiler, and you can't lay the blame for that on the design of C. They are neither necessary nor desirable. > Do you think it's easy to port between 32-bit int compilers and 16-bit int > compilers? Yes. I do it all the time. I port code from 32-bit UNIX compilers to 16 bit UNIX compilers and Manx in both 16- and 32- bit mode. I have lots of UNIX utilities running on my machine... it's *easier* to do that than to port from Lattice to Manx in many cases, because UNIX programmers live in an environment where portability is encouraged. Too many Amiga programmers are ex-C=64 people. > Your practice of writing "DisplayImage" the way you do is good for > portability, but hurts your programs' performance, speed wise. Why? If the call overhead becomes a problem I can always inline it, either by converting it to a macro or by using one of the inlining preprocessors that are floating around. > I personally don't criticize you for choosing "portabilty" over speed, Take out those quotes. Portability is a real consideration, even within a single line of computers. > nor would I criticize someone for choosing speed over portability. I would, if they were expending energy on useless micro optimisation. You might need that extra millisecond in Blazemonger, but writing editors and the like in assembly is just asking for trouble. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
peter@sugar.hackercorp.com (Peter da Silva) (05/30/91)
In article <og9Hk52h@cs.psu.edu> melling@cs.psu.edu (Michael D Mellinger) writes: > Just ftp to prep.ai.mit.edu and grab some GNU software and > see how many machines the software runs on(some of it is more portable > than others). If GNU Smalltalk or Bison were written in assembler, > how easy would it be to port them to a dozen different machines? And keep in mind that most of the GNU software out there is extremely bad code from the point of view of portability. RMS has a great deal of disdain for 16 bit machines, and none of this code was written with any idea of ever porting it to anything less than a VAX. This is true of both RMS code, and the code of the other people in the FSF... the attitude has proven contagious. So when Mike here is pointing to the GNU code as "portable", keep in mind that what he's pointing to is not any sort of ideal. It's just typical C code. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.