Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ucsd!rutgers!apple!oliveb!pyramid!prls!mips!mash
From: mash@mips.COM (John Mashey)
Newsgroups: comp.arch
Subject: Re: RISC as a "technology window"?
Message-ID: <15961@winchester.mips.COM>
Date: 25 Mar 89 23:42:17 GMT
References: <63866@pyramid.pyramid.com>
Reply-To: mash@mips.COM (John Mashey)
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 58

In article <63866@pyramid.pyramid.com> wendyt@pyrps5.pyramid.com (Wendy Thrash) writes:
>In article <717@m3.mfci.UUCP> rodman@mfci.UUCP (Paul Rodman) writes:
>There's one large hidden cost here that people never seem to acknowledge:
>If you sell even one system without floating-point hardware, some poor
>programmer (or group) will spend the next twenty years (your product should
>last so long) supporting floating-point operations on systems without the
>floating-point hardware.

>Hardware costs don't factor in the cost of phone calls from customers
>complaining about slow (trapped and simulated) software floating point or
>slow (-fswitch) hardware floating point or outmoded (someone wrote the
>microcode years ago, and nobody understands it well enough to fix it now)
>firmware floating point, or the costs of maintaining separate versions of
>libraries, additional code in compilers, etc. (for compiler-generated
>software floating point).

>It's like the guy says on the commercial: You can pay me now (for extra
>hardware) or pay me later (for extra support).  If you sell enough systems
>at the lower price to cover the hidden costs, then you've made a good
>decision, but do remember that the costs are merely hidden, not nonexistent.

These comments are well-taken, i.e., worry about the cost of the entire
system and its support.

Fortunately, this is much less of an issue than it used to be, simply
because VLSI FPUs now have good performance, at low cost.
It has never been really that much of an issue in the larger-systems arena,
in that the FP was a small part of the enitre product.
It used to be a serious issue in the small-systems arena, especially when:
	a) The integer unit was cheap.
	b) The VLSI FPU was either nonexistent [like for the 68010], or
	"slow" (i.e., relative to the integer unit's performance).
	c) A fast FPU was a whole logic board.
In this case, the difference between b) and c) was a lot of $$$ as a fraction
of the entire prodduct.

Both Sun and MIPS came to the same conclusion, albeit from different directions,
for their RISC products: generate exactly 1 form of FP code,
and if no FPU is present, emulate it in the kernel.  Given that FP chips
are reasonably inexpensive, most people just buy them, but if somebody
really wants to save money, where they're deploying a bunch of machines in
a commercial application that doesn't use FP, they can.

This leads to an interesting question: the 80387 and Weitek (1167? whatever it
is that you use to replace a 387 at higher speed) are not directly
binary-compatible?  Can anybody out there give a comprehensive tutorial
on:
	a) How 386 UNIX systems deal with this?
	b) What compilers support both flavors?
	c) What sorts of software packages handle both?
Are there two separate versions?  Or is there code that checks at run-time
for the presence of the FPU?  What is typically done when there is no FPU at
all?
-- 
-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