Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!oxy!rafetmad From: rafetmad@oxy.edu (David Ronald Giller) Newsgroups: comp.windows.ms.programmer Subject: 486SX Message-ID: <165722@tiger.oxy.edu> Date: 6 May 91 06:31:54 GMT Organization: Occidental College, Los Angeles, CA 90041 Lines: 67 > > > 486SX == 486 w/o "built in" coprocessor > > > > 486SX == 386 ? >No, no. The 486 is a complex 64-bit RISC CPU (very similar to the i860) which >is microcoded to do 386 instructions. The hardware is totally different. What? 64-bit? RISC? Not last time I looked. The 80x86 family is about as far from the RISC concept as I can conceive. The 486 is basically just a debugged (we hope), optimized version of the 386. With a debugged (we hope) optimized version of the 387 on board. The fact that the two are in the same physical package (on the same wafer) is what gives the 486 its great floating- point power and speed. How could a processor that is coded to emulate another possibly ever execute instructions in a single cycly (as the 486 is wont to do)? The 486 is really what the 386 should have been. >The 486sx seems to be here for marketing reasons, now that AMD has started >shipping their 386 clone CPUs. I think that the 486sx will perform like a 486 >of equal speed. The question is, since it lacks the internal FPU, if there will >be a 487sx. If yes, the 487sx/486sx combination is likely to perform >drastically worse than a 486. If things at Intel haven't changed, shouldn't we expect the 486sx to be a 16- bit-bussed version of the 486? The 8086/8088 and 386/386sx have been this route. A marketing reason indeed, to be able to say 'Almost the same per- formance, at a greatly reduced price!!!'. But for I/O intensive purposes (on a 32-bit bus) this is a big mistake. Indeed, if there were a 486sx/487sx combo, I can't see its marketplace. Surely this combo will be more expensive than a 386/387, and will offer little if any performance benefit. The 386sx really lost a bit of its punch, so much so that it paled when compared to a 286 at the same speed (talking in 16-bit mode, now). >if you are not interested in FPUs, the 486sx may be worth a look. Anyway, there >seems to be a need for fast CPUs for doing such weird things as Windows. Yes, there seems to be little need for an FPU under Windows right now (unless your applications use them intensively). If, however, Windows gains display Postscript, (which, IMHO would be a positive boon, even if it is unlikely), it would arguably NEED an FPU. >Clue: If Windows runs much to slow on a 286, and does not make sense to run on >a 386sx with less than 2 MB, why are we still using 16bit compilers? Why would we want to forsake the large Windows + 286 market? Windows will, unless the horrible mistake of making it a 32-bit OS is made, continue to be the environment of choice for these very popular workhorses. Writing a 32-bit only app under Windows is really an inappropriate. Something this large (and correspondingly expensive) should be left to OS/2. And don't tell me about OS upgrade costs; this is no longer an issue. New buyers would do well to go for OS/2; it's cheaper than DOS+Windows, faster (my experiense is that it is very noticeably faster), and DEFINITELY more stable. THIS is the environment for apps that require 32-bit operation. (I don't really want to turn this into another Windows vs. OS/2 war, but the facts are there.) >Anyone got his hands on the new Watcom 386 C Compiler special Windows Version? See my above argument; however, I hear it's a good package. >--- -Dave David Giller ----- (rafetmad@oxy.edu) or (dgiller@oxy.edu) ------------ Box 134 "Some of us wake up -- others roll over." Occidental College "It's easy to deceive a child." -- John Lydon Los Angeles, CA 90041