[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference rusure::math

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 20: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.RTitleUserPersonal
Name
DateLines
1332.1It's faster?CHOSRV::YOUNGThe OOL's are not what they seem.Fri Nov 09 1990 19:509
    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