Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!munnari.oz.au!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.arch
Subject: Re: Implementing Interval Arithmetic with IEEE rounding modes
Message-ID: <6389@goanna.cs.rmit.oz.au>
Date: 19 Jun 91 10:58:57 GMT
References: <399@validgh.com>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 24

> 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.  

It sounds to me as though there is some scope for compiler research
here:  if I have something like
	X = X - Y
	Z = Z + W
then you can halve the number of mode switches in a fairly obvious
way.  This should pay off spectacularly for vector operations:
	X(1:N) = X(1:N) - Y(1:N)
only needs one mode switch (provided the compiler keeps track of the
mode setting at the beginning of each basic block).

I think it would be instructive to look at the level 1 BLAS and a few
subroutines from LINPACK to see whether a plausible optimisation level
applied to Fortran-90 versions could reduce the cost of mode switching.
What exactly do the interval arithmetic operations look like when built
on top of IEEE 754 primitives?


-- 
Q:  What should I know about quicksort?   A:  That it is *slow*.
Q:  When should I use it?  A:  When you have only 256 words of main storage.