与 AArch64 与 ARM 32 位不同，它甚至不是一种单独的机器代码格式。我认为您很难将 x86-64 与 x86 分开，即使您遗漏了“传统模式”（即能够像仅 32 位 CPU 一样工作，直到/除非您启用 64位模式）。
x86-64 的 64 位模式使用相同的操作码和指令格式（大多只是一个新前缀 REX）。 https://wiki.osdev.org/X86-64_Instruction_Encoding。我怀疑有人会争辩说它与 x86 或任何所需的专利标准有很大不同。 （虽然这方面的专利可能早就过期了，如果是 8086 的话）。
特别是考虑到长模式包括 32/16 位“兼容”子模式 (https://en.wikipedia.org/wiki/X86-64#Operating_modes)，并使用英特尔现有的 PAE 页表格式。
但请注意，英特尔和 AMD 之间的许多专利共享内容是用于实现技术，例如处理 push/pop/call/ret 的修改堆栈指针部分的“堆栈引擎”，让它解码为 1 uop 并通过 RSP 避免延迟链。或 IT-TAGE 分支预测（Intel Haswell、AMD Zen 2）。或者也许是解码到微指令的整个概念，英特尔在 1995 年首次使用 P6 (Pentium Pro) 实现了这一点。
大概还有一些关于 ISA 扩展的专利，例如 SSE4.1 和 AVX，对于大多数用途而言，如果没有这些扩展，CPU 就没有吸引力了。 （SSE2 是 x86-64 的基线，因此您需要它。同样，指令和机器代码格式与 32 位模式相同。）
顺便说一句，您必须发明一种启动方式，以需要启用分页的长模式启动。那么也许可以通过某些地址范围的直接映射来启动？或者发明一种新的长模式子模式，允许禁用分页，直接使用物理地址。
固件可以处理这个问题并通过 64 位 UEFI 启动，这可能允许 64 位操作系统在不修改的情况下运行，只要它们永远不会退出长模式。
请注意，AMD 在设计 AMD64 时，有意保持 x86 的可变长度难以解码的机器码格式尽可能不变，并尽可能少做其他更改。
这意味着 CPU 硬件不需要单独的解码器或在执行单元中单独处理即可在 64 位模式下运行。 AMD 不确定 AMD64 是否会流行起来，并且大概不想在几乎没有人利用它的情况下陷入需要大量额外晶体管来实现 64 位模式的困境。
（即使在他们的第一代 K8 芯片的实践中也是如此；在 64 位 Windows 普及之前几年，运行仍在不断发展的 amd64 端口的发行版的 GNU/Linux 用户仅占市场的一小部分早在 2003 年。）
不幸的是，这意味着与 AArch64 不同，AMD64 错过了清理 x86 的一些小缺陷的机会（比如提供 setcc r/m32 而不是不方便的 setcc r/m8 是我最喜欢的例子，我会为64 位模式与 16 和 32 的操作码。）
我明白为什么他们不想完全重新设计机器码格式并需要一种全新的解码方法；以及成本高昂的硅片，这将迫使工具链软件（组装器/反汇编器）进行更多更改，而不是对现有工具进行大部分细微更改。这将略微提高采用 x86 扩展的障碍，这对他们击败 IA-64 至关重要。
（IA-64 在当时是 Intel 的 64 位 ISA，其语义与 x86 大不相同，因此甚至无法共享大部分后端。在大多数情况下重新设计机器代码是可能的虽然与 x86 的指令语义相同。有关这一点的更多信息，请参阅Could a processor be made that supports multiple ISAs? (ex: ARM + x86)：如果 ISA 基本相同，则单独的前端为共同的后端提供服务完全可以工作，就像大多数情况下不同的机器代码格式一样语义相同。）