[Dwarf-Discuss] [EXTERNAL] - RE: Multiple floating point types with the same size but different encodings

[Ron Brender]

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 at 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 <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
> > 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 at lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/attachments/20220125/5075e4b3/attachment-0001.html>