Re: [Dwarf-Discuss] [EXTERNAL] - RE: Multiple floating point types with the same size but different encodings
>
> For ATE codes, the problem is with standardization if we wanted
> to standardize it in some way for DWARF6.
> The current DW_ATE_{,complex_}float is way too unspecific and historically
> can be about various formats.
> So, we'd need something like DW_ATE_{,complex_}ieee754_float
> (or ieee754_binary_float?)
> which would depending on DW_AT_byte_size be binary{16,32,64,128,256}
> format, and then add DW_ATE_* values for the floating point formats
> known to us, which would be
> vax_f_float, vax_g_float, vax_d_float (what about vax_h_float?)
> bfloat16
> Intel extended precision
> IBM extended (double double)
> what else?
> Anyway, it might be possible as can be seen in the DW_ATE_HP_*
> extensions to reuse the same DW_ATE_* code for multiple different
> formats as long as they are guaranteed to have different DW_AT_byte_size.
>
> For DW_AT_precision/DW_AT_min_exponent/DW_AT_max_exponent we would
> just define them the same way as C/C++ does define corresponding
> macros, e.g. https://en.cppreference.com/w/c/types/limits
> (though of course, we can only reasonably use properties that are
> expressible as small integral values or booleans, can't have
> attributes matching to say FLT_MAX etc., which need some floating point
> values). All could be optional and the producers would need to use them
> only if without those attributes it would be ambiguous what it is.
>
I suspect you'd end up needing more attributes to completely pin down a
floating-point type. Consider the i86/i87 FPU 80-bit floating-point type. It
had a single bit which was the integer part, in additional to the traditional
fractional bits of the mantissa. So determining the number of bits in the
exponent is not simply (bit_size - mantissa_bits - sign_bit). Also, you'd need
to indicate lack of support for inf/nan, unless you were expecting that to be
deduced from the min_exponent/max_exponent.
The encodings do seem like a cleaner approach, as Ron argued: You either
recognize the enumerated value, probably because your hardware supports it
natively, and you don't care all that much about all the persnickety bits; or
you reject the type. I suppose you might choose to support a non-native
floating-point type, but I suspect you'd need to have a priori knowledge of all
the details anyway.
If we do end up promoting any of these architecture-specific types into the
standard, perhaps we should provide some of the implementation details about
what they mean. We could do that by referencing other documents, but it seems
reasonable to include a table containing the number of bits for each field, and
a mention of any major peculiarities (e.g. skewed bias, inf/nan unsupported,
etc.).
--
Todd Allen
Concurrent Real-Time
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] [EXTERNAL] - RE: Multiple floating point types with the same size but different encodings
For the sake of history, I don't recall much of the technical issues, but I do recall working with Paul way back when (we were both with HP at the time) to come up with a single common HP-wide list of base types and codes for all the floating-point types in use across HP. I support Paul's suggestion that the best strategy is to simply enumerate as DW_ATE codes all the "interesting" representations in use. This enumeration can easily be extended if more are needed. A formal parameterized model for floating point would force consumers to do a lot of detective work to conclude that, for example, "Oh yeah, this is just the IEEE 32-bit type". Alternatively, a dispatch on a DW_ATE code makes it easy to support those, and only those, that are of interest for each implementation One issue that bears discussion is whether the existing types should be considered "generic" (any floating point with a given size) and supplement those with new codes that are very specific to actual implementations? Ron On Tue, Jan 25, 2022 at 8:55 AM Paul Robinson via Dwarf-Discuss < dwarf-discuss@lists.dwarfstd.org> wrote: > John Reagan tells me his message didn't go to the list, > but Jakub quotes it in his reply. My comments below. > > > -Original Message- > > From: Jakub Jelinek > > Sent: Tuesday, January 25, 2022 7:10 AM > > To: John Reagan > > Cc: Robinson, Paul ; ja...@redhat.com; dwarf- > > disc...@lists.dwarfstd.org > > Subject: Re: [EXTERNAL] - RE: [Dwarf-Discuss] Multiple floating point > > types with the same size but different encodings > > > > On Mon, Jan 24, 2022 at 09:43:07PM -0500, John Reagan wrote: > > > Yes, on OpenVMS we have 2 32-bit floats (VAX f_float, IEEE s_float), 3 > > > 64-bit floats (VAX d_float, VAX g_float, IEEE t_float), and 1 128-bit > > > float (IEEE x_float). We had a 2nd 128-bit float back on the VAX but > we > > > don't support that anymore. > > > > > > Our current encoding on OpenVMS Itanium: > > > > > > DW_ATE_Float: s_float (size 4), t_float (byte size 8), x_float (byte > > > size 16) > > > > > > DW_ATE_complex_float: s_float complex, t_float complex, x_float complex > > > > > > DW_ATE_HP_VAX_float [0x88]: f_float (byte size 4), g_float (byte size > 8) > > > > > > DW_ATE_HP_VAX_float_d [0x89]: d_float (byte size 8) > > > > > > DW_ATE_VAX_complex_float [0x8f]: f_float complex, g_float complex > > > > > > DW_ATE_VAX_complex_float [0x90]: d_float complex > > > > > > For choice, I'd guess that Ron might have more history as the comments > > > on the code also say that HP-UX and NSK used the same codes too. So I > > > don't know if OpenVMS was the first user or if OpenVMS inherited it. > > I'd guess that HP-UX got there first, and the VAX-specific ones were added > for OpenVMS later. NSK had a legacy floating-point format but I don't > recall > how we described it. > > > > > If s_float and f_float or t_float and g_float coexist on the same > platform > > in the same ABI, I'm afraid DW_AT_precision to distinguish between them, > > Did you mean, DW_AT_precision isn't enough to distinguish between them? > > > IEEE single has 24-bit significand precision (1 bit implied) and > > it seems s_float does too, and similarly IEEE double has 53-bit precision > > (1 bit implied) and it seems g_gloat does too (d_float has 56-bit > > precision). > > So we'd need also exponent bias (or minimum or maximum exponent) > > to differentiate between them. > > > > Jakub > > It sounds like ATE codes would be better all around. We could have a > pile of attributes that parameterize all the things, but that seems > overly general. > --paulr > > ___ > Dwarf-Discuss mailing list > Dwarf-Discuss@lists.dwarfstd.org > http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org > ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] [EXTERNAL] - RE: Multiple floating point types with the same size but different encodings
On Tue, Jan 25, 2022 at 01:55:40PM +, paul.robin...@sony.com wrote:
> > If s_float and f_float or t_float and g_float coexist on the same platform
> > in the same ABI, I'm afraid DW_AT_precision to distinguish between them,
>
> Did you mean, DW_AT_precision isn't enough to distinguish between them?
Yes. My understanding is that e.g. IEEE single and VAX f_float both use
the same number of bits for exponent and mantissa, but the difference is that
f_float uses a different exponent bias and doesn't support NaNs/Infinities.
So when describing it through the C/C++ float.h macros,
*_MANT_DIG is the same, but they differ in *_MIN_EXP and *_MAX_EXP.
> > IEEE single has 24-bit significand precision (1 bit implied) and
> > it seems s_float does too, and similarly IEEE double has 53-bit precision
> > (1 bit implied) and it seems g_gloat does too (d_float has 56-bit
> > precision).
> > So we'd need also exponent bias (or minimum or maximum exponent)
> > to differentiate between them.
>
> It sounds like ATE codes would be better all around. We could have a
> pile of attributes that parameterize all the things, but that seems
> overly general.
For ATE codes, the problem is with standardization if we wanted
to standardize it in some way for DWARF6.
The current DW_ATE_{,complex_}float is way too unspecific and historically
can be about various formats.
So, we'd need something like DW_ATE_{,complex_}ieee754_float
(or ieee754_binary_float?)
which would depending on DW_AT_byte_size be binary{16,32,64,128,256}
format, and then add DW_ATE_* values for the floating point formats
known to us, which would be
vax_f_float, vax_g_float, vax_d_float (what about vax_h_float?)
bfloat16
Intel extended precision
IBM extended (double double)
what else?
Anyway, it might be possible as can be seen in the DW_ATE_HP_*
extensions to reuse the same DW_ATE_* code for multiple different
formats as long as they are guaranteed to have different DW_AT_byte_size.
For DW_AT_precision/DW_AT_min_exponent/DW_AT_max_exponent we would
just define them the same way as C/C++ does define corresponding
macros, e.g. https://en.cppreference.com/w/c/types/limits
(though of course, we can only reasonably use properties that are
expressible as small integral values or booleans, can't have
attributes matching to say FLT_MAX etc., which need some floating point
values). All could be optional and the producers would need to use them
only if without those attributes it would be ambiguous what it is.
Jakub
___
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] [EXTERNAL] - RE: Multiple floating point types with the same size but different encodings
John Reagan tells me his message didn't go to the list, but Jakub quotes it in his reply. My comments below. > -Original Message- > From: Jakub Jelinek > Sent: Tuesday, January 25, 2022 7:10 AM > To: John Reagan > Cc: Robinson, Paul ; ja...@redhat.com; dwarf- > disc...@lists.dwarfstd.org > Subject: Re: [EXTERNAL] - RE: [Dwarf-Discuss] Multiple floating point > types with the same size but different encodings > > On Mon, Jan 24, 2022 at 09:43:07PM -0500, John Reagan wrote: > > Yes, on OpenVMS we have 2 32-bit floats (VAX f_float, IEEE s_float), 3 > > 64-bit floats (VAX d_float, VAX g_float, IEEE t_float), and 1 128-bit > > float (IEEE x_float). We had a 2nd 128-bit float back on the VAX but we > > don't support that anymore. > > > > Our current encoding on OpenVMS Itanium: > > > > DW_ATE_Float: s_float (size 4), t_float (byte size 8), x_float (byte > > size 16) > > > > DW_ATE_complex_float: s_float complex, t_float complex, x_float complex > > > > DW_ATE_HP_VAX_float [0x88]: f_float (byte size 4), g_float (byte size 8) > > > > DW_ATE_HP_VAX_float_d [0x89]: d_float (byte size 8) > > > > DW_ATE_VAX_complex_float [0x8f]: f_float complex, g_float complex > > > > DW_ATE_VAX_complex_float [0x90]: d_float complex > > > > For choice, I'd guess that Ron might have more history as the comments > > on the code also say that HP-UX and NSK used the same codes too. So I > > don't know if OpenVMS was the first user or if OpenVMS inherited it. I'd guess that HP-UX got there first, and the VAX-specific ones were added for OpenVMS later. NSK had a legacy floating-point format but I don't recall how we described it. > > If s_float and f_float or t_float and g_float coexist on the same platform > in the same ABI, I'm afraid DW_AT_precision to distinguish between them, Did you mean, DW_AT_precision isn't enough to distinguish between them? > IEEE single has 24-bit significand precision (1 bit implied) and > it seems s_float does too, and similarly IEEE double has 53-bit precision > (1 bit implied) and it seems g_gloat does too (d_float has 56-bit > precision). > So we'd need also exponent bias (or minimum or maximum exponent) > to differentiate between them. > > Jakub It sounds like ATE codes would be better all around. We could have a pile of attributes that parameterize all the things, but that seems overly general. --paulr ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
Re: [Dwarf-Discuss] [EXTERNAL] - RE: Multiple floating point types with the same size but different encodings
On Mon, Jan 24, 2022 at 09:43:07PM -0500, John Reagan wrote: > Yes, on OpenVMS we have 2 32-bit floats (VAX f_float, IEEE s_float), 3 > 64-bit floats (VAX d_float, VAX g_float, IEEE t_float), and 1 128-bit > float (IEEE x_float). We had a 2nd 128-bit float back on the VAX but we > don't support that anymore. > > Our current encoding on OpenVMS Itanium: > > DW_ATE_Float: s_float (size 4), t_float (byte size 8), x_float (byte > size 16) > > DW_ATE_complex_float: s_float complex, t_float complex, x_float complex > > DW_ATE_HP_VAX_float [0x88]: f_float (byte size 4), g_float (byte size 8) > > DW_ATE_HP_VAX_float_d [0x89]: d_float (byte size 8) > > DW_ATE_VAX_complex_float [0x8f]: f_float complex, g_float complex > > DW_ATE_VAX_complex_float [0x90]: d_float complex > > For choice, I'd guess that Ron might have more history as the comments > on the code also say that HP-UX and NSK used the same codes too. So I > don't know if OpenVMS was the first user or if OpenVMS inherited it. If s_float and f_float or t_float and g_float coexist on the same platform in the same ABI, I'm afraid DW_AT_precision to distinguish between them, IEEE single has 24-bit significand precision (1 bit implied) and it seems s_float does too, and similarly IEEE double has 53-bit precision (1 bit implied) and it seems g_gloat does too (d_float has 56-bit precision). So we'd need also exponent bias (or minimum or maximum exponent) to differentiate between them. Jakub ___ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
