[Dwarf-Discuss] [EXTERNAL] - RE: Multiple floating point types with the same size but different encodings
Tue Jan 25 13:55:40 GMT 2022
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 <jakub at redhat.com>
> Sent: Tuesday, January 25, 2022 7:10 AM
> To: John Reagan <john.reagan at vmssoftware.com>
> Cc: Robinson, Paul <paul.robinson at sony.com>; jason at redhat.com; dwarf-
> discuss at 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
> 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
More information about the Dwarf-discuss