[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| Title: | Mathematics at DEC |
|
| Moderator: | RUSURE::EDP |
|
| Created: | Mon Feb 03 1986 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 2083 |
| Total number of notes: | 14613 |
1332.0. "Why this result on CVT overflow ?" by EAGLE1::BEST (R D Best, sys arch, I/O) Thu Nov 08 1990 17:19
Some of the people who work on RTLs or instruction emulation software
may know about this.
In several of our processor SRMs, the 'convert floating to integer'
operation is defined to yield the low order bits of the true result, if
an overflow occurs. (See, for example, p. 3-128 of DEC STD 32, rev. J,
item 3)
What is the utility of this definition ? Or is it useful ?
What would happen if the result on some new architecture were made
unpredictable, or defined some other way ?
I guess it's not that hard to do, since the exponent for our floating
point representations is 2.
| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1332.1 | It's faster? | CHOSRV::YOUNG | The OOL's are not what they seem. | Fri Nov 09 1990 16:50 | 9 |
| It is probably just for the convenience of the processor implementors.
To me (NOT a CPU Architect), the most straightforward way to convert
floating-to-integer is to do a bit move from the mantissa, using the
exponent as an index into it. This should allow you to do overflow
(ie. range) checking in parallel and then not bother to clear the
output if it IS an overflow.
-- Barry
|