Comment by sfink
I don't know, but one reason might be that with 8-bit opcodes you only have 256 instructions to play with, and many of those encode registers, so ZEROAX is burning a meaningful percentage of your total opcode space. And if you're not encoding it into a single byte, then it's pure waste: you already need XOR (and SUB), so you'd just be adding a redundant way of achieving the same thing. (Note that this argument doesn't completely hold up, since eg the 6502 had a fair number of undocumented opcodes largely because they didn't need all of them.)
Though technically you said "assembler macro", not opcode. For that, I suspect the argument is more psychological: we had such limited resources of all sorts back then that being parsimonious with everything was a required mindset. The mindset didn't just mean you made everything as short as possible, it also meant you reused everything you possibly could. So reusing XOR just felt more fitting and natural than carving out a separate assembler instruction name. (Also, there would be the question of what effect ZEROAX should have on the flags, which can be somewhat inferred when reusing an existing instruction.)
I meant something defined in the assembler along the lines of
where it was defined with a semantically meaningful name, but emitting the exact same opcodes as when writing it out. I mean, I guess taking that to the logical extreme, you'd end up with... C. I dunno, it just seemed like the sort of thing that would have caught on my convention.I use to write lots of 6502 and 68k assembler, and 68k especially tended to look quite human-readable by the time devs ended up writing macros for everything. Perhaps that wasn't the same culture around x86 asm, which I admit I've done far, far less of.