NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/arch/9441

Internet Message Format | 1992-09-15 | 1.8 KB

Path: sparky!uunet!elroy.jpl.nasa.gov!usc!news!nic.cerf.net!davsmith
From: [e-mail] (David Smith)
Newsgroups: comp.arch
Subject: Re: SPARC Floating Point Query
Message-ID: <[e-mail]>
Date: 16 Sep 92 03:06:02 GMT
References: <[e-mail]>
Sender: [e-mail]
Organization: CERFnet
Lines: 25
Nntp-Posting-Host: nic.cerf.net

In article <[e-mail]> [e-mail] (J P Fitch) writes:
>Can anyone throw any light on the following aspect of the SPARC?
>
>We have a trivial C program which calls double divide.  Compiled to
>assembler it creates what one might expect.  When we assemble the code
>and look with adb we find that the assembler has created an additional
>instruction, a fmovs, immediately after that fdivd.  We cannot find
>anything in the documentation we have been able to find to explain
>why, or what it is trying to avoid.

The nearest I was ever able to figure out, that fmovs (basically an FP
no-op) is there to force the IU to take the FP exception that the fdivd
might have caused.  You see, in the SPARC architecture FP traps are
only handled by the IU when it issues an FP instruction to the FPU.
(SPARC Architecture manual, Rev A, page 53) Hence, the floating point
no-op to force the exception to be taken immediately so that you have
some clue about when the exception happens.  Unfortunately that little
kludge assumes that the exception will happen before the FP no-op is
issued.  This is true only if the FP queue is one deep or the FPU is
_very_ fast.  More recent SPARC implementations have FP queues deeper
than one.  I do not know how SUN is handling this with their compilers
for the Viking chip, for example.
--
David L. Smith
[e-mail] or [e-mail]