[cfp-interest 3640] Re: The C-23 approach to encode and decode.
Vincent Lefevre
vincent at vinc17.net
Sun Oct 5 17:30:34 PDT 2025
On 2025-10-06 09:27:12 +1100, Damian McGuckin wrote:
> Interesting comments on Annex H.
>
> FYI only - Damian
I disagree with Michel. Here's my answer in the stds-754 list:
On 2025-10-05 17:59:30 -0400, Michel Hack wrote:
> I do however note a significant flaw in the choice of unsigned char
> arrays for the representations, because those brutally expose the
> Endianness issue! It would have been much better to use uint_32_t,
> uint_64_t, and uint_128_t for this.
Endianness would still have been exposed when such integers are
stored in memory.
> (LLVM may also support uint_256_t, at any rate I recall that a
> colleague worked on this a few years ago.)
An implementation may choose to have a 256-bit floating-point type,
but no uint_256_t format. So you would have a second issue with the
endianness.
This is a bit like the 32-bit ARM processors, where (before VFP got
introduced) the double format (thus a 64-bit format) was encoded like
a structure of two 32-bit integers, in big endian order. But as ARM
is a little-endian processor, this yielded a mixed-endian format.
With VFP, the double format became entirely little-endian in memory.
> I wonder if there are Endian-neutral vector register types, now that
> there are many architectures with wide vector registers. I'm afraid
> however that these may have Little-Endian ordering built-in...
>
> In the context of 754 this affects the parameterized extra-wide formats,
> which implicitly assume array-like backing, but ordering of elements
> within an array may or may not match the ordering of bytes within a
> register-size word.
So like ARM above.
> Anyone remember the messy Vax wide FP formats?
> It's good that 754 decided that these issues are out-of-scope... but
> are we all clear on that?
This is a bit complex. For a processor-independent library, the
possibility of a mixed-endian format eases the implementation.
A good example is GMP / MPFR (MPFR just reuses the GMP format to
store the significand): an integer is an array of words, where
the words are ordered in little endian; but the representation
of each word in memory follows the endianness of the platform.
I don't think that mixed-endianness introduces any issue in
practice (having different endianness between platforms does,
but that's unavoidable to preserve efficiency).
--
Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
More information about the cfp-interest
mailing list