Encodeing of compressed intervals
Michel,
Let us take encoding of bin32 is a 32-bit string.
We numerate bits form left to right.
bits[0] is a sign bit. bits[1:8] are exponent bits. buts[8:31] are significand field.
The IEEE 754 2008 3.4, 6.2.1 say
that the following bitstrings encode sNaNs
bits[1:9]=111111110 && !bits[10:31]=0000000000000000000000
and the following bitstrings encode qNaNs
bits[1:9]=111111111
The payload is encoded in bits[10:31].
We could encode decoration dec in payload of sNaN in such a way
bits[0:10]=0111111111 bits[11:18]="decoration octet" bits[19:31]=0000000000000 .
These are unambiguous rules where to find payload in a bitstring.
The code pattern to extract the payload is ((bits >> 13) & 0xff .
> As I pointed out, BFP NaNcodes are not portable. On some platforms you
> have to reverse the bits. You also have to communicate the NaN encoding
> rules, which could be messy.
Some platform names the sign bit as bit[0] and other platforms name
sign bit as bit[31].
This is not a trouble if sign bit of bin32 is at the same position as
sign bit of int32.
Do you mean that there are some platforms where positions of sign bit in bin32 and int32 are different ?
-Dima
----- Original Message -----
From: mhack@xxxxxxx
To: stds-1788@xxxxxxxxxxxxxxxxx
Sent: Friday, June 27, 2014 12:29:41 AM GMT +04:00 Abu Dhabi / Muscat
Subject: Re: ... replacement for 14.4 and C6.2 (interchange encodings)
> Yes. And it seems to me that it is easy to extract decoration when it
> is encoded in payload. It is logical AND with a certain bit mask and
> possibly a shift.
As I pointed out, BFP NaNcodes are not portable. On some platforms you
have to reverse the bits. You also have to communicate the NaN encoding
rules, which could be messy.
> Maybe 16+0.0 16+2.0 16+4.0 16+8.0 16+12.0 is better as the decoration
> again can be extracted by a logical AND.
You just described how one extracts a floating-point integer. Indeed,
by adding 0x1p52 to the FP-encoded decoration, the FP integer becomes
a clean 32-bit unsigned integer in the bottom (least-significant) half
of a binary64 datum. This addition can be done by the sender or by
the receiver -- and letting the receiver do it preserves the standard
values of the decorations in the interchange format.
Many machines also have instructions to convert directly beween int
and double, so in C one typically simply codes deco = (int)fp_deco,
and the compiler typically generates just one or two instructions.
Michel.
---Sent: 2014-06-26 20:28:17 UTC