Further floating-point-emulator cleanups

[Zack Weinberg]

On Fri, Mar 22, 2002 at 01:56:04PM -0800, Richard Henderson wrote:
> On Fri, Mar 22, 2002 at 01:09:33PM -0800, Zack Weinberg wrote:
> > [...]
> > which is, IMO, a fair bit easier to comprehend, and is calculated
> > directly from the target parameter instead of via a series of
> > #ifdef-selected magic numbers.
> 
> Sounds good.

Checked in with that change, after repeating the C testsuite.

> > I agree that this is broken, but this patch is already too big.  I'd
> > prefer to fix both these issues in a separate patch; they don't make
> > anything more broken than it already was.
> 
> Ok then.

I thought about it a bit more over lunch.  REAL_VALUE_TO_TARGET_* are
used by code which needs to access the bit pattern of a floating point
constant as integer(s), for whatever reason (there are several).  Most
of the code assumes that it's going to get the result in 32-bit
chunks.  I don't think we have a typedef guaranteed to be 32 bits on
the host side (correct me if I'm wrong); but it shouldn't be hard to
add one, modulo the PDP10 folks.  Changing the interface to use
HOST_WIDE_INT and fill it up strikes me as a bad idea -- all the
callers would need to change their printf formats depending on the
width of HOST_WIDE_INT.  (Except that's what H_W_I_PRINT_* are for,
tho I'm not sure we have them in enough varieties.)

The places that want to convert to target format and then break it up
into sign/exp/mantissa bitfields, they should have their union defined
for them in a convenient global location such as real.h.

Thoughts?

zw