This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: exotic floating point formats test
On Fri, Mar 09, 2001 at 08:05:37PM -0500, Michael Meissner wrote:
> On Fri, Mar 09, 2001 at 02:58:15PM -0800, Zack Weinberg wrote:
> > On Fri, Mar 09, 2001 at 05:34:54PM -0500, David Edelsohn wrote:
> > > >>>>> "Zack Weinberg" writes:
> > Aha, this is what GCC means by IBM_FLOAT_FORMAT. Interesting how the
> > latter six bytes have all been multiplied by two (rounding?) - and
> > then the EBCDIC conversion changes the letter values around; 0x82
> > isn't ascii anything...
>
> IIRC, IBM floating point's exponent is expressed in terms of
> hexidecimal digits and not in terms of binary digits, which IEEE &
> VAX use (ie, FLT_RADIX is 16, not 2). There is also no hidden bit
> (and no NaNs or Infinities). The use of hexidecimal digits means on
> average you loose 2-3 bits of precision. Also, unlike the IEEE
> format, the float format is exactly the same as the double format,
> with the additional 32 bits being all mantissa.
Interesting. Thanks for the info.
> > If you have time and patience, could you see if you can come up with a
> > floating-point literal that translates to eight printable characters?
> > (*not* @@ABCDEF) This is eventually going to wind up as autoconf doing
> > greps on an object file, and I'd really rather not deal with
> > unprintable bytes in the middle of the pattern. Finding one is not
> > hard if you have a compiler that supports C99 hexadecimal float
> > literals (I need it in decimal at the end, though).
>
> Note that there still is a translation from the C99 hexadecimal
> float literals into IBM floating point.
The numeric value of the float literal is pretty much irrelevant. All
I need is something that generates an identifiable string in an object
file.
zw