They wanted some sort of backwards ccompatibility at the assembly language level, the idea being that 8008 assembly code could be fed to an 8080 assembler. Not sure how well that worked out in practice, but that would be a motivation for A remaining a language-level feature that refers to the 8 bit part.

No. because you still have the opcodes that operate on just 64/32/16/8 bits of the register.

Aren't those AL and AH? When we rename A to AL, why do we need to permanently retire the term "A"? The L in AL stands for "low"; what does the A stand for?

The A stands for AL, in a snippet of 8008 assembly code that you're supposed to be able to use in the middle of 8080 assembly code, and dwhich is written in a language that knows nothing about AL or AX. Or that was the idea.

Thanks. So it's not so much that "you still have the opcodes that operate on just 64/32/16/8 bits" as "ASCII assembly code for any CPU is expected to be source-compatible with ASCII assembly code for any later CPU"?

Is there any indication in the source demarcating the 8008 assembly from the 8080 assembly?

But was that ever supported in practice? I don't remember that being supported, and 8008 assembly code needed to be translated anyways by a tool, so that could have taken care of A -> AL.

Accumulator.

You're missing my point. AL is the "L"ow bits of the "A" register. AH is the "H"igh bits of the "A" register. The whole thing, low plus high, is the "A" register. We can tell that by the names AL and AH.

> The whole thing, low plus high, is the "A" register.

Well, it's the "AX" register.