为什么64位模式的英特尔微处理器不支持MOV AH，1？
在Barry B. Brey的《智能微处理器》一书中写道
MOV AH, 1
在64位模式下不允许，但在32位或16位模式下允许。如果可以在64位模式下允许MOV AL，1，那么MOV AH，1有什么问题？
共有2个答案
另请注意，根据英特尔优化手册，一些处理器不鼓励使用8位寄存器，而另一些则不鼓励。目前，只鼓励骑士登陆，但在未来，8位和16位指令工作速度较慢的处理器列表可能会增加。英特尔在手册中写道：
在8位或16位寄存器上操作的指令在骑士登陆微架构中没有在硬件上进行优化。一般来说，使用在32位或64位通用寄存器上操作的整数指令比8位或16位寄存器更快。
虽然Knights Landing不是通用CPU，但我预计未来所有处理器上的趋势可能是下一个重大微体系结构变化，即自Icelake微体系结构以来，这是基于10nm节点的Intel CPU微体系结构，预计将在2019年取代Cannonlake-8位和16位寄存器操作将很慢，而不仅仅是写，但阅读也（免责声明：我的这一预期纯属猜测）。
因此，回到寄存器-你不能在64位模式下编码，例如movzx r8，ah，但你可以用寄存器本身编码任何东西，例如mov ah，1，因为AMD设计了64位模式，旧指令的编码方式与旧32位模式相同。
mov ah，1没有问题。它在X64模式下运行良好。
它的操作码是b4 01。
唯一不允许mov ah的时候是mov有REX前缀的时候。
发件人：http://www.felixcloutier.com/x86/MOV.html
***在64位模式下，如果使用REX前缀，则无法对r/m8进行编码以访问以下字节寄存器：AH、BH、CH、DH。
在这种情况下，高字节寄存器（AH、BH、CH和DH）被重新定义为DIL、SIL、BPL和SPL。但这仅限于存在REX前缀的情况。
带有REX前缀的指令包括：
anything with the R8..R15 regs and parts thereof
anything that accesses the new 8 bit regs: DIL, SIL, BPL, SPL
anything that accesses 64 bit registers.
-
问题内容： 从我读到的内容来看，它用于修复CPU中的错误，而无需修改BIOS。根据我对汇编的基本知识，我知道汇编指令在内部由CPU分解为微代码，并相应地执行。但是intel以某种方式可以在系统启动和运行时进行一些更新。 有人有更多信息吗？是否有关于微码可以做什么以及如何使用的文档？ 编辑：我读过维基百科的文章：没弄清楚我怎么能自己写一些，以及它有什么用。 问题答案： 在较早的时期，微代码在CPU中
-
我想从mysql读取数据，然后写入sftp。现在我将文件写入本地，从本地写入sftp，最好的方法是什么？
-
众所周知，NaN在算术中传播，但我找不到任何演示，所以我写了一个小测试： 这个例子（在这里实时运行）基本上产生了我所期望的（消极有点奇怪，但它有点道理）： 2015年MSVC奥运会产生了类似的东西。然而，英特尔C 15生产: 具体来说，。 这...不可能是对的，对吧？相关标准(ISO C，ISO C，IEEE 754)对此有什么说法，为什么编译器之间的行为会有差异？
-
在《英特尔内部指令指南》中指出，名为“sqrtsd”的指令的延迟为18个周期。 我用自己的程序测试了它，例如，如果我们将0.15作为输入，它是正确的。但是当我们取256（或任何2^x）数字时，延迟只有13。为什么？ 我的一个理论是，由于13是“sqrtss”的延迟，这与“sqrtsd”相同，但在32位浮点上完成，那么处理器可能足够聪明，能够理解256可以容纳在32位中，因此使用该版本，而0.15需
-
我一直在思考为什么JDBC只是阻塞操作，为什么我不能为假设的事件处理程序onResultSetArrived（ResultSet rs）设置一些侦听器。为什么我必须为每个JDBC查询阻塞一个线程。 过了一段时间，我深入研究了Java套接字（我想JDBC是构建在它们之上的），并意识到也没有任何事件处理。提供非阻塞读取的唯一选项是通过available（）方法，但这非常低效，因为必须在循环中定期检查它
-
gRPC基于HTTP/2，浏览器广泛支持HTTP/2（假设）。因此，我觉得从浏览器使用gRPC应该没有问题。 然而，很明显有一个问题。协议grpc web是不同的，因为“由于浏览器限制”而存在。还有许多博客文章描述了为让gRPC从浏览器工作而部署的复杂技术堆栈。 我忽略了实际的问题——为什么gRPC不只是在浏览器上工作？