tipos - tamaño de palabra informatica
¿Por qué la CPU accede a la memoria en un límite de palabra? (4)
Escuché mucho que los datos deben estar correctamente alineados en la memoria para una mejor eficiencia de acceso. Memoria de acceso a la CPU en un límite de palabra.
Así que en el siguiente escenario, la CPU tiene que hacer 2 accesos de memoria para obtener una sola palabra.
Supposing: 1 word = 4 bytes
("|" stands for word boundary. "o" stands for byte boundary)
|----o----o----o----|----o----o----o----| (The word boundary in CPU''s eye)
----o----o----o---- (What I want to read from memory)
¿Por qué debería pasar esto? ¿Cuál es la causa raíz de la CPU que solo se puede leer en el límite de la palabra?
Si la CPU solo puede acceder al límite de palabra de 4 bytes, la línea de dirección solo debe necesitar 30 bits, no 32 bits de ancho. Porque los últimos 2 bits son siempre 0 en el ojo de la CPU.
AGREGAR 1
Y aún más, si admitimos que la CPU debe leer en el límite de la palabra, ¿por qué no puede comenzar el límite en el lugar donde quiero leer? Parece que el límite está fijado en el ojo de la CPU.
ADD 2
Según AndreyT , parece que la configuración del límite está cableada y está cableada por el hardware de acceso a la memoria. La CPU es inocente en lo que a esto respecta.
Muchas gracias...
El significado de "puede" (en "... la CPU puede acceder ...") en este caso depende de la plataforma de hardware.
En la plataforma x86, las instrucciones de la CPU pueden acceder a datos alineados en absolutamente cualquier límite, no solo en "límite de palabra". El acceso mal alineado puede ser menos eficiente que el acceso alineado, pero las razones no tienen absolutamente nada que ver con la CPU. Tiene todo que ver con cómo funciona el hardware de acceso a memoria de bajo nivel subyacente. Es muy posible que en este caso el hardware relacionado con la memoria tenga que hacer dos accesos a la memoria real, pero eso es algo que las instrucciones de la CPU no conocen y no necesitan conocer. En lo que respecta a la CPU, puede acceder a cualquier dato en cualquier límite. El resto se implementa de forma transparente a las instrucciones de la CPU.
En plataformas de hardware como Sun SPARC, la CPU no puede acceder a datos desalineados (en pocas palabras, su programa se bloqueará si lo intenta), lo que significa que si por alguna razón necesita realizar este tipo de acceso desalineado, tendrá que implementar manual y explícitamente: divídalo en dos (o más) instrucciones de CPU y, por lo tanto, realice dos (o más) accesos de memoria explícitamente.
En cuanto a por qué es tan ... bueno, así es como funciona el hardware moderno de memoria de computadora. Los datos deben estar alineados. Si no está alineado, el acceso es menos eficiente o no funciona en absoluto.
Un modelo muy simplificado de memoria moderna sería una cuadrícula de celdas (filas y columnas), cada celda almacenando una palabra de datos. Un brazo robótico programable puede poner una palabra en una celda específica y recuperar una palabra de una celda específica. Uno a la vez. Si sus datos se distribuyen en varias celdas, no tiene más remedio que hacer varios viajes consecutivos con ese brazo robótico. En algunas plataformas de hardware, la tarea de organizar estos viajes consecutivos está oculta de la CPU (lo que significa que el propio brazo sabe qué hacer para reunir los datos necesarios de varias piezas), en otras plataformas es visible para la CPU (lo que significa que es la CPU quien es responsable de organizar estos viajes consecutivos del brazo).
Guarda el silicio en la lógica de direccionamiento si puede hacer ciertas suposiciones sobre la dirección (como "los n bits inferiores son cero). Algunas CPU (x86 y sus similares de trabajo) pondrán la lógica en su lugar para convertir los datos desalineados en múltiples recuperaciones, ocultando Algunos desagradables éxitos de rendimiento del programador. La mayoría de las CPU que se encuentran fuera de ese mundo provocarán un error de hardware que explica, en términos inequívocos, que no les gusta esto.
Todos los argumentos que escucharán sobre "eficiencia" son tontos o, más precisamente, están planteando la pregunta. La verdadera razón es simplemente que guarda el silicio en el núcleo del procesador si el número de bits de dirección se puede reducir para las operaciones. Cualquier ineficiencia que surja del acceso mal alineado (como en el mundo x86) es el resultado de las decisiones de diseño de hardware, no intrínsecas al direccionamiento en general.
Ahora que se dice, para la mayoría de los casos de uso, la decisión de diseño de hardware tiene sentido. Si está accediendo a datos en palabras de dos bytes, la mayoría de los casos de uso tienen acceso a offset , luego offset+2 , luego offset+4 y así sucesivamente. Ser capaz de incrementar la dirección por bytes al acceder a palabras de dos bytes no suele ser lo que usted quiere hacer (como en el 99.44%). Como tal, no está de más exigir que las compensaciones de dirección se alineen con los límites de las palabras (es un inconveniente leve y único cuando se diseñan las estructuras de datos), pero seguro que se ahorra en el silicio.
Como punto de vista histórico, trabajé una vez en un Interdata Model 70, una minicomputadora de 16 bits. Se requería que todos los accesos a la memoria estuvieran alineados a 16 bits. También tenía una cantidad muy pequeña de memoria cuando trabajaba en ella para los estándares de la época. (Era una reliquia incluso en ese entonces). La alineación de palabras se usó para duplicar la capacidad de la memoria, ya que la CPU envuelta en alambre podía ser fácilmente hackeada. Se agregó una nueva lógica de decodificación de la dirección que tomó un 1 en el bit bajo de la dirección (anteriormente un error de alineación en la creación) y lo usó para cambiar a un segundo banco de memoria. ¡Intenta eso sin lógica de alineación! :)
La alineación de palabras no solo es representada por las CPU
En el nivel de hardware, la mayoría de los módulos de RAM tienen un tamaño de palabra determinado con respecto a la cantidad de bits a los que se puede acceder por ciclo de lectura / escritura.
En un módulo que tuve que conectar en un dispositivo integrado, el direccionamiento se implementó a través de tres parámetros: El módulo se organizó en cuatro bancos que podían seleccionarse antes de la operación de RW. cada uno de estos bancos era esencialmente una tabla grande de palabras de 32 bits, que se podía direccionar a través de un índice de fila y columna.
En este diseño, el acceso solo era posible por celda , por lo que cada operación de lectura devolvía 4 bytes, y cada operación de escritura esperaba 4 bytes.
Un controlador de memoria conectado a este chip RAM se podría diseñar de dos maneras: ya sea permitiendo un acceso sin restricciones al chip de memoria usando varios ciclos para dividir / combinar datos no alineados a / desde varias celdas (con lógica adicional), o imponer algunas restricciones sobre cómo Se puede acceder a la memoria con la ganancia de complejidad reducida.
Como la complejidad puede impedir la capacidad de mantenimiento y el rendimiento, la mayoría de los diseñadores eligieron esta última [ cita requerida ]
Porque es más eficiente.
En su ejemplo, la CPU tendría que hacer dos lecturas: tiene que leer en la primera mitad, luego leer en la segunda mitad por separado y luego volver a ensamblarlas juntas para realizar el cálculo. Esto es mucho más complicado y más lento que hacer la lectura de una sola vez si los datos se alinearon correctamente.
Algunos procesadores, como x86, pueden tolerar un acceso de datos mal alineado (por lo que aún necesitaría los 32 bits), otros como Itanium no pueden manejar los accesos de datos mal alineados y se quejarán de forma espectacular.