[email protected] wrote:
You neglected to tell gcc that bcd_a is a
necessary *input* to the asm, so it might optimize away previous
instructions that set the value. You need either
asm("CLRC\n\tDADD.W %1,%0" : "+r" (bcd_a) : "r" (bcd_b) );
or
asm("CLRC\n\tDADD.W %1,%0" : "=r" (bcd_a) : "r" (bcd_b), "0" (bcd_a));
Right.
Note that you don't need the "A" modifier unless you're accessing part
of a multi-word operand. You would use it for a 32-bit add:
asm("CLRC\n\tDADD.W %A1,%A0\n\tDADD.W %B1,%B0" : "=r" (bcd_a) : "r" (bcd_b),
"0" (bcd_a));
True, but harmless.
You can also let it use the full range of possible addressing modes:
asm("CLRC\n\tDADD.W %1,%0" : "+ro" (bcd_a) : "g" (bcd_b) );
Yeah, but I'm not sure that makes any difference in this case. Does it?
Amd, further, let it know that the operation is commutative:
asm("CLRC\n\tDADD.W %1,%0" : "=ro" (bcd_a) : "%g" (bcd_b), "0" (bcd_a));
Now I don't follow you. The dadd instruction is certainly not
commutative. Since that is all you have here, how would the overall
operation be commutative when the final answer is still constrained to
be in bcd_a?
Now if I defined a third variable, say bcd_c, and made that the output
of the assembly code, and then returned that from the original full bcd
addition static inline function, I see how that would become
communtative. Right now, I don't follow you.
And, I suppose, for completeness' sake, tell gcc that a memory
destination is slow and to be avoided if possible:
asm("CLRC\n\tDADD.W %1,%0" : "=r,o?" (bcd_a) : "%g,g" (bcd_b), "0,0"
(bcd_a));
Does this actually do anything. The compiler is free to choose
addressing modes, so surely it just grabs from and stuffs to whereever
fits best.
Some gcc platforms require a final `: "cc"' clobber at the end, to
indicate that the condition codes are modified; other platforms assume
it. I don't know which applies to mspgcc.
I've always assumed it was assumed in mspgcc. Any input on that, Dmitry?
Regards,
Steve
