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.