为什么在x86操作系统上运行16位程序会变慢? [英] Why run 16-bit programs on x86 operating systems get slower?
问题描述
我正在研究有关汇编的一些知识，以及正在阅读的材料，作者说，为16位编译的程序在x86操作系统上的旋转速度较慢，而对于x64而言，同样的情况，在32位编译的程序上，运行速度较慢. x64 ...
为什么会这样? 在计算机内存和处理器中发生了什么，因此16位或32位程序的计算机分别以32位和64位的速度旋转得更慢?
在32位系统中，运行速度较慢的大约16位程序，我可以告诉您. 当英特尔从16位升级到32位时，他们不得不扩展指令集以应对新的32位寄存器，但要保持与16位程序的二进制兼容性.
为此，他们加了一个前缀，如果我记得很好，则为66h，即当它应用于使用16位寄存器的任何指令时，会使该指令使用32位寄存器.
例如，以66h为前缀的16位指令(如MOV AX，BX)变成MOV EAX，EBX
但是这将对新的32位指令施加惩罚，因为它们至少需要一个额外的内存提取周期才能执行.然后，英特尔创建了所谓的32位段和16位段.
基本上，任何代码段都必须驻留在代码段中.在80386之前，所有段都使用16位指令，并且假定所有指令都使用16位寄存器.
Intel的32段也包含代码，但是这次假设每个指令都使用32位寄存器，因此在32位段中，MOV EAX，EBX的操作码与MOV AX的操作码相同， BX在16位段中.
这使程序不必为每个32位指令使用66h前缀.不再有惩罚了.
但是...如果我必须在被分为32位段的程序中使用16位寄存器，该怎么办?这些使用16位寄存器的指令必须使用前缀66h.
因此:使用16位寄存器的指令在16位段中没有前缀，而在32位符号中带有前缀.使用32位寄存器的指令在32位段中没有前缀，在16位段中没有前缀.
此外:从奔腾处理器开始，我们有两个并行执行指令的管道.对于要使用的这些管线，输入它们的指令必须属于Intel所称的"RISC核":指令的子集不再在CPU内部作为微程序执行，而是使用有线逻辑.你猜怎么了?前缀指令和使用16位寄存器在16位段中执行的代码不属于该组，因此不能与另一组并行执行.当带前缀的指令设法进入其中一个流水线时，另一条流水线会停滞，从而影响CPU的性能.
I'm studying some things about assembly, and the material I'm reading, the author said that programs compiled for 16-bit rotate more slowly on x86 operating systems and the same goes for x64, 32bit compiled programs run slower on x64...
Why does this happen? What happens in the computer memory and the processor, so that programs 16bits or 32bits machines rotate more slowly in 32 bits and 64 bits, respectively ?
About 16 bit programs running slower in 32 bits systems, I can tell you about that. When Intel went from 16 bits to 32 bits, they had to expand the instruction set to cope with the new 32-bit registers, but maintaining binary compatibility with 16-bit programs.
To accomplish that, they added a prefix, 66h if I remember well, that when applied to any instruction that uses 16 bit registers, makes that instruction to use 32 bit registers.
For instance, a 16-bit instruction, like MOV AX,BX, prefixed with 66h, turns into MOV EAX,EBX
But this then imposes a penalty on the new 32 bit instructions, because they need at least an extra memory fetch cycle to get executed. Intel then created the so called 32-bit segments and 16-bit segments.
Basically, any piece of code must reside in a code segment. Before the 80386, all segments used 16-bit instructions, and all instructions are assumed to use 16 bit registers.
Intel's 32-segment contain code as well, but this time every instruction is assumed to use 32 bit registers, so in a 32-bit segment, the opcode of MOV EAX,EBX is the same as the opcode of MOV AX,BX in a 16-bit segment.
This allows a program to not having to use the 66h prefix for every 32-bit instruction. There's no penalty anymore.
But... what if I have to use 16-bit registers within a program that is conained into a 32-bit segment? Those instructions using 16-bit registers will have to use the prefix 66h.
So: instructions that use 16-bit registers are unprefixed in 16-bit segments and prefixed in 32-bit semgnts. Instructions that use 32-bit registers are unprefixed in 32-bit segments and prefixed in 16-bit segments.
Besides: starting with the Pentium processor, we have two pipelines for executing instructions in parallel. For these pipelines to be used, instructions entering them must belong to what Intel names "RISC nucleus": a subset of instructions that are no longer executed as a microprogram inside the CPU, but using wired logic. Guess what? Prefixed instructions, and code executing in a 16-bit segment using 16-bit registers don't belong to this group and therefore, cannot execute in parallel with another one. When a prefixed instruction manages to enter one of the pipelines, the other is stalled, thus affecting the perfomance of the CPU.
这篇关于为什么在x86操作系统上运行16位程序会变慢?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
