Hi All,

We all know that, more often than not, the formats of scalar types
such as:

float
double
long double

....assume canonical forms, often standardized by IEEE and others
standards organizations.

I would like to know:

1. For a particular CPU bit-width, the extent of variation of formats.
For example, if someone says, "I just bought a 64-bit machine", what
do you imagine to be the extent of variations on potential formats of
the floating-point scalar types for all the possible C++ compilers
that could run on that machine? If the type is 'double', you might
say, "I imagine there will be 14 different potential formats for
'double' on that 64-bit machine for all possible compilers.'

2. For the Universe of CPU's, OS's, and C++ compiler packages, what is
extent of variation? You might say, "Well...CPU's generally go from 8-
bit to 256-bit for machines that might be seen by average user.
Accross all machines, it is not so much the compiler, but the
underlying architecture, and I happen to know that 'double' has, in
practice, only assumed specific, standardized formats, and there are X
of them." What is X?

3. Does C++ Standard prescribe underlying permissible arithemetic
scalar formats to any extent?

-Le Chaud Lapin-

-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Le Chaud Lapin wrote:
> Hi All,
> 
> We all know that, more often than not, the formats of scalar types
> such as:
> 
> float
> double
> long double
> 
> ...assume canonical forms, often standardized by IEEE and others
> standards organizations.
> 
> I would like to know:
> 
> 1. For a particular CPU bit-width, the extent of variation of formats.
> For example, if someone says, "I just bought a 64-bit machine", what
> do you imagine to be the extent of variations on potential formats of
> the floating-point scalar types for all the possible C++ compilers
> that could run on that machine?  ...

The bit-width of a machine tells you almost nothing useful about this. 
The relevant information is the FPU type. If the machine has an FPU (not 
necessarily as a distinct unit), you can reasonably assume that all 
compilers for that machine use types recognized by that FPU. For those 
few systems without an FPU, software emulation must be used, in which 
case just about anything is possible, though you can reasonably guess 
that a 64-bit machine, at least one emulated floating point type will 
have a size of 64-bits, and that 'double' will be such a type. IEEE 
formats are popular, but less-than-full conformance with IEEE 
requirements is quite common.

> ... If the type is 'double', you might
> say, "I imagine there will be 14 different potential formats for
> 'double' on that 64-bit machine for all possible compilers.'
> 
> 2. For the Universe of CPU's, OS's, and C++ compiler packages, what is
> extent of variation? You might say, "Well...CPU's generally go from 8-
> bit to 256-bit for machines that might be seen by average user.
> Accross all machines, it is not so much the compiler, but the
> underlying architecture, and I happen to know that 'double' has, in
> practice, only assumed specific, standardized formats, and there are X
> of them." What is X?

I've no idea - sorry! I suspect that X is larger than you'd like, but 
that a fairly small subset of those formats account for the overwhelming 
majoring of systems.

> 3. Does C++ Standard prescribe underlying permissible arithemetic
> scalar formats to any extent?

If std::type_traits<T>::is_iec559 is true, then T is required to conform 
to IEC 559 requirements, equivalent to IEEE 754. But is_iec559 is not 
required to be true.

Otherwise, C++ cross-references the C standard for the contents of 
<float.h> and <cfloat>. The <float.h> section of the C standard 
cross-references section 5.2.4.2.2, which describes a model for a 
generalized floating point format, and defines the contents of <float.h> 
in terms of that model. However, footnote 16 explains "The 
floating-point model is intended to clarify the description of each 
floating-point characteristic and does not require the floating-point 
arithmetic of the implementation to be identical."

In practice, that model is sufficiently general that I doubt that there 
are many commonly used floating point formats that it can't describe.

-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

Le Chaud Lapin schrieb:
> Hi All,
> 
> We all know that, more often than not, the formats of scalar types
> such as:
> 
> float
> double
> long double
> 
> ...assume canonical forms, often standardized by IEEE and others
> standards organizations.
> 
> I would like to know:
> 
> 1. For a particular CPU bit-width, the extent of variation of formats.
> For example, if someone says, "I just bought a 64-bit machine", what
> do you imagine to be the extent of variations on potential formats of
> the floating-point scalar types for all the possible C++ compilers
> that could run on that machine? If the type is 'double', you might
> say, "I imagine there will be 14 different potential formats for
> 'double' on that 64-bit machine for all possible compilers.'

For the intels, it doesn't really matter whether the underlying 
technology is 32 or 64 bit wide as the floating point types are the 
same. We usually have the following mapping:

float	:	IEEE single precision, 32 bits
double	:	IEEE double precision, 64 bits

Gcc also offers:

long double:	IEEE extended precision, 80 bits in memory, 96 in the 
registers (some additional zero-bits are in the register that are not 
stored, but do not contribute to the precision of the type).

Approximately the same variations hold for other machines. MC68K 
supports all three of them, the PPCs only single and double precision.

> 2. For the Universe of CPU's, OS's, and C++ compiler packages, what is
> extent of variation? You might say, "Well...CPU's generally go from 8-
> bit to 256-bit for machines that might be seen by average user.
> Accross all machines, it is not so much the compiler, but the
> underlying architecture, and I happen to know that 'double' has, in
> practice, only assumed specific, standardized formats, and there are X
> of them." What is X?

You'll find plenty. For example, for the MC68Ks, Motorola also defined 
an in-house format "Fast Floating Point" with a 7 bit exponent, one 
sign-bit and 24 mantissa bits and no denormalized numbers (IIRC). It was 
easier to extract the exponent quickly from the binary representation.

OpenGL uses a "half-float" format with five exponent bits and ten 
mantissa bits (IIRC), requiring only 16 bits. I'm unclear whether any 
compiler supports it directly, but the OpenEXR toolchain does support it 
in C++ by "class magic".

The MC68Ks also support a format called "packed decimal" which was a 
nibble-based BCD-arithmetic format. I don't remember any compiler 
supporting it, and its support was also phased out on the 68040 and 
68060 CPUs and there only available in software.

For really really ancient processors like the 6502, I remember a decimal 
6 byte floating point format with one byte (two digits) exponent and 
four digits mantissa with the base of 100 (not 10). There might be a 
compiler (the CC65) which might even support it as "float" - I'm not 
sure, though.

So long,
	Thomas

-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

On Oct 7, 7:09 pm, Le Chaud Lapin <jaibudu...@gmail.com> wrote:
> Hi All,
>
> We all know that, more often than not, the formats of scalar types
> such as:
>
> float
> double
> long double
>
> ...assume canonical forms, often standardized by IEEE and others
> standards organizations.

    This doesn't agree with my own experience.

    However, it is true that if anyone designs a
    _new_ architecture from scratch, they are likely
    to use IEEE-754 floating-point format.  But there
    are plenty of machines being manufactured which
    support older formats, for backward compatibility.
    Prior to IEEE-754, each manufacturer used its own
    formats.

    Note that supporting IEEE-754 format is not the
    same as conforming to the IEEE-754 standard.

> I would like to know:
>
> 1. For a particular CPU bit-width, the extent of variation of formats.

    CPU bit-width is not always very well defined.
    Are you talking about memory path width?
    Maximum integer register width?
    Largest integer width supported by your compiler?

    And why would any of these determine
    the floating-point format?


> For example, if someone says, "I just bought a 64-bit machine", what
> do you imagine to be the extent of variations on potential formats of
> the floating-point scalar types for all the possible C++ compilers
> that could run on that machine?

    If you include floating point done
    entirely in software (using integer
    operations) it's potentially infinite,
    even if you specify the architecture.

    Even if you restrict yourself to
    hardware implementations, I can
    think of at least 4 hardware-supported
    64-bit floating point formats off the
    top of my head, just on machines I've used.

    Even if you know the format, there's
    still the question of byte-ordering,
    which some people might need to know.
    I know of at least 3: big-endian,
    little-endian, and NUXI.  On machines
    w/o byte operations, this could be
    compiler-dependent.

> 2. For the Universe of CPU's, OS's, and C++ compiler packages, what is
> extent of variation? You might say, "Well...CPU's generally go from 8-
> bit to 256-bit for machines that might be seen by average user....

   What counts as "the average user"?  90% of
   users have never seen anything but a
   Wintel box, probably 90% of programmers, too.

   That said, it sounds like a question for a
   computer architecture expert, not for a
   C or C++ newsgroup.

> 3. Does C++ Standard prescribe underlying permissible arithemetic
> scalar formats to any extent?

    As I understand, integers have to at
    least pretend to be 2's compliment binary,
    and the standard specifies minimum widths
    for each type.

    AFAIK, it places no restrictions
    whatsoever on floating-point,
    except maybe that double has to
    have more precision that float, etc.
    It's all QOI.


-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]

On Thu,  8 Oct 2009 21:01:15 CST, Thomas Richter
<thor@math.tu-berlin.de> wrote:

>The MC68Ks also support a format called "packed decimal" which was a 
>nibble-based BCD-arithmetic format. 

x86 (up to 32-bit) also has packed BCD support.  Integer ALU support
for BCD was dropped from x86-64, though it still works in
compatibility mode.

Additionally the x87 FPU supports load/store conversion of 18-digit
(10-byte) packed BCD integer values.  Arithmetic is done in the native
format with the result truncated (if fractional) and converted to BCD
on store.  This works in all x86(-64) chips.


>I don't remember any compiler supporting it, and its support was also
>phased out on the 68040 and 68060 CPUs and there only available in 
>software.

Ditto x86 compilers.  The only way to use BCD is via assembler.

George

-- 
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]