Boost logo

Boost :

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2007-09-09 13:35:39


Guillaume Melquiond wrote:
> Le samedi 08 septembre 2007 ? 23:10 -0400, Daryle Walker a ?crit :
>> Maybe we should add a header to our detail (and/or pending) folder
>> encapsulating the full versions of built-in integer arithmetic
>> operations, that most(?) processors have, but neither C nor C++ let us
>> access. I'm talking about functions like:
>>
>> std::pair<unsigned, bool> full_add( unsigned a1, unsigned a2 );
>>
>> The processor has a "carry" flag whenever an integer addition overflows,
>> but we can't access it (without assembly-language hacks).
>
> Is it really worth it? Nowadays, compilers are smart enough. They
> generate better code when details are not obfuscated by hand-crafted
> assembly code. I tested the following code with GCC:
>
> #include <algorithm>
>
> std::pair<unsigned, bool> full_add(unsigned a, unsigned b)
> { return std::make_pair(a + b, a + b < a); }
>
> bool no_overflow(unsigned a, unsigned b)
> { return !full_add(a, b).second; }

Here's what I get on ARM:

_Z8full_addjj:
        adds r2, r1, r2
        movcc r1, #0
        movcs r1, #1
        str r2, [r0, #0]
        strb r1, [r0, #4]
        mov pc, lr

_Z11no_overflowjj:
        cmn r0, r1
        movcs r0, #0
        movcc r0, #1
        mov pc, lr

which looks pretty good, and probably optimal.

But I have encountered cases where compilers don't (can't?) do a very
good job; for example, I don't think I've seen a way to get optimal
code for 128-bit addition. Even 64-bit arithmetic is not so great on
32-bit processors, with library functions used rather than inline
adds/adc sequences. But maybe this is better fixed by improving the
compiler. Daryle, what application did you have in mind?

Phil.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk