🚀 go-pugleaf

> >  > 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