🚀 go-pugleaf

Dik Winter observes that dynamic rounding modes (that can be varied
at run time) don't have to be quite so expensive on pipelined systems
if the control modes can be written without emptying the pipeline.

If you don't have such a feature then the cost of interval addition
is dominated by the cost of emptying the pipe and the cost of the two
additions is minor.  

However several existing instruction set architectures, including SPARC for
which I can take some blame, combine too much stuff into the floating-point
control/status register, so that it's unrealistic to expect
the hardware to keep track of changes to the rounding modes only... so
the pipeline will necessarily have to be drained.  In addition the SPARC
architecture specifies that changes to the floating-point control/status
register don't have to take effect for a couple of cycles after the load,
with no hardware interlock support,
so you have to force some nop dead time before you can initiate a rounded add.
Other RISC architectures may be similar.  The common CISC architectures
have separate control and status registers, and at least the microcoded
implementations of floating-point +-*/ are so slow that control register
manipulations are of no consequence.   This was the environment anticipated
when IEEE 754 was being drafted, leading to its expectation (though not a
requirement) that rounding modes be implemented dynamically in hardware.

So for satisfactory interval arithmetic performance, I've come to the
conclusion that one of the following paths must be followed:

1) separate control and status registers and appropriate hardware support

2) additional instructions with static rounding modes built in -
	+-*/ rounding to +infinity
	+-*/ rounding to -infinity

3) microprogrammed instructions, perhaps in a coprocessor, to perform
	interval operations directly 
-- 

David Hough

dgh@validgh.com		uunet!validgh!dgh	na.hough@na-net.ornl.gov