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)