Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!iuvax!pur-ee!a.cs.uiuc.edu!uxc.cso.uiuc.edu!uxe.cso.uiuc.edu!mcdonald From: mcdonald@uxe.cso.uiuc.edu Newsgroups: comp.arch Subject: Re: 88k trick for FP abs/neg Message-ID: <46500020@uxe.cso.uiuc.edu> Date: 7 Jul 88 13:52:00 GMT References: <2553@obiwan.mips.COM> Lines: 18 Nf-ID: #R:obiwan.mips.COM:2553:uxe.cso.uiuc.edu:46500020:000:772 Nf-From: uxe.cso.uiuc.edu!mcdonald Jul 7 08:52:00 1988 >In article <10136@tekecs.TEK.COM>, andrew@frip.gwd.tek.com (Andrew Klossner) >writes > > To clear up a question: on the 88k, floating point values are > > kept in general registers, so "abs" is done by ANDing to 0 the > > sign bit, "neg" is done by XORing the sign bit, and "mov" is > > done with conventional register-to-register move instructions. > >Oughtn't the operand be first tested for "IEEE-ness"? Specifically, >what if the operand of neg is a Signaling NaN? Oughtn't this cause >an invalid operation exception? Not if you expect to actually use or sell the resulting code. Testing for special cases slows code down horribly, ESPECIALLY in cases like this where otherwise it would take only 1 cycle or in that vicinity! It would be fine for debugging.