Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!rice!hsdndev!husc6!genrad!decvax.dec.com!abyss.zk3.dec.com!kenton
From: kenton@abyss.zk3.dec.com (Jeff Kenton OSG/UEG)
Newsgroups: comp.sys.m88k
Subject: Re: Is the FPSR interlocked with the FPU pipe?
Message-ID: <1991Apr25.132059.23889@decvax.dec.com>
Date: 25 Apr 91 13:20:59 GMT
References: <1991Apr24.200412.7483@eagle.lerc.nasa.gov>
Sender: usenet@decvax.dec.com (Usenet News System)
Reply-To: kenton@abyss.zk3.dec.com (Jeff Kenton OSG/UEG)
Distribution: na
Organization: Digital Equipment Corporation - Nashua, NH
Lines: 31
Nntp-Posting-Host: abyss.zk3.dec.com

In article <1991Apr24.200412.7483@eagle.lerc.nasa.gov>,
fsset@bach.lerc.nasa.gov (Scott E. Townsend) writes:
|> This sounds too strange to be true, but is it possible for the FPSR to
|> return 'too fresh' data?  Or put another way, why should the following two
|> code fragments behave differently?
|> 
|> #1
|> 	fdiv.ddd r8,r2,r4
|> 	fldcr	 r12,fcr62	; fcr62 == FPSR
|> 	bb1	 0,r12,@L21	; AFINX bit
|> 
|> #2
|>         fdiv.ddd r8,r2,r4
|> 	tb1	 0,r0,0		; trap not taken, but system 'synced'
|>         fldcr    r12,fcr62
|>         bb1      0,r12,@L21
|> 
|> This code is buried a bit, so I don't have the exact different results,
|> but the behaviour _is_ different.  Is it possible the fldcr gets whatever
|> is 'current' rather than the result of the fdiv? (which will take a while)
|> 

Yes -- that is exactly what's happening.  As a matter of fact, most of the
status bits in the FPSR are set by exception handlers, not hardware.  The
imprecise exceptions (AFINX is one) are not detected before the next cycle,
which is what your example #1 is expecting.

-----------------------------------------------------------------------------
==	jeff kenton		Consulting at kenton@decvax.dec.com        ==
==	(617) 894-4508			(603) 881-0011			   ==
-----------------------------------------------------------------------------