Tag: cpu registers

x86_64寄存器rax / eax / ax / al覆盖整个寄存器的内容: 正如广泛宣传的那样，现代x86_64处理器有64位寄存器，可以以32位寄存器，16位寄存器甚至8位寄存器的后向兼容方式使用，例如： 0x1122334455667788 ================ rax (64 bits) ======== eax (32 bits) ==== ax (16 bits) == ah (8 bits) == al (8 bits) 这样的scheme可以从字面上理解，也就是说，人们总是只能使用指定的名称来访问寄存器的一部分，以便读写，这是非常合乎逻辑的。实际上，对于高达32位的所有内容都是如此： mov eax, 0x11112222 ; eax = 0x11112222 mov ax, 0x3333 ; eax = 0x11113333 (works, only low 16 bits changed) mov al, 0x44 ; eax = 0x11113344 (works, only low 8 […]

如何知道variables是在寄存器中还是在堆栈中？: 我正在阅读这个关于isocpp FAQ的 inline 问题，代码是这样给出的 void f() { int x = /*…*/; int y = /*…*/; int z = /*…*/; // …code that uses x, y and z… g(x, y, z); // …more code that uses x, y and z… } 那就这么说了假设一个典型的具有寄存器和堆栈的C ++实现，寄存器和参数在调用g()之前被写入堆栈，然后参数从g()的堆栈中读取并再次读取以恢复寄存器g()返回到f() 。但是这是很多不必要的读写，特别是在编译器能够使用variablesx ， y和z寄存器的情况下：每个variables可以被写两次（作为寄存器并且也作为参数）并被读两次（当在g()并在返回f()期间恢复寄存器。我很难理解上面的段落。我尝试列出我的问题如下：为了使计算机对驻留在主存储器中的一些数据进行一些操作，数据必须首先被加载到某些寄存器，然后CPU才能对数据进行操作。（我知道这个问题与C ++没有特别的关系，但是理解这个将有助于理解C ++是如何工作的。）我认为f()是一个函数，与g(x, […]

如果登记册太快了，为什么我们没有更多呢？: 在32位，我们有8个“通用”寄存器。与64位，金额翻倍，但它似乎独立于64位变化本身。现在，如果寄存器速度如此之快（没有内存访问），为什么自然不会有更多？ CPU制造商不应该将尽可能多的寄存器工作到CPU中吗？为什么我们只有我们拥有的金额有什么逻辑限制？

为什么基于JVM栈和Dalvik VM寄存器？: 我很好奇，为什么Sun决定创build基于JVM栈，而Google决定制作基于DalvikVM寄存器的？我猜想JVM不能真的假定在目标平台上有一定数量的寄存器可用，因为它应该是平台独立的。因此，它只是推迟寄存器分配等，到JIT编译器。（如我错了请纠正我。）所以，Android的人认为，“嘿，这是无效的，让我们立即注册基于VM …”？但是，等等，有多种不同的Android设备，Dalvik目标有多less个寄存器呢？ Dalvik操作码是否针对一定数量的寄存器进行硬编码？目前市场上所有的Android设备都拥有相同数量的寄存器吗？或者，是否有在dex-loading期间执行的寄存器重新分配？这一切如何融合在一起？

为什么大部分的x64指令会将32位寄存器的上半部分清零？: 今天我了解了x64程序集（资料来源： http : //x86asm.net/articles/x86-64-tour-of-intel-manuals/ ）也许最令人惊讶的事实是，诸如MOV EAX，EBX之类的指令自动将RAX寄存器的高32位清零。英特尔文档（3.4.1.1通用基本体系结构中的64位模式的通用寄存器）在同一来源中引用告诉我们： 64位操作数在目标通用寄存器中生成一个64位结果。 32位操作数产生一个32位结果，在目标通用寄存器中零扩展为一个64位结果。 8位和16位操作数生成8位或16位结果。目标通用寄存器的高56位或48位（分别）不会被操作修改。如果8位或16位操作的结果是用于64位地址计算的，则明确地将寄存器扩展为完整的64位。在x86-32汇编中，16位指令如 mov ax, bx 不要performance出这种eax的上位字“零”的“奇怪”的行为。因此：这种行为被引入的原因是什么？乍一看这似乎不合逻辑（但原因可能是我习惯了x86-32汇编的怪癖）。