IEEE extended real formats

[Zack Weinberg <zack at codesourcery dot com>]

I'm looking into bug 14610, which says that IEEE extended floating
constants are incorrectly emitted on ia64.  Indeed they are.  However,
there are ramifications beyond the ia64, hence this message.

real.c knows three subtypes of IEEE extended: Motorola, Intel 96-bit,
and Intel 128-bit.  These are rendered into memory thus
(S=sign/exponent, E=exponent, M=mantissa, 0=literal zero, each
character is a hexadecimal digit)

(Motorola)  SEEE 0000 MMMM MMMM MMMM MMMM   (big-endian)
            MMMM MMMM MMMM MMMM 0000 EEES   (little-endian)

(Intel 96)  SEEE 0000 MMMM MMMM MMMM MMMM   (big)
            MMMM MMMM MMMM MMMM 0000 EEES   (little)

(Intel 128) 0000 0000 SEEE 0000 MMMM MMMM MMMM MMMM  (big)
            MMMM MMMM MMMM MMMM 0000 EEES 0000 0000  (little)

I've checked the M68k, i386, and ia64 reference manuals, and I believe
that the Motorola format is correct, but both Intel formats are wrong.
All Intel documentation describes IEEE extended as an 80-bit format:

   SEEE MMMM MMMM MMMM MMMM   (big)
   MMMM MMMM MMMM MMMM EEES   (little)

For the ia64, this is expected to be embedded in an 128-bit memory
block with all the padding at higher addresses, in *both*
endiannesses:

   SEEE MMMM MMMM MMMM MMMM 0000 0000 0000
   MMMM MMMM MMMM MMMM ESSS 0000 0000 0000

What I'm not clear on is where the x86 expects the padding.  The
manuals, even the most recent, simply say "extended-real values are
stored in 10 consecutive bytes."  But this is always embedded in an
12- or 16-byte block, so I do not know what to do.  Can anyone
comment?

zw