🚀 go-pugleaf

In article <43004@bbn.COM> slackey@BBN.COM (Stan Lackey) writes:
[In a discussion of why IEEE floating point is expensive.]
>2. Rounding modes ... [had] been intended for range arithmetic.  Now, when I
>asked, lots of people knew what they were for, but no one [on comp.arch] had
>ever heard of them having ever been used.  Interesting how much hardware out
>there can do these operations that are so rarely used.  Kind of like the
>decimal string instruction set on the VAX, except that the VAX decimal
>strings are occasionally used.

There are a number of reasons that rounding modes are not used more.  And
unfortunately, the reasons feed each other.

- Programming languages historically do not support rounding modes.
- So, such use has been restricted generally to changing modes between program
  runs (for a warm fuzzy).
- So, specifying the rounding modes is part of device setup and not part of
  the operation instruction.
- So, changing the rounding mode is a difficult and time consuming operation.
- So, newer programming languages tend not to support rounding modes because
  the designers know users will not pay the cost.

We can break the cycle and provide good access to faster, more robust floating
point programs with the following efforts.

- Specify the rounding mode as part of the operation.  In essence, I am saying
  that rounding MODES are a self-defeating way of looking at the capability.
  We should have ADD-ROUNDING-UP and ADD-ROUNDING-DOWN, etc.
- Make these operations available in a programming language.
- Make these operations convenient in a programming language, e.g. operator
  overloading in Ada and C++.

The most difficult effort is the first, since it involves new hardware design.
The second two efforts would be fairly easy to implement under GNU's C++
compiler.

QUESTION: What effort would be required to retrofit an existing IEEE FP chip
to take the modes as part of the operation?

NOTE:  LANGUAGE DISCUSSIONS ARE NOT APPROPRIATE IN THIS NEWSGROUP.  IF YOU
WISH TO ADDRESS LANGUAGE ISSUES, POST A SEPARATE ARTICLE TO COMP.LANG.MISC.
-- 
  Lawrence Crowl		716-275-9499	University of Rochester
		      crowl@cs.rochester.edu	Computer Science Department
...!{allegra,decvax,rutgers}!rochester!crowl	Rochester, New York,  14627