brianw@microsoft.UUCP (Brian WILLOUGHBY) (01/03/91)
rhyde@ucrmath.ucr.edu (randy hyde) writes: >>> Do a DIR on a PC side by side a IIe doing CAT. > >Hardly a fair comparison of CPUs. All you're comparing is the speed of the >PC's BIOS (which is *horribly* slow) against the speed of the IIe's monitor >ROM. For applications like word processing, the 8088 can update the screen >about twice as fast as the //gs due to the more reasonable layout of the >display memory. Sounds like a double standard to me. Whenever someone defends the 65x02 for being slow because its C compilers are not as efficient as the more refined 80x86 compilers, the claim is made that you must evaluate the processor with the software that you will be using. I think that this applies with the BIOS vs. monitor ROM performance. In fact, I think that it is more important. The BIOS ROM is there for good, not many people attempt to rewrite it. But the Apple ][ will function with languages other than C. You can choose to develop on the 65x02 with a language other than C, but it is hard to work without the BIOS on a PC. Unless you want to worry about hardware incompatibility. It is easier to write directly to hardware on the Apple ][, because even the GS supports the earliest video modes. But the PC world is a mess of incompatible video generators which will not necessarily all function in a compatible way on every machine. >Of course, who uses an 8088 @ 4.77 Mhz anymore? If you don't use one any more, then how are you so sure of the relative performance of the 65816 vs. the 8088? If you are comparing the 65816 with the 386, then say so. >>>Also note that on 8088's it took (takes!) 4 clock cycles to access memory. > >One of the reasons the 286/386/486 chips run faster is that they access >memory in 3/2/1 cycles (depending on the processor). This, of course, is >on top of the fact that the new processors access 16/32 bits at a shot). > >*** randy Hyde Many of the 80x86 functions are still 8 bit. So are most of the I/O (peripheral) accesses. Also, character data is 8 bits by definition, so whenever you are working with text, you are working with 8 bits. Also, the 32 bit 80x86 processors have a curious flaw because they cannot work with both 16 and 32 bit instructions at the same time without increasing the code size with opcode override instructions. 8 bit accesses can be easily mixed because the 80286 instruction set allowed for this. These one byte prefixes seriously affect code size when mixing 16 and 32 bit data manipulations. Another caveat is that typical PC programs are written for the 8 bit 80x86, not many programs take advantage of the more expensive 32 bit machines, not even system software. Microsoft's OS/2 is actually a 16-bit operating system, purely for the advantage of being compatible with the 80286. The biggest crippling factor for the 80386 is its compatibility with the 80286. It even takes more cycles to execute 80286 instructions because it has to go out of the way to remain compatible. In summary, many of the problems which hold back the Apple ][ (backwards compatibility, etc.) also plague the PC. Fortunately for the PC world, there are a lot more people involved with overcoming these difficulties, so the average user doesn't have to think about it.