Floating point binary layout between compilers

Question

I am cleaning up some of our network-code and while replacing various integer types (int, unsigned short, ...) with more explcit typedefs such as int32_t and uint16_t I was wondering how portable double and float are between different compilers. We are sending structures similar to the following:

struct foo
{
   uint32_t id;
   double dbl;
};

...

// copy_packed() copies packed bytes of integral type and adheres 
// to network byte-ordering
copy_packed(int32_t data, char* buffer, char* end);
copy_packed(uint32_t data, char* buffer, char* end);
copy_packed(uint16_t data, char* buffer, char* end);

...
// overload for structure types calls overloads for its members
void copy_packed(foo &data, char* buffer, char* end)
{
    copy_packed(data.id, buffer); 
    copy_packed(data.id, buffer); 
};

Until now only programs compiled with VC++ are used, but use of the protocol on GCC is scheduled.

The question is now: can double amd float be safely send over the wire even when then interpreted by different compilers? The question - as far as I understand - boils down to whether GCC and VC++ comply to IEEE754. Or maybe provide functions to convert to conformant packaging?

Any hints on the matter?

this might help: http://stackoverflow.com/q/7248950/79455 does almost the same as you do — rve, Oct 31 '11 at 11:24

score 4 · Answer 1 · answered Oct 31 '11 at 11:26

4

You can ask the compiler: std::numeric_limits<T>::is_iec559 will tell you whether type T is a IEC559 (IEEE754) type.

answered Oct 31 '11 at 11:26

MSalters

173,980
10
155
350

my concern is more related to the question whether relevant compilers agree on how they "interpret" IEEE754. Even tough there shouldn't be much room for interpretation anyway.. – Arne Oct 31 '11 at 22:07
Then you should have asked that. Many compilers can apply relaxed rules, e.g. to facilitate Common Subexpression Elimination, which would violate IEEE754 order-of-evaluation rules. That's not related to layouts, though. – MSalters Nov 01 '11 at 08:54
well, I sense you misunderstood me here. I am/was concerned about how, for example different compilers might or might not use different bit patterns to indicate NaN and such. This *is* a matter of binary data layout and very relevant when sending data over the wire. – Arne Nov 02 '11 at 20:13
@Arne: Wouldn't really matter what they use (as output). While there are multiple NaN formats possible, all IEEE754 implementations have to accept (as input) all possible NaN formats. – MSalters Nov 03 '11 at 10:19
... and that's exactly what I wanted to hear :-) Still, I somehow expect(ed) this not to be the case in practice. – Arne Nov 03 '11 at 21:58

score 4 · Accepted Answer · answered Oct 31 '11 at 11:48

Not very. IEEE doesn't define byte order, and not all systems are IEEE. The real question is how portable you have to be. IEEE is pretty much universal for modern Unix platforms, as well as Windows; if your portability is limited to these, you can generally type pun a float into a uint32_t, and a double into a uint64_t, and handle input and output that way. If you have to take mainframes into consideration (and possibly embedded processors—I'm less familiar about those), you'll have a lot more work to do; floating point on the major mainframes isn't even base 2.

There is another variation: the interpretation of the bit marking signaling NaN varies. — AProgrammer, Oct 31 '11 at 11:54

score 2 · Answer 3 · answered Oct 31 '11 at 11:29

This is one of the best article I ever have seen on Floating Point Arithmetic. Jump in to Current IEEE 754 Implementations

Current implementations of IEEE 754 arithmetic can be divided into two groups distinguished by the degree to which they support different floating-point formats in hardware. Extended-based systems, exemplified by the Intel x86 family of processors, provide full support for an extended double precision format but only partial support for single and double precision: they provide instructions to load or store data in single and double precision, converting it on-the-fly to or from the extended double format, and they provide special modes (not the default) in which the results of arithmetic operations are rounded to single or double precision even though they are kept in registers in extended double format. (Motorola 68000 series processors round results to both the precision and range of the single or double formats in these modes. Intel x86 and compatible processors round results to the precision of the single or double formats but retain the same range as the extended double format.) Single/double systems, including most RISC processors, provide full support for single and double precision formats but no support for an IEEE-compliant extended double precision format. (The IBM POWER architecture provides only partial support for single precision, but for the purpose of this section, we classify it as a single/double system.)

+1 @sarat: I did knew the original paper but never saw the edited version you pointed out. Nice! — Arne, Oct 31 '11 at 22:02

Floating point binary layout between compilers

3 Answers3