¿Por qué el código debe estar alineado con los límites de direcciones pares en x86?

Question

Estoy trabajando a través del de Kip Irvine "Assembly Language for x86 Processors, sexta edición" y estoy realmente disfrutando.

acabo de leer sobre la tecla de acceso NOP en el párrafo siguiente:

"It [NOP] is sometimes used by compilers and assemblers to align code to 
even-address boundaries." 

El ejemplo dado es:

00000000 66 8B C3 mov ax, bx 
00000003 90   nop 
00000004 8B D1  mov edx, ecx 

Luego, el libro afirma:

"x86 processors are designed to load code and data more quickly from even 
doubleword addresses." 

Mi pregunta es: Es la razón por la que esto es así es porque para los procesadores x86 a los que se refiere el libro (32 bits), el tamaño de palabra de la CPU tiene 32 bits y, por lo tanto, puede extraer las instrucciones con el NOP y procesarlas de una vez. Si este es el caso, supongo que un procesador de 64 bits con un tamaño de palabra de un quadword haría esto con un hipotético 5 bytes de código más un nop?

Por último, después de escribir mi código, ¿debo revisar y corregir la alineación con NOP para optimizarlo, o el compilador (MASM, en mi caso) hará esto por mí, como parece sugerir el texto?

Gracias,

de Scott

Answer 1

código que se ejecuta en la palabra (para 8086) o DWORD (80386 y posteriores) límites ejecuta más rápido debido a que el procesador va a buscar palabras enteras (D). Entonces, si sus instrucciones no están alineadas, entonces hay un bloqueo al cargar.

Sin embargo, no puede dword-alinear cada instrucción. Bueno, supongo que podrías, pero estarías desperdiciando espacio y el procesador tendría que ejecutar las instrucciones NOP, lo que mataría cualquier beneficio de rendimiento de alinear las instrucciones.

En la práctica, alinear código en límites dword (o lo que sea) solo ayuda cuando la instrucción es el objetivo de una instrucción de bifurcación y los compiladores alinearán típicamente la primera instrucción de una función, pero no alinearán los destinos de bifurcación que puedan también ser alcanzado por el otoño. Por ejemplo:

MyFunction: 
    cmp ax, bx 
    jnz NotEqual 
    ; ... some code here 
NotEqual: 
    ; ... more stuff here 

un compilador que genera el código normalmente se alineará MyFunction porque es un objeto de bifurcación (alcanzado por call), pero no va a alinear el NotEqual porque hacerlo sería insertar NOP instrucciones que tendría para ser ejecutado cuando se cae. Eso aumenta el tamaño del código y hace que el caso de caída sea más lento.

Sugeriría que si recién está aprendiendo el lenguaje ensamblador, que no se preocupe por cosas como esta que con mayor frecuencia le darán ganancias de rendimiento marginales. Solo escribe tu código para que las cosas funcionen. Después de que funcionen, puedes crear un perfil y, si crees que es necesario después de consultar los datos del perfil, alinea tus funciones.

El ensamblador normalmente no lo hará automáticamente.

Answer 2

Porque el procesador (16 bits) puede recuperar valores de la memoria solo en direcciones pares, debido a su diseño particular: se divide en dos "bancos" de 1 byte cada uno, por lo que la mitad del bus de datos se conecta al primer banco y la otra mitad al otro banco. Ahora, supongamos que estos bancos están alineados (como en mi imagen), el procesador puede obtener valores que están en la misma "fila".

bank 1 bank 2 
+--------+--------+ 
| 8 bit | 8 bit | 
+--------+--------+ 
|  |  | 
+--------+--------+ 
| 4  | 5  | <-- the CPU can fetch only values on the same "row" 
+--------+--------+ 
| 2  | 3  | 
+--------+--------+ 
| 0  | 1  | 
+--------+--------+ 
\ /\ /
    | | | | 
    | | | | 

data bus (to uP) 

Ahora, ya que este traiga limitación, si la CPU se ve obligado a buscar valores que se encuentran en una dirección impar (suponer 3), que tiene a buscar valores a los 2 y 3, entonces los valores a las 4 y 5 , deseche los valores 2 y 5, luego únase a 4 y 3 (está hablando de x86, que es como una pequeña distribución de memoria endia).
Es por eso que es mejor tener código (¡y datos!) En direcciones pares.

PD: En procesadores de 32 bits, el código y los datos se deben alinear en direcciones que son divisibles por 4 (ya que hay 4 bancos).

Espero que estuviera claro. :)

Answer 3

El problema no se limita solo a las recuperaciones de instrucciones. Y es desafortunado que los programadores no se den cuenta de esto temprano y lo castiguen a menudo. La arquitectura x86 ha dejado a la gente floja. Esto dificulta la transición a otras arquitecturas.

Tiene todo que ver con la naturaleza del bus de datos. Cuando tiene, por ejemplo, un bus de datos de 32 bits de ancho, una lectura de la memoria se alinea en ese límite. En este caso, los dos bits de dirección inferiores normalmente se ignoran ya que no tienen significado. Por lo tanto, si realizara una lectura de 32 bits desde la dirección 0x02, sea parte de una búsqueda de instrucciones o una lectura de la memoria. Luego se requieren dos ciclos de memoria, una lectura de la dirección 0x00 para obtener dos de los bytes y una lectura de 0x04 para obtener los otros dos bytes. Tomando el doble de tiempo, bloqueando la tubería si se trata de una instrucción de búsqueda. El rendimiento alcanzado es dramático y de ninguna manera una optimización desaprovechada para lecturas de datos. Los programas que alinean sus datos en límites naturales y ajustan estructuras y otros elementos en múltiplos enteros de estos tamaños, pueden ver tanto como duplicar el rendimiento sin ningún otro esfuerzo. De manera similar, usar un int en lugar de un char para una variable, incluso si solo va a contar hasta 10, puede ser más rápido. Es cierto que agregar nops a los programas para alinear los destinos de las sucursales generalmente no vale la pena. Lamentablemente, x86 tiene una longitud de palabra variable, basada en bytes, y usted constantemente sufre estas ineficiencias. Si está pintado en una esquina y necesita exprimir unos cuantos relojes más de un bucle, no solo debe alinearse en un límite que coincida con el tamaño del bus (en estos días 32 o 64 bit) sino también en un límite de línea de caché, y intente mantener ese bucle dentro de una o quizás dos líneas de caché. En ese sentido, un solo nop al azar en un programa puede causar cambios donde las líneas de caché tocan y se puede detectar un cambio en el rendimiento si el programa es lo suficientemente grande y tiene suficientes funciones o bucles. La misma historia, por ejemplo, si tiene un destino de sucursal en la dirección 0xFFFC, si no está en la memoria caché debe buscarse una caché, nada inesperado, pero una o dos instrucciones más adelante (cuatro bytes) se requiere otra línea de caché. Si el objetivo ha sido 0x10000, dependiendo del tamaño de su función de forma natural, es posible que haya sacado esto en una línea de caché. Si se trata de una función a la que a menudo se llama y otra función a la que se suele llamar se encuentra en una dirección lo suficientemente similar como para que estos dos se desalojen mutuamente, se ejecutará el doble de lento. Este es un lugar donde el x86 ayuda con la longitud de la instrucción variable, pero puede empacar más código en una línea de caché que en otras arquitecturas bien utilizadas.

Con x86 y recuperaciones de instrucción realmente no se puede ganar. En este punto, a menudo es inútil tratar de sintonizar a mano los programas x86 (desde una perspectiva de instrucciones). La cantidad de núcleos diferentes y sus matices, puede hacer ganancias en un procesador en una computadora un día, pero ese mismo código hará que otros procesadores x86 en otras computadoras funcionen más despacio, a veces menos de la mitad de la velocidad. Es mejor ser genéricamente eficiente pero tener un poco de descuido para que funcione bien en todas las computadoras todos los días. La alineación de los datos mostrará mejoras en los procesadores de las computadoras, pero la alineación de las instrucciones no es la misma.