Setting A register to zero is very widespread operation and I wonder why it performs such an unoptimized way. Replace it with "xor a" operation is better solution. This can be done in code but since we have useful peephole optimization engine we can use it.
I'm not sure, may be this optimization can be applied to gbz80 and r2k, I never worked with such MCU's.
A new conditional would need to be created for the peephole rules that would check to see if the arithmetic flags (carry, zero, etc) were used (after the xor a,a) and before being set by another instruction (add, sub, rla, etc).
The "ld a,#0" does not affect the flags, however "xor a,a" does. For example:
rr a
ld a,#0
rla a
gives a different result than:
rr a
xor a,a
rla a
And there is currently no conditional available in the peephole optimizer to check if
the arithmetic flags must be preserved.
I was just going to mention the problem with the carry bit being cleared, but I see Lee was quicker. This is not just a theoretical problem; for example, the following C code would generate a mangled result with this peephole rule:
int x;
void foo(void) { x = -x; }
I think this is better handled in the code generator.
Related
Wiki: z80
Closing this item, since this has to be handled in the code generator (at least until we have a conditional for flags - and then the rules would have to be rewritten). In fact the code generator already does this in some places, though apparently not enough.
Philipp
In revision #7983, in the smallopts branch, code generation has been improved to use xor a,a more often.
Most important, it is now uses to get zero that is pushed on the stack, or used as the first byte of a left operand of a subtraction.
Philipp