Open pdarragh opened 8 months ago
Hmmm. The only reason we have eax is to support our encoding of strings where we pack two characters per 64-bit word. One option is to drop eax. We could keep the string encoding by reading a 64-bit word and then zeroing out the lower or upper half after the read. Without eax, we wouldn't have to worry about register size agreement.
We also have the cl
register, but I don't think that's used.
We could also simplify the encoding of strings to just use a word per character and leave the packed representation as an exercise. In any case, I lean toward the simpler machine model where everything is 64-bits.
A student attempted to compile this code:
and they got this error:
Apparently, the specification of
and
cares about the order of the operands: if the left operand is only 32 bits wide (e.g.,eax
), then the second operand can only be 32 bits wide. However, if the first operand is 64 bits wide (e.g.,rax
), then the second operand can be of any lesser width (e.g.,eax
) and that second operand will be sign-extended.So we'll want to update the checks in the a86 instructions to look for this, and then update the course notes accordingly. I assume
and
is not the only instruction featuring this behavior, so we'll have to look through the others to see what else ought to be changed.