🚀 go-pugleaf

barnett@steinmetz.ge.com (Bruce Barnett) writes:
>I just did a benchmark on a Sun 4/110 without the FPA option.
...
>I assume this is due to:
>
>	Compiler always assumes the FPA chip is *ALWAYS* there.
>	FP calls are trapped by the kernal and the hardware is emulated
...
>******FLAME ON TO SUN*******
>You can't hide this sort of information, you twits.  I knew the machine
>would be slow for floating point, but if I knew it would make a PC look
>like a Cray in comparison, I would not have ordered this configuration....

I have no data on the marketing of this.  However, I'm sure they did it
for a good enigneering reason, which is:
	when you start a new architecture, don't go out of your way to
	have multiple flavors of code. You may get there anyway, as
	architectures evolve, but don't start that way.
Surely the past history of the major mess with 68K-floating-point object
code flavors (has a 68881, as an FPA, has nothing, must decide
dynamically....) or, to a lesser exent, with 386's (387 vs the Weitek
stuff) isn't something to repeat on purpose.

BTW: MIPSco does EXACTLY the same thing: there's one flavor of FP object
code, and you trap and emulate in the kernel. Believe me, it is not fun
trying to have compilers generate multiple flavors of code, and making it
all be both right, and optimally fast for each potential configuration, so
one flavor is a big help.

Of course, customers should always be warned that if they care about FP,
they should order an FP chip.  We include them by default, and people have
to explicitly order one without to get rid of it.

Anyway, this is probably an unfair ding on Sun: there is a good reason for it.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	{ames,decwrl,prls,pyramid}!mips!mash  OR  mash@mips.com
DDD:  	408-991-0253 or 408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086