gcc uses its own status register cc0 that is set as a result of
"compares" and operators such as EQ,LT,GT. This is effectively a
translation of the avr status register effects for signed/unsigned
operations. So after each instruction gcc know what status is available
or not.
This "register" may be set implicit from an operation (often implied
compare with zero) or from a specific compare.
unsigned CARRY is a special case. It is really an overflow during an
operation and cannot be equated to a compare operation. So it does not
fit gcc model.
One might argue that carry is the result of a compare with largest
integer value (255 for bytes). But these situation do not directly arise
in "C" - or I assume any other supported language - so it is not
considered. (Though the ability to propage carry would indeed help
create mode independent arithmetic operation.).
The cc0 system at present cannot deal with instruction between the
"setter" and the "user" of cc0. Tracking avr status register effects is
already there to support this - but the rest of gcc does not fully
utilize this.
Some of this limitation is often hidden in the final code by back end
optimization - so it may appear at times that gcc is smarter than I
describe.
There has been some suggestion of changing gcc cc0 based system, But as
yet, nobody has completely figured out a way of doing it.
Andy
Wouter van Gulik wrote:
I have not dug enough into the details of gcc, but I thought that
flags were only visible at a low level, such as in the avr.md file,
where you are defining the assembly code sequences for different
effects. Thus it is possible to define a 16-bit addition instruction
with an "add, adc" sequence - but you can't really make use of the
carry flag after that.
Yes this is exactly what I wanted to point out. The carry is now only
used in handwritten assembler (in avr.md). GCC's RTL does not know
anything about the carry bit being available when it's set/cleared and
when it's clobbered.
HTH,
Wouter
_______________________________________________
AVR-GCC-list mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
_______________________________________________
AVR-GCC-list mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
