[Cfp-interest] functions: thoughts about conversions - version 0

[David Hough CFP]

Another way to deal with the number of 
convertToInteger FP to integer type conversion functions:


Add four functions for each FP type:

 maxint  from_FP  ( FP x, int round, int bits );
 maxint  from_FP_x( FP x, int round, int bits );
umaxint ufrom_FP  ( FP x, int round, int bits );
umaxint ufrom_FP_x( FP x, int round, int bits );

These functions return the maximum length signed or unsigned
integer type in an implementation.

The FP functions do not signal the inexact exception.
The FPx functions do signal the inexact exception when an otherwise
valid result differs in value from x.

While an implementation shall provide these functions, it should also
define macros that correspond to functions that are implemented
efficiently in hardware.    Although optimizing compilers might recognize
some invocations of these functions and convert them into efficient
hardware sequences, programmers can help make their intents clear
by using such macros.

Thus if "(int)x" happens to signal invalid or integer overflow
correctly for x of type double, without signaling inexact, then

#define from_double_trunc_int(x) ((int)(x))

would be a handy macro in lieu of

#define from_double_trunc_int(x) ((int)from_FP(x,trunc,8*sizeof(int)))

which would be guaranteed to handle exceptions correctly in all conforming
implementations.

In contrast,

#define ufrom_Float32x_floor_16(x) ((int16)ufrom_Float32x_x(x,floor,16))

might be a handy macro for conversions from _Float32x to 16-bit unsigned
integers signaling inexact, but it is less likely to have an efficient
hardware implementation.

(Should we list all the macro names and require that they be defined?
All 4 x 5 macros per {FP type, int type} pair?   Probably not, although
macros are less of a burden than functions.   Or should we define the form of
the macro names and recommend that an implementation define only those
that have an efficient hardware implementation?).