Exercise 2: Tracing MOV EAX, 0 — Possible Solution
====================================================================

STARTING VALUE
------------------------------
RAX = 0xFFFFFFFF12345678
  Upper 32 bits (bits 63-32): 0xFFFFFFFF
  Lower 32 bits (bits 31-0):  0x12345678

THE INSTRUCTION
------------------------------
MOV EAX, 0 writes the value 0 into EAX — the low 32 bits of RAX.

APPLYING THIS CHAPTER'S OWN RULE
------------------------------
Per this chapter's own warn-box, writing to a 32-bit sub-register like
EAX doesn't just set those 32 bits to the new value — it ALSO
automatically zeroes the upper 32 bits of the full 64-bit register,
regardless of what they held before.

RESULT
------------------------------
- The lower 32 bits become 0x00000000 (the literal value written).
- The upper 32 bits are ALSO forced to 0x00000000, per the 32-bit-
  write-zero-extends rule.

So RAX afterward = 0x0000000000000000 — entirely zero.

WHY IT'S NOT 0xFFFFFFFF00000000
------------------------------
0xFFFFFFFF00000000 would be the result if writing EAX behaved the
same way writing AX or AL does — only touching its own bit range and
leaving everything above it completely untouched (per this chapter's
own AL/AX-only-touches-its-own-bits explanation). But 32-bit writes
are explicitly the ONE case this chapter flags as behaving
differently: they zero-extend into the full 64-bit register rather
than leaving the upper half alone. Assuming EAX behaves like AX/AL
would (only clearing the low 32 bits, leaving 0xFFFFFFFF sitting in
the upper 32) is exactly the mistake the warn-box is written to
prevent.

WHY THIS WORKS AS AN ANSWER
------------------------------
It applies the exact rule from the chapter's own warn-box to the
given starting value, arrives at the fully-zeroed final RAX value,
and explicitly explains why the more "intuitive" wrong answer
(0xFFFFFFFF00000000) would only be correct if EAX behaved like AX/AL
— which this chapter states plainly that it does not.