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.