Exercise 2: How x86-64's Prefixes Extend cpu8bit1-5's Own Z80 Trick — Possible Solution
====================================================================

CPU8BIT1-5'S ORIGINAL MECHANISM
------------------------------
Per cpu8bit1-5, the Z80's CB/DD/ED/FD prefix bytes work by reserving
four specific byte values as SIGNALS rather than ordinary
instructions: each one tells the CPU "look up the next byte in a
separate, additional table of instructions, not the normal one" —
effectively unlocking several extra 256-value opcode spaces layered
on top of the original single-byte space, without ever disturbing the
original 8080-compatible encodings.

X86-64'S OWN VERSION OF THE SAME IDEA
------------------------------
Per this chapter's own explanation, the 0x0F escape byte works
exactly the same way — a specific byte value that signals "the
following byte(s) should be looked up in a separate, additional
opcode table," unlocking an entire second table of instructions
beyond the original single-byte space, the same underlying mechanism
as the Z80's own prefixes.

The REX prefix, also covered in this chapter (and first named back in
assembly2-2), works similarly but unlocks a different kind of
extension: rather than selecting an alternate instruction table, it
signals "interpret the registers in this instruction using the
extended 64-bit register set (including R8-R15) and/or 64-bit operand
width," extending what an ordinary instruction byte can express
without needing an entirely separate mnemonic for every register/width
combination.

WHY THIS IS THE SAME TRICK, JUST APPLIED FURTHER
------------------------------
Both mechanisms — the Z80's four prefixes and x86-64's own several —
solve the identical underlying problem this chapter names: a single
opcode byte can only distinguish 256 things, and a genuinely richer
instruction set needs more distinct instructions than that. Rather
than redesigning the whole opcode-byte scheme from scratch, both
architectures solve it by reserving specific byte values as
"look elsewhere" signals, unlocking additional opcode space layered
on top of what already exists. x86-64 simply applies this same idea
across MORE layers (0x0F, REX, and further SIMD-specific escape
sequences this chapter previews for assembly2-9) than the Z80's four
prefixes ever needed to.

WHY THIS WORKS AS AN ANSWER
------------------------------
It restates the Z80's own prefix mechanism accurately from cpu8bit1-5,
explains what x86-64's own 0x0F escape and REX prefix each
specifically unlock, and explicitly identifies the shared underlying
principle (a reserved byte value signaling "look in a different
table/interpretation" to escape the 256-opcode ceiling) rather than
just asserting the two are "similar."