[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] Got strange compilation problem

From: David Bourgeois
Subject: Re: [avr-gcc-list] Got strange compilation problem
Date: Fri, 17 Feb 2006 15:24:42 +0100
User-agent: Opera M2/8.51 (Win32, build 7712)

Indeed that's the difference which explains why one solution generates much shorter code than the second. I'm too ashamed too explain the stupid reason why my code broke :-/ so I guess both solutions were working right. So this was the opportunity to learn more about typecasts and the important thing here is that ((uint8 + uint8) % uint8) takes more space than ((uint8_t)(uint8_var1 + uint8_var2) % uint8_var3) for the exact reason you explained below.

Thanks to all,

On Thu, 16 Feb 2006 10:48:57 +0100, Joerg Wunsch <address@hidden> wrote:

"David Bourgeois" <address@hidden> wrote:

(A full compilable example would be nice.  It's always hard to guess
the various missing pieces when trying to reproduce other people's

Replacing the 2 lines
     length = (p->inIdx) - (p->outIdx);
     length %= FIFO_SIZE;
     length = (((p->inIdx) - (p->outIdx)) % FIFO_SIZE);

completely broke my code.

The difference between both is that in the first case, the entire
computation is trimmed down to a uint8_t result immediately, while in
the second case, the intermediate results are computed as `int'.  Note
the change in signedness: the implicit promotion of a uint8_t argument
to an int expression makes the expression signed.  I guess that's what
broke your code.

The IMHO equivalent single-line expression would be

length = (uint8_t)(unsigned)((p->inIdx) - (p->outIdx)) / FIFO_SIZE;

even though GCC still generates somewhat different code for that.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]