CLR opcode workaround

[SamuraiCrow]

When generating code for the CLR opcode using a data register operand, there is a microcode bug in the 68000 CPU that can crash the system. If it hasn't been fixed already, the CLR.W D0 opcode should be implemented as EOR.W D0,D0. It's a drop-in substitute for all sizes.

[dmcoles]

interesting, do you have any further details on this bug? I am only aware of the issues that could potentially be caused by clr with hardware registers (for example) that cannot be read - which in this case EOR.W D0,D0 would not be a useful substitute.

[SamuraiCrow]

The bug only affects data register operands. Memory-direct operands generate the intended effect with CLR already.

I think this bug fix would only make a difference in the assembler opcode and the 32 bit unsigned division operation because the remainder is in the high word and the quotient is in the low word (or the other way around).

[dmcoles]

the multiply, divide and rnd functions all use clr.w. do you have any links where i can read up on this?

[SamuraiCrow]

I'm afraid not but I gave the same advice to the Scorpion Engine developer on EAB when he was getting unexplained crashes with his modulo operation and said the EOR workaround worked. It only affects the stock 68000, not 68020+ and probably not 68010 AFAIK.

[SamuraiCrow]

I did a little more reading on a long, insult-ridden EAB thread and the problem is that CLR was incorrectly classified as using read-modify-write addressing.

That means that if it was used on chip RAM the system could crash because of bus timing issues. If it was used on a data register, it would write a zero to whatever memory was recently accessed (determined by whatever the last contents of the address bus latch was set at). Either way it was unsafe on Amiga.

The standard workaround was to use MOVEQ #0,D0 but that would clear the whole register. EOR.L D0,D0 would also, but at least would set the condition code registers correctly. For clearing the bottom half of a data register, EOR.W D0,D0 is functionally equivalent to the 68020 version of CLR.W D0 in both opcode size, results and processor flags. Not bad for a substitution.