Re: [boost] Ann: Floating Point Utilities Review starts today

From: Martin Bonner (Martin.Bonner_at_[hidden])
Date: 2008-02-26 10:34:04

----Original Message----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Johan Råde Sent: 26
February 2008 15:08 To: boost_at_[hidden]
Subject: Re: [boost] Ann: Floating Point Utilities Review starts today

> John Maddock wrote:
> 
>> Sorry to bring this up again (!), but I've been trying to get my
>> head around the aliasing rules and what is and isn't allowed, in
>> particular by following the rather useful article here:
>> http://www.cellperformance.com/mike_acton/2006/06/understanding_strict_aliasing.html
>> 
>>> From this it appears that your current code is perfectly fine,
>>> however I 
>> still can't help feeling that we could do better than call an
>> external function (memcpy) to move 4 or 8 bytes.
> 
> When you compile on Visual Studio, with the compiler option /Oi (or
> /O2), 
> then the compiler treats memcpy as a compiler intrinsic (i.e.
> essentially as a key word) 
> and not as an external function; see
> http://msdn2.microsoft.com/en-us/library/tzkfha43.aspx 
> I looked at assembler output a year ago, and, if I remember right,
> a memcpy of four bytes was compiled to a single move instruction.
> 
> The suggestion in the article is to
>> use a union to move from one type to another:
>> 
>> union float_to_int32
>> {
>>    float f;
>>    boost::uint32_t i;
>> };
>> 
>> boost::uint32_t get_bits(float f)
>> {
>>    float_to_int32 u;
>>    u.f = f;
>>    return u.i;
>> }
>> 
>> I can't claim to have tested exhaustively, but modifying get_bits and
>> set_bits to use this method seems to work OK for VC8&9 and Minwg GCC.
>> 
> 
> Interesting, but I wouldn't do this without the approval of a
> pedantic langauge lawyer. 
> I have been bitten by this sort of things in the past.
> And I'm not sure it would make things faster on Visual Studio anyway.

I'm not sure I'm a pedantic language lawyer, but the standard says "In a union, at most one of the data members can be active at any time".  It is quite clear that experts in CLC++M regard John Maddock's version of setbits and getbits as undefined behaviour.  In general, I would regard using undefined behaviour as unacceptable for a boost library.  The floating point utilities are different, they pretty much /have/ to use undefined behaviour.  They also seem to be taking the correct approach of using #ifdef, and testing on as many platforms as possible (I haven't reviewed them yet).  

On the other hand, even if floating point utilities have to go through a minefield, there doesn't seem any point in wandering around more than necessary. Particularly if the tested compilers don't actually generate better code for the undefined behaviour version!

-- 
Martin Bonner
Senior Software Engineer/Team Leader
PI SHURLOK LTD
Telephone: [phone] / 203894 (direct)
Fax: [phone]
Email: martin.bonner_at_[hidden]
www.pi-shurlok.com
disclaimer