[rfa(arm)/rfc] Eliminate HOST_{FLOAT,DOUBLE,...}_FORMAT

[rfa(arm)/rfc] Eliminate HOST_{FLOAT,DOUBLE,...}_FORMAT

[Andrew Cagney]

Hello,

The attatched should catch a few eyebrows :-)

The existing GDB tries to be smart about converting host/target floating 
point values - if it thinks that host-float == target-float then it just 
does a move instead of a conversion.

This patch eliminates the short cut.  Instead the conversion is always 
routed through floatformat_{to,from}_doublest().  The most telling 
comment and the reason this will probably catch a few eyebrows can be 
found in i387-tdep.c:

!   /* Avoid call to floatformat_to_doublest if possible to preserve as
!      much information as possible.  */

To me, the comment doesn't make sense.  If sizeof (host long double) == 
size of (target long double) and information is still being lost then I 
think floatformat_* has a bug.

As a side effect it also cleans up the ARM target-float -> 
target->double conversion so that it is more portable (well I think it is).

Comments?  Approval for the ARM part?  I can/should separate the arm 
part out.

	Andrew

Re: [rfa(arm)/rfc] Eliminate HOST_{FLOAT,DOUBLE,...}_FORMAT

[Richard Earnshaw]

> Hello,
> 
> The attatched should catch a few eyebrows :-)
> 
> The existing GDB tries to be smart about converting host/target floating 
> point values - if it thinks that host-float == target-float then it just 
> does a move instead of a conversion.
> 
> This patch eliminates the short cut.  Instead the conversion is always 
> routed through floatformat_{to,from}_doublest().  The most telling 
> comment and the reason this will probably catch a few eyebrows can be 
> found in i387-tdep.c:
> 
> !   /* Avoid call to floatformat_to_doublest if possible to preserve as
> !      much information as possible.  */
> 
> To me, the comment doesn't make sense.  If sizeof (host long double) == 
> size of (target long double) and information is still being lost then I 
> think floatformat_* has a bug.
> 
> As a side effect it also cleans up the ARM target-float -> 
> target->double conversion so that it is more portable (well I think it is).
> 
> Comments?  Approval for the ARM part?  I can/should separate the arm 
> part out.

The ARM part looks like a good move to me (not that that need count for 
anything).  Overall, it all looks pretty sensible...

R.

Re: [rfa(arm)/rfc] Eliminate HOST_{FLOAT,DOUBLE,...}_FORMAT

[Andrew Cagney]

> The ARM part looks like a good move to me (not that that need count for 
> anything).  Overall, it all looks pretty sensible...


Ok.  I'll check the arm part in and then re-think the more general changes.

	Andrew

Re: [rfa(arm)/rfc] Eliminate HOST_{FLOAT,DOUBLE,...}_FORMAT

[Andrew Cagney]

> To me, the comment doesn't make sense.  If sizeof (host long double) == 
>> size of (target long double) and information is still being lost then I 
>> think floatformat_* has a bug.
> 
> 
> You could lose information if the original value's bit pattern is not
> a valid FP number.  Does floatformat_to_doublest handle these
> situations 110% correctly?  I see at least one FIXME comment in the
> code there.


At present this loss happens randomly depending on the host / target 
combination.  I would prefer GDB to at least have slightly more 
consistent behavour.

The next step would be to ramp up sim/common/sim-fpu.[hc] and use that 
for all FP caculations.

--

Anyway, looking at the code, yes there are several nasty errors:

   unsigned long mant;

should be ULONGEST so that it fits a 64 bit mantisa and:

       dto += ldexp ((double) mant, exponent - mant_bits);

unfortunatly doesn't take a ``long double''.

   /* Note that if exponent indicates a NaN, we can't really do anything 
useful
      (not knowing if the host has NaN's, or how to build one).  So it will
      end up as an infinity or something close; that is OK.  */


sigh.

	Andrew

Re: [rfa(arm)/rfc] Eliminate HOST_{FLOAT,DOUBLE,...}_FORMAT

[Eli Zaretskii]

> Date: Fri, 29 Jun 2001 11:17:23 -0400
> From: Andrew Cagney <ac131313@cygnus.com>
> > 
> > You could lose information if the original value's bit pattern is not
> > a valid FP number.  Does floatformat_to_doublest handle these
> > situations 110% correctly?  I see at least one FIXME comment in the
> > code there.
> 
> 
> At present this loss happens randomly depending on the host / target 
> combination.  I would prefer GDB to at least have slightly more 
> consistent behavour.

I agree with the goal, but I don't think we could explain to users of
native debuggers that they have NaN's being converted to Inf's in the
name of consistency ;-)

>  /* Note that if exponent indicates a NaN, we can't really do anything useful
>     (not knowing if the host has NaN's, or how to build one).  So it will
>     end up as an infinity or something close; that is OK.  */

Perhaps we should allow each native platform to provide a function
that produces a NaN for every FP type it supports?  Then utils.c won't
need to bother about doing things it doesn't know about.

Re: [rfa(arm)/rfc] Eliminate HOST_{FLOAT,DOUBLE,...}_FORMAT

[Andrew Cagney]

>  /* Note that if exponent indicates a NaN, we can't really do anything useful
>> (not knowing if the host has NaN's, or how to build one).  So it will
>> end up as an infinity or something close; that is OK.  */
> 
> 
> Perhaps we should allow each native platform to provide a function
> that produces a NaN for every FP type it supports?  Then utils.c won't
> need to bother about doing things it doesn't know about.


We've already (almost) got this.  sim/common/sim_fpu.[ch] portably 
implements exact IEEE floating point (it ``just'' lacks support for 80 
floats).

	Andrew