Weekly edition	Kernel	Security	Distributions	Contact Us	Search
Archives	Calendar	Subscribe	Write for LWN	LWN.net FAQ	Sponsors

Lack of CarryOut in C

Posted Apr 2, 2013 18:45 UTC (Tue) by jreiser (subscriber, #11027)
In reply to: McIntyre: Scanning for assembly code in Free Software packages by butlerm
Parent article: McIntyre: Scanning for assembly code in Free Software packages

the inability of C code to take advantage of the carry bit

Amen. However, sometimes ((unsigned)(x+y) < (unsigned)x) plus a comment is good enough (courtesy of MIPS, which has no Carry in hardware.)

That still isn't good enough for decoding a big-endian bitstream, which wants both CarryOut and Zero after ((x<<=1)|CarryIn).

(Log in to post comments)

Lack of CarryOut in C

Posted Apr 2, 2013 19:24 UTC (Tue) by brunowolff (guest, #71160) [Link]

This risks getting removed during optimization.

Lack of CarryOut in C

Posted Apr 2, 2013 20:14 UTC (Tue) by pbonzini (subscriber, #60935) [Link]

Not for ((unsigned)x+(unsigned)(y) < (unsigned)x). jreiser almost got it right.

Lack of CarryOut in C

Posted Apr 3, 2013 3:28 UTC (Wed) by tterribe (✭ supporter ✭, #66972) [Link]

> ((x<<=1)|CarryIn)

Conveniently, x<<=1 can be implemented as x=(unsigned)x+(unsigned)x, which reduces this to a previously solved problem. But honestly if you're decoding a bitstream a bit at a time, there are better optimizations to be done.