🚀 go-pugleaf

In article <1989Jul21.035825.27704@cs.rochester.edu> crowl@cs.rochester.edu (Lawrence Crowl) writes:
>
>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.

I don't see why this requires new hardware (hence the comp.arch follow
up). Consider a f88 module which define new operators +up +down etc.
Now one could write

		result = a +up b

and get the obvious result. The fact that +up actually uses some macro
(or system call) to condition the floating point mode shouldn't matter
(performance aside).

Any language which supports operator definitions and overloading (e.g.
Ada) should suffice.

If someone can explain why the hardware MUST be different, please do.
Keith H. Bierman      |*My thoughts are my own. Only my work belongs to Sun*
It's Not My Fault     |	Marketing Technical Specialist    ! kbierman@sun.com
I Voted for Bill &    |   Languages and Performance Tools. 
Opus  (* strange as it may seem, I do more engineering now     *)