AVR Freaks

At one time, unsigned char would promote to unsigned int.

That was annoying enough that it got changed.

That said, using an int implies that the compiler cannot optimise away a register use.

Comparing the result with an operand is faster and requires fewer registers.

    c1 += c2;
    if (c1 < c2) {
        // overflow
    }

@alank2: It would be helpful if you would change the subject to something that actually describes the topic of discussion; eg, "Detect Overflow In C" - this would make it easier to find again in future, as it's a topic that does come up from time-to-time.

See also Tip #5.

EDIT

Done - see #17

In GCC that would be:

if (SREG & (1 << SREG_C)) {

HOWEVER the C language gives no guarantee about code sequencing. In the presented code it might suit the optimising code generator to actually do the SREG test before the addition !

Having said that a quick test with:

#include <avr/io.h>

uint8_t c1, c2;

int main(void) {
    while(1) {
        c1 += c2;
        if (SREG & (1 << SREG_C)) {
            PORTB = 0xFF;
        }
    }
}

generates the "right code" on this occasion:

uint8_t c1, c2;

int main(void) {
    while(1) {
        c1 += c2;
  7e:   20 91 60 00     lds     r18, 0x0060     ; 0x800060 <_edata>
  82:   80 91 61 00     lds     r24, 0x0061     ; 0x800061 <c1>
  86:   82 0f           add     r24, r18
  88:   80 93 61 00     sts     0x0061, r24     ; 0x800061 <c1>
        if (SREG & (1 << SREG_C)) {
  8c:   0f b6           in      r0, 0x3f        ; 63
  8e:   00 fe           sbrs    r0, 0
  90:   f8 cf           rjmp    .-16            ; 0x82 <main+0x6>
            PORTB = 0xFF;
  92:   98 bb           out     0x18, r25       ; 24
  94:   f4 cf           rjmp    .-24            ; 0x7e <main+0x2>

But, it would be VERY unwise to rely on this kind of thing.

But that is a terrible solution!

The true solution here is probably to start by picking variable widths that will not overflow in the first place.

There is still no guarantee that the carry flag (or any other flag in SREG) will reflect the previous expression.  The comma creates a sequence point, wherein all side effects of the first expression are complete before the second expression is evaluated, and none of the side effects of the second expression will have occurred until after the first expression has been evaluated.  Since the hardware flags in SREG are not part of the C abstract machine, changes to them will not be counted as side effects, and the sequence point will exert no power over them.

; asm.S

#define __SFR_OFFSET 0
#include <avr/io.h>

    .global add_8_with_carry

    ; bool add_8_with_carry( uint8_t addend, uint8_t augend, uint8_t * sum );
    ; ABI says addend in R24, augend in R22, *sum in R21:R20
add_8_with_carry:
    add R22, R24 ; doesn't really matter which way round this is done and R24 is then free to prepare bool return
    ldi R24, 1
    brcs 1f
    clr R24
1:
    mov R27, R21
    mov R26, R20
    st X, R22
    ret

and invoked as:

// avr.c

#include <stdbool.h>
#include <avr/io.h>

bool add_8_with_carry( uint8_t addend, uint8_t augend, uint8_t * sum );

uint8_t c1, c2;

int main(void) {
    c1 = 0xAA;
    c2 = 0x99;
    if (add_8_with_carry(c1, c2, &c1)) {
        PORTB = 0x55;
    }
    else {
        PORTB = 0xAA;
    }
    while(1) {
    }
}

This appears to build clean with:

D:\atmel_avr\avr8-gnu-toolchain-win32_x86\bin>avr-gcc -mmcu=atmega16 avr.c asm.S -Os -g -o avr.elf

D:\atmel_avr\avr8-gnu-toolchain-win32_x86\bin>

I  wouldn't quite go that far -- a comparison test on multi-bit-often-multi-byte values is going to be less expensive than a status register bit test?  I'd think not.  But

... I'd lean very far towards awneil.  How many lines of A VR8 code have I written in the past 20 years?  Well over a million source lines I'd wager.  How many times did I feel a bit irritated that my chosen C toolchain didn't have carry or rotate or arithmetic operand widths other than standard?  Probably "several".  Now many times was it so important to the app that I needed to do a cycle-counted solution?  A "few".  So make the critical loop tight and get on with life. Whinging about what is included in the C >>language<< ain't gonna help get the app to work any quicker.  You are free to invent your own language.  Or add extensions to the infinite-value-open-source-toolchain.

Maybe I'm missing something in your analysis, skeeve.  Am I looking at the wrong C implementation example?  How do you know that both operands are in registers after the arithmetic operation?  If it is just carry being tested than wouldn't one use BRCS?  But no matter in the end...as I mentioned I think it would be rare in the real world that this is of vital importance, and if so it will be worth the time to answer the questions.