I vote NO on Motion P1788/M0024.02:RoundedOperations

[Ian McIntosh <ianm@xxxxxxxxxx>]

I vote NO on motion 24.

I agree high performance is an important goal, which is why I suggested allowing one of the bounds to be negated to avoid rounding mode changes.

It isn't feasible to require hardware instructions with explicit rounding modes though:
1. As Dan said, it rules out a conforming implementation on most existing architectures, and getting implementations on them is an essential goal.
2. Many instruction set architectures just don't have enough bits in the instructions to add a rounding mode field, forcing them into a CISC variable length instruction approach.
3. Even where a new rounding mode field can be added, it delays implementation 1/4 to 1/2 decade.
4. The definition of "in hardware" is fuzzy:
a. Does it have to be fast?
b. Can the instruction trap to an operating system emulation routine? There are current "hardware" instructions doing that.
c. Can it be done by firmware with no special hardware to implement it? There are current "hardware" instructions doing that.
d. Can some members of an architecture family have explicit rounding instructions, while others don't?
If a software vendor develops a 1788 implementation for an architecture family for which one CPU model has instructions with explicit rounding modes, but also provides support for older CPUs which do not, can it claim conformance or not?
e. If it's slower to use new instructions than not to, is the implementation required to use them?
5. It doesn't solve other performance issues; for example, at the same point that you need to set the rounding mode you may also have to suppress trapping on overflows.
6. 754 doesn't require any hardware. It can be done entirely in software. Programming languages don't require specific hardware.
7. It's up to the hardware implementers to decide what their market needs and wants, and how best to satisfy their customers.

Not really part of this motion: One implication of defining level 1 first without considering other levels is that we've made other decisions that likely require special hardware to be fast. If we care about performance we should think carefully about them once we get to those levels and understand their costs.

- Ian McIntosh IBM Canada Lab Compiler Back End Support and Development


Dan Zuras Intervals ---05/13/2011 10:44:49 AM--- Folks, I vote NO on Prof Kulish's motion to require a

From:	Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
To:	Ian McIntosh/Toronto/IBM@IBMCA
Date:	05/13/2011 10:44 AM
Subject:	I vote NO on Motion P1788/M0024.02:RoundedOperations

---

		 Folks,

		 I vote NO on Prof Kulish's motion to require a
		 conforming implementation to provide explicit
		 hardware instructions for directed rounding
		 operations.

		 There are many reasons.

		 We are an arithmetic standards body not a hardware
		 standards body.  It is not our place to dictate
		 how our implementers shall design their hardware.

		 Also, to do so would eliminate nearly all existing
		 hardware from any possibility of conforming to our
		 standard.  This would severely limit acceptance of
		 1788 in the market.

		 We have already gone out of our way to provide for
		 the flexibility necessary to eliminate the need for
		 frequent changes in rounding mode.  For example,
		 permitting representations of the form [-inf,sup]
		 rather than [inf,sup].  Thus, much of the performance
		 improvement Prof Kulish seeks can already be had on
		 existing hardware without new instructions.

		 All of that having been said, what Prof Kulish
		 suggests would clearly be a good idea for any
		 architecture that permits it.  Indeed, some already
		 have such instructions.  But it is up to the hardware
		 designers to decide what is best for their customers,
		 not us.

		 Perhaps someday hardware designers will include even
		 more useful instructions than explicit directed
		 rounding instructions.  If 1788 is successful we may
		 even see explicit interval registers with explicit
		 interval add, subtract, et al.

		 But not today.

		 And not by our demanding it of them.

		 That's how I feel anyway.

		 Yours,

		 		 		 		 Dan