Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!hp4nl!cwi.nl!dik
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.arch
Subject: Re: Changing IEEE rounding modes on the fly (was Re: somthing else)
Message-ID: <3755@charon.cwi.nl>
Date: 22 Jun 91 00:11:27 GMT
References: <1991Jun19.165150.2121@shinobu.sgi.com> <3751@charon.cwi.nl> <1991Jun21.160606.4247@oakhill.sps.mot.com>
Sender: news@cwi.nl
Organization: CWI, Amsterdam
Lines: 34

In article <1991Jun21.160606.4247@oakhill.sps.mot.com> marvin@bushwood.UUCP (Marvin Denman) writes:
 > In article <3751@charon.cwi.nl> dik@cwi.nl (Dik T. Winter) writes:
 > >In a previous posting I gave timings (from the manual) for the 88100, but
 > >apparently the fp pipelines must be flushed before a change to the fp
 > >control register is performed.  So I was wrong, and the 88100 does not
 > >meet the factor 3 criterion.  (Alas, this is not documented, and the flush
 > >must be programmed!)
 > 
 > This is not true for the 88100.  The floating point control register can be
 > changed on the fly with no problems.  The only flush necessary is before
 > reading or writing the status register.  The fp control register will only
 > affect instructions issued after it is modified because its information
 > is carried through the pipeline with it.  I'm sure because I designed it that
 > way.  
 > 
Thank you for the clarification.  That is exactly the way I want it.
Surprisingly I got a message from somebody of the 88open consortium that
stated the following:
 > Yes, the "official" way to flush the pipe is to do something like
 > a "tb1 0,#r0,xxx" instruction.  The software standards at the ABI
 > (SVR4.0) level require this to be done for the fpsetround(),
 > fpsetsticky(), and fpsetmask() routines.  The equivalent Object
 > Compatibility Standard (OCS, i.e. SVR3+POSIX+ANSI C) routines
 > contain the note that
 >         "For consistent and portable application behavior, an
 >      application should ensure that all previously initiated
 >      floating point instructions have completed prior to invoking
 >      these functions."
Now, how did this come into the ABI/OCS?  Why the required flush for
fpsetround() etc?  Is 88open assuming that the behaviour can not be
carried on in future implementations?
--
dik t. winter, cwi, amsterdam, nederland
dik@cwi.nl