CompuServe Messages

Bart, If you can _guarantee_ that A4 and A5 are pointing to even addresses, your best bet is to use move.l #0(a5)+ etc. (20 clock cycles per 4 bytes, as compared to 12 cycles per byte) I don't know why you'd rather not pad the memory to achieve this – what's a byte, after all? Your use of a loop, as you say, will be much slower. Can your assembler handle repeat loops? On mine, I can do: REPT 4 move.b #0,(a4)+ move.b #0,(a5)+ ENDR This _looks_ like a loop, but will generate code much like your original version. Personally, I prefer writing it out in full in this case, to make it clearer that I could not use a more efficient technique. As for the relative speed of ANDI vs. BCLR – my book is ambiguous (due to bad printing). If the difference was important to you, you could write a loop to execute the instruction a large number of times, and time it with a watch. I would be inclined to use the BCLR approach if the bit in question was used as a flag (using an equate for the value 7) – i.e. to match with a BSET or BTST. I would use the ANDI approach if I were merely masking out bits which I wanted zeroed. In fact, with ANDI, I might even write the value in binary (with leading zeroes) to make it clearer which bits were affected. Put another way, I would choose my coding to reflect my intention. This would help me with debugging in the future. Regards, Shraddhan – via Whap! from Hertfordshire in the UK