Re: your mail
On 2014-06-23 10:32:27 -0400, Michel Hack wrote:
> On Mon, 23 Jun 2014 11:02:10 +0200 Vincent Lefèvre wrote:
> > This is how I understand it: the mapping of bits to the memory is
> > entirely unspecified by the standard.
>
> I think we all agree on this. As Dima points out, it's the external
> representation we're talking about, in a network or file stream.
But IEEE 754 doesn't specify that either.
Note that for a network or file stream, one may prefer a
character-based representation, as already specified. This avoids
some problems, as you know. Then, what are the reasons to specify
a binary format? I don't remember that this question was raised.
If this is for (memory + time) efficiency, then you want to keep
the same memory representation as the IEEE 754 implementation (so,
nothing really portable, but there are practical solutions to
detect or announce the representations used in practice).
If this is for compactness (and you don't care very much about the
overhead of a conversion), then you can fix a byte-string format
(possibly parameterized in a limited way, e.g. either BE or LE,
if time matters a bit). Also note that compression can yield good
compactness over character-based formats.
> > There may be even more possibilities that endianness. An implementation
> > could choose to introduce some form of mix-endianness (a bit like old ARM's
> > for binary64), padding bits, possibly holes, and so on.
>
> I thought the world had become more reasonable since the growing pains of
> the 1980s, when formats evolved from 8 to 16 to 32 and finally 64 bits.
> So there was (is there still?) a mixed-endian representation of an IEEE 754
> format. I knew that some of the various Vax FP formats were mixed-Endian.
FYI:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0056d/Bcfhgcgd.html
The reason is that the ARM is 32-bit based, and loading a binary64
is done by loading 2 consecutive 32-bit words; this can be done with
a single instruction, but you don't have the choice of which word
comes first. The ARM supports both BE and LE. This means that whatever
choice is done with this method, you'll end up with a "mixed-endian"
format in either BE or LE mode.
Concerning GCC support of this format:
https://gcc.gnu.org/gcc-4.7/changes.html
Support on ARM for the legacy floating-point accelerator (FPA)
and the mixed-endian floating-point format that it used has been
obsoleted. The ports that still use this format have been obsoleted
as well. Many legacy ARM ports already provide an alternative that
uses the VFP floating-point format. The obsolete ports will be
deleted in the next release.
https://gcc.gnu.org/gcc-4.8/changes.html
Code generation support for the old FPA and Maverick floating-point
architectures has been removed. Ports that previously relied on
these features have also been removed.
and the current GCC version is 4.9.
> In any case, I agree that we can't handle all bizarre cases, and am
> not quite sure what to say about them, should they arise, other than
> perhaps to define their own non-conflicting signature. But I don't
> want to be totally silent about the issue, like 754-2008. As I
> mentioned in an earlier post, 754 could get away with it because it
> only defined the representation of a single datum and not of an
> ordered aggregate, as 1788 has to.
I think that one can leave the related P1788 parts as undefined if the
FP representation is neither pure BE nor pure LE.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)