Thanks for the reply. I scrolled a lot through the i386 md and c files. I
notice that the i386 architecture has dedicated
instructions for comparing values and ALU instructions only specify
(clobber (reg:CC FLAGS_REG)). What I do not understand is how they specify
the way ALU instructions affect the flags.
In order to set the flags, I am trying something like this:
(define_expand "addsi3"
[( parallel [(set (match_operand:SI 0 "register_operand" "")
(plus:SI (match_operand:SI 1 "register_operand" "")
(match_operand:SI 2 "nonmemory_operand" ""))
)
(set (reg:CC FLAGS_REG) (compare:SI (match_dup
1) (match_dup 2)))]
)]
""
"
if(GET_CODE(operands[2])==CONST_INT && INTVAL(operands[2])==1){
emit_insn(gen_inc(operands[0], operands[1]));
DONE;
}
"
)
and to use them:
(define_insn "beq"
[(set (pc)
(if_then_else (eq:SI (reg:CC FLAGS_REG) (const_int 0))
(label_ref
(match_operand 0 "" ""))
(pc)
)
)]
""
"jeq \\t%l0"
)
but that does not look right. The carry and zero flags should be set after
the operation and the less than and equal, before the sum is done, since
the destination register can just as well be the same with one of the
sources. The "parallel" statement, afaik, tells the compiler to evaluate
the operands first, then execute both insns which means that all flags
will be set with the state of the operands before the operation.
I am probably a bit confused about the compiler behavior since I am
thinking more like in the way of machine execution. The compiler doesn't
know the values of the operands at compile time, so it doesn't really set
any flags in the condition register. How does it work then?
Sorry for the large text and thanks again for your time.
> "Radu Hobincu" <radu.hobi...@arh.pub.ro> writes:
>
>> I have written here a few weeks ago regarding some tutorials on GCC
porting and got some very interesting replies. However, I seem to have
gotten stuck with a couple of issues in spite of my massive Googling, and
>> I was wondering if anyone could spare a couple of minutes for some
clarifications.
>> I am having troubles with the condition codes (cc_status). I have
looked
>> over a couple of architectures and I do not seem to understand how they
work.
>> The machine I am porting GCC for has 1 4bit status register for carry,
zero, less than and equal. I do not have explicit comparison
>> instructions,
>> all of the ALU instructions modify one or more flags.
>> What I figured out so far looking over AVR and Cris machine
descriptions
>> is that each instruction that modifies the flags contain an attr
declaration which specify what flags it is changing. Also, there is a
macro called NOTICE_UPDATE_CC which sets up the cc_status accordingly by
>> reading this attr. This is the part of the code I do not understand.
There
>> are certain functions for which I could not find any descriptions, like
"single_set" and macros like "SET_DEST" and "SET_SRC". Also, looking over
>> conditions.h, I see that the CC_STATUS structure contains 2 rtx fields:
"value1" and "value2", and also an int called "flags". What do they
represent? Is "flags" the contents of the machine's flag register?
>
> For a new port I recommend that you avoid cc0, cc_status, and
> NOTICE_UPDATE_CC. Instead, model the condition codes as 1 or 4
> pseudo-registers. In your define_insn statements, include SET
> expressions which show how the condition code is updated. This is how
the i386 backend works; see uses of FLAGS_REG in i386.md.
>
> As far as things like single_set, SET_DEST, and SET_SRC, you have
reached the limits of the internal documentation. You have to open the
source code and look at the comments. Similarly, the description of the
CC_STATUS fields may be found in the comments above the
> definition of CC_STATUS in conditions.h.
>
> Ian
>
