As I said already in my answer on Dan's mail the motion does not require hardware instructions with explicit rounding modes!
The motion requires arithmetic operations with the directed roundings as distinct operations. The rounding shall be an integral part of the operation.
These operations are the basic building blocks for interval arithmetic. For a quarter of a century these operations have not been available and this was felt as great deficiency for interval arithmetic. Of course, many tricks have been developed to code around this. But with an interval arithmetic standard these times definitively shall be left behind.
Best wishes
Ulrich
Am 13.05.2011 23:52, schrieb Ian McIntosh:
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
-- Karlsruher Institut für Technologie (KIT) Institut für Angewandte und Numerische Mathematik (IANM2) D-76128 Karlsruhe, Germany Prof. Ulrich Kulisch Telefon: +49 721 608-42680 Fax: +49 721 608-46679 E-Mail: ulrich.kulisch@xxxxxxx www.kit.edu www.math.kit.edu/ianm2/~kulisch/ KIT - Universität des Landes Baden-Württemberg und nationales Großforschungszentrum in der Helmholtz-Gemeinschaft