Estaba leyendo acerca de arduino y la arquitectura AVR y me quedé atascado en el punto de que la forma en que se resuelve el estancamiento o la propagación de las tuberías se logra mediante la introducción de la arquitectura de Harvard en el AVR. Memoria de programa que permite cargar el programa sin un operador. ¿Pero cómo ayuda a resolver el problema anterior?
La arquitectura de Harvard, que por cierto se usó mucho antes de que se inventaran los AVR, sí tiene espacios de direcciones separados para la memoria del programa y para la memoria de datos. Lo que esto trae a la parte es la capacidad de diseñar el circuito de manera tal que se pueda usar un circuito de control y bus por separado para manejar el flujo de información de la memoria del programa y el flujo de información a la memoria de datos. El uso de buses separados significa que es posible que la búsqueda y ejecución del programa continúe sin interrupción de una transferencia de datos ocasional a la memoria de datos. Por ejemplo, en la versión más sencilla de la arquitectura, la unidad de búsqueda de programas puede estar ocupada buscando la siguiente instrucción en la secuencia del programa en paralelo con la operación de transferencia de datos que puede haber sido parte de la instrucción del programa anterior.
En este nivel más simple, la arquitectura de Harvard tiene una limitación, ya que generalmente no es posible poner código de programa en la memoria de datos y ejecutarlo desde allí.
Hay muchas variaciones y complejidades que pueden agregarse a esta forma más simple de la arquitectura que he descrito. Una adición común es agregar el almacenamiento en caché de instrucciones al bus de información del programa que permite a la unidad de ejecución de instrucciones acceder más rápidamente al siguiente paso del programa sin tener que ir a una memoria más lenta para obtener el paso del programa cada vez que sea necesario.
Algunas notas además de la respuesta de Michaels:
1) la arquitectura de Harvard no requiere que haya dos espacios separados para los datos y el código, solo que (en su mayoría) se buscan en dos buses diferentes.
2) el problema que se resuelve con la arquitectura de Harvard es la contención del bus: para un sistema en el que la memoria de código puede proporcionar las instrucciones lo suficientemente rápido para mantener la CPU a plena velocidad, la carga adicional de las recuperaciones de datos / almacenes ralentizar la CPU hacia abajo. Ese problema se resuelve con una arquitectura Hardvard: una memoria que es (un poco) demasiado lenta para la velocidad de la CPU.
Tenga en cuenta que el almacenamiento en caché es otra forma de resolver este problema. A menudo, Harvarding y el almacenamiento en caché se utilizan en combinaciones interesantes.
Harvard utiliza dos buses. No hay ninguna razón inherente para mantener dos, en casos muy especiales se usan más de dos, principalmente en DSPs (procesadores de señales digitales).
La Banca de Memoria (en el sentido de distribuir accesos de memoria a diferentes conjuntos de chips) se puede ver como una especie de Harvarding dentro del sistema de memoria en sí, no basado en la distinción de datos / código, sino en ciertos bits de la dirección.
Una arquitectura pura de Harvard generalmente permitirá que una computadora con un nivel de complejidad determinado funcione más rápido que una arquitectura de Von Neuman, siempre que no sea necesario compartir recursos entre el código y las memorias de datos. Si las limitaciones de pines u otros factores obligan al uso de un bus para acceder a ambos espacios de memoria, tales ventajas pueden ser anuladas en gran medida.
Una arquitectura "pura" de Harvard se limitará a ejecutar el código que se coloca en la memoria por algún mecanismo que no sea el procesador que ejecutará el código. Esto limita la utilidad de tales arquitecturas para dispositivos cuyo propósito no está establecido por la fábrica (o alguien con equipo de programación especializado). Se pueden usar dos enfoques para aliviar este problema:
Algunos sistemas tienen áreas de código y memoria separadas, pero proporcionan hardware especial que se le puede pedir que tome el bus de código, realice alguna operación y devuelva el control a la CPU una vez que se complete. Algunos de estos sistemas requieren un protocolo bastante elaborado para llevar a cabo tales operaciones, algunos tienen instrucciones especiales para realizar dicha tarea, y algunos incluso buscan ciertas direcciones de "memoria de datos" y activan la toma / liberación cuando se intenta acceder a ellas. . Un aspecto clave de tales sistemas es que existen áreas de memoria explícitamente definidas para "código" y "datos"; incluso si es posible que la CPU lea y escriba espacio de "código", aún se reconoce que es semánticamente diferente del espacio de datos ".
Un enfoque alternativo que se utiliza en algunos sistemas de gama alta, es tener un controlador con dos buses de memoria, uno para el código y otro para los datos, ambos conectados a una unidad de arbitraje de memoria. Esa unidad, a su vez, se conecta a varios subsistemas de memoria utilizando un bus de memoria separado para cada uno. Un acceso de código a un subsistema de memoria puede procesarse simultáneamente con un acceso de datos a otro; solo si el código y los datos intentan acceder al mismo subsistema simultáneamente, uno de los dos tendrá que esperar.
En los sistemas que utilizan este enfoque, las partes de un programa que no son críticas para el rendimiento pueden simplemente ignorar los límites entre los subsistemas de memoria. Si el código y los datos residen en el mismo subsistema de memoria, las cosas no se ejecutarán tan rápido como si estuvieran en subsistemas separados, pero para muchas partes de un programa típico eso no importará. En un sistema típico, habrá una pequeña parte del código donde el rendimiento realmente importa, y solo funcionará en una pequeña parte de los datos que posee el sistema. Si uno tuviera un sistema con 16K de RAM que se dividiera en dos particiones de 8K, uno podría usar las instrucciones del enlazador para asegurarse de que el código crítico para el rendimiento se ubicara cerca del inicio del espacio total de la memoria, y que los datos críticos para el rendimiento estuvieran cerca del fin. Si el tamaño total del código aumenta, por ejemplo, 9K, el código dentro del último 1K sería más lento que el código colocado en otro lugar, pero ese código no sería crítico para el rendimiento. Del mismo modo, si el código fuera por ejemplo. solo 6K, pero los datos aumentaron a 9K, el acceso al 1K de datos más bajo sería lento, pero si los datos críticos para el rendimiento se encontraran en otro lugar, eso no supondría un problema.
Tenga en cuenta que si bien el rendimiento sería óptimo si el código estuviera por debajo de 8K y los datos por debajo de 8K, el diseño del sistema de memoria mencionado anteriormente no impondría ninguna partición estricta entre el código y el espacio de datos. Si un programa solo necesita 1K de datos, el código podría crecer hasta 15K. Si solo necesita 2K de código, los datos podrían crecer a 14K. Mucho más versátil que tener un área de 8K solo para código y un área de 8K solo para datos.
Un aspecto que no se ha discutido es que para los microcontroladores pequeños, normalmente con solo un bus de direcciones de 16 bits, una arquitectura de Harvard duplica (o triplica) el espacio de direcciones. Puede tener 64K de código, 64K de RAM y 64k de E / S asignadas en memoria (si el sistema utiliza E / S asignadas en memoria en lugar de números de puerto, este último ya separa el direccionamiento de E / S del código y el amplificador). ; Espacios RAM).
De lo contrario, tiene que rellenar el código, la RAM y, opcionalmente, la dirección de E / S dentro del mismo espacio de direcciones de 64K.
Lea otras preguntas en las etiquetas microprocessor arduino avr computer-architecture architecture