所以AFAIK的syscall指令，等同于AMD的sysenter。因此，从理论上讲，人们应该只在AMD芯片上找到syscall指令，对吗？好吧，显然不是这种情况，因为我搞砸了ntdll.dll和ntdll.dll（WOW64版本），我发现常规版本使用syscall，而WOW64中的ntdll.dll使用sysenter 。为什么会这样？
仅AMD支持syscall 在32位用户空间模式下（传统模式和兼容模式）。所有x86-64 CPU都以64位模式支持它。
Intel的sysenter成为32位用户空间的首选；英特尔赢得了争夺主导权的斗争。同样，显然AMD的传统模式syscall是内核要应对的噩梦。 32位Linux内核甚至没有启用它。 64位Linux内核确实允许从支持32位用户空间（兼容模式）的AMD CPU上进行系统调用。 （一些链接指向this answer中有关内核asm入口点的相关注释。）
AMD设计了AMD64（已变为x86-64），并为syscall的工作方式定义了一种（非常好的）行为[在64位模式下与32位模式下的工作方式不同。 （例如，在64位用户空间中，它将旧的RFLAGS保存到R11中，而该模式在旧版模式中不存在，因此不能在那里执行。）
英特尔采用64位-syscall作为以与AMD兼容的方式实现其x86-64版本的一部分。（对一些实现错误进行模化，例如，如果尝试使用sysret，会发生什么情况？使用非规范的RCX用户空间返回地址；在Intel上，故障的发生是特权级别= ring 0，但对于RSP，仍然是已恢复的用户空间堆栈=>另一个线程可以接管内核。仅在已知RCX安全的情况下安全使用它。）
syscall是有效的，可满足内核开发人员的需求。因此不需要分派来选择在当前CPU上运行的指令。