Path: utzoo!utgpu!watmath!clyde!att!pacbell!ames!amdcad!crackle!tim
From: tim@crackle.amd.com (Tim Olson)
Newsgroups: comp.arch
Subject: Re: Memory-mapped floating point (was Re: ZISC computers)
Message-ID: <23669@amdcad.AMD.COM>
Date: 2 Dec 88 18:07:54 GMT
References: <22115@sgi.SGI.COM> <278@antares.UUCP> <2958@ima.ima.isc.com> <8939@winchester.mips.COM> <1044@microsoft.UUCP> <9061@winchester.mips.COM> <23656@amdcad.AMD.COM> <9139@winchester.mips.COM>
Sender: news@amdcad.AMD.COM
Reply-To: tim@crackle.amd.com (Tim Olson)
Organization: Advanced Micro Devices, Inc. Sunnyvale CA
Lines: 26
Summary:
Expires:
Sender:
Followup-To:

In article <9139@winchester.mips.COM> mash@mips.COM (John Mashey) writes:
| Given the same assumptions (variables already in registers,
| and we have enough of them to make that happen occasionally also),
| but giving 29K benefit of the doubt on the constants, we end up with:
| 	DP +	DP *	SP +	SP *
|   R3000 2	5	2	4
|   29K	10	10	7	7
| This, of course, is one of the most favorable-to-MIPS comparisons,
| which is why I didn't use it in the first case.  Needless to say,
| 29K code generators will want to allocate FP variables to the FP unit
| whenever possible, to avoid this kind of hit.

Of course.  I was trying to make a fair comparison.  Our local scalar
stack *is* in the local register file, which is what we were comparing. 
If you want to compare operations where the operands are already in the
FP registers, then:

 	DP +	DP *	SP +	SP *
   R3000 2	5	2	4
   29K	 5	5	5	5

(Assuming non-pipelined '027 operation).

	-- Tim Olson
	Advanced Micro Devices
	(tim@crackle.amd.com)