Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Proposed replacement for 14.4 and C6.2 (interchange encodings)



The first three paragraphs of 14.4 are ok.  I start with rewriting the
fourth paragraph, which currently begins the same way:

   Interchange Level 4 encoding of an interval datum is a bit string that
   comprises, in the order defined above, the platform's representation
   of the 754-2008 interchange encodings of the two floating-datums, and
   of the decoration represented as a small integer, as detailed below.
   Since the 754-2008 standard supports two different encodings for
   decimal formats, and does not address the Endianness issue at all,
   this standard defines a *standard type signature*, described below,
   which incorporates the parameters of the encoding.

   Interchange encoding of the decoration field is as a small integer:
      ill    0
      trv    4
      def    8
      dac   12
      com   16
   This encoding permits future refinement without disturbing the natural
   propagation order of the decorations, and fits within the range of a C
   signed char, namely 0..127.

   A 754-conforming implementation *shall* provide, for each interchange
   encoding, a *standard type signature*, which is a 16-byte string laid
   out as follows:
      ieee1788           8 bytes, Ascii, any case
      bin | bid | dpd    3 bytes, Ascii, defines FP encoding
      '\0'               1 byte, null char (8 zero bits)
      nnnn               4 bytes, size in bytes, stored as native int32

   The size is that of the interchange object, consisting of the two
   floating-point datums and the decoration.  From this the size of
   an individual floating-point datum and of the decoration can be
   derived (assuming only that the former is a multiple of the latter,
   and that the size of the latter is a power of two), as well as the
   Endianness of the representation (assuming that the size is less
   than 2**24, which is presumably large enough to cover any extended
   format being contemplated in the near future).

   The flexibility in the size of the decoration is to accomodate
   alignment and padding issues -- or systems whose "small integer"
   datatype is a word and not a byte.  (It still assumes that a word
   consists of 2, 4 or 8 bytes, which seems general enough today.)

   For example, in C, the corresponding structure describing the type
   used in the Basic Standard (Chapter C) would be:
      struct { char    format[12];
               int32_t itemlength; } xxx = { "ieee1788bin", 17 };

   (If ld=2**d is the size of the decoration, and lf=k*ld is the size
   of a floating-point datum, then itemlength = (2k+1)*2**d, from which
   both k and d can be recovered, and hence also lf and ld.)

   Such a type signature could be included in a header that accompanies
   interchange-encoded intervals for export, to achieve fairly universal
   portability.

The original text resumes with the Example, except that there should be
two versions following the two-line Level-3 description.  In each instance
"The interchange encodings" is to be replaced with:
  The Big-Endian interchange encodings...     (example as given)
  The Little-Endian interchange encodings...  (on each line, reverse the
                                               eight-bit bytes, but not
                                               the bits within a byte)


Similarly, the first three paragraphs of C6.2 are ok, and my rewrite starts
with the fourth paragraph:

   Interchange Level 4 encoding of an interval datum is a bit string that
   comprises, in the order defined above, the platform's representation of
   the 754-2008 interchange encodings of the two binary64 floating-datums,
   and of the decoration represented as a small integer, as detailed below.

   Interchange encoding of the decoration field is as a small integer:
      ill    0
      trv    4
      def    8
      dac   12
      com   16
   This encoding permits future refinement without disturbing the natural
   propagation order of the decorations, and fits within the range of a C
   signed char, namely 0..127.

   In order to achieve near-universal portability, the encoding is described
   by a standard type signature, which deals with the fact that IEEE 754-2008
   does not address the Endianness issue.  This is a 16-byte string laid out
   as follows:
      ieee1788           8 bytes, Ascii, any case
      bin                3 bytes, Ascii, defines FP encoding
      '\0'               1 byte, null char (8 zero bits)
      nnnn               4 bytes, size in bytes, 17 as native int32

   The size is that of the interchange object, consisting of the two
   floating-point datums and the decoration.  (The format is designed to
   support the larger choice of number formats and encodings permitted by
   the full standard.)

   For example, in C, the corresponding structure would be:
      struct { char    format[12];
               int32_t itemlength; } xxx = { "ieee1788bin", 17 };

   Such a type signature could be included in a header that accompanies
   interchange-encoded intervals for export, to achieve fairly universal
   portability.

The original text resumes with the Example, except that there should be
two versions, Big-Endian and Little-Endian, as decribed above for 14.4.


Michel.

P.S.  My earlier "C struct" example was syntactically challenged...
---Sent: 2014-06-22 19:38:54 UTC