Intel iAPX 432
El Intel iAPX 432 fue el primer diseño de microprocesador de 32 bits de Intel, introducido en 1981 como un conjunto de tres circuitos integrados. El iAPX 432 fue pensado para ser el principal diseño de Intel para los años 1980, implementando muchas características avanzadas de multitarea y manejo de memoria en hardware, que los condujo a referirse al diseño como el Micromainframe.
El soporte para estructuras de datos del procesador permitía implementar los sistemas operativos modernos usando mucho menos código de programa que otros CPUs ordinarios, el 432 haría, internamente en hardware, mucho del trabajo. Sin embargo, el diseño era extremadamente complejo comparado a los microprocesadores de consumo masivo de ese tiempo, tanto, que los ingenieros de Intel no pudieron traducir el diseño en una implementación eficiente usando la tecnología de semiconductores de la época. El CPU resultante fue muy lento y costoso, y así, los planes de Intel para sustituir la arquitectura x86 por el iAPX 432 terminaron miserablemente.
El prefijo del nombre del modelo de procesador, iAPX, se reporta como la abreviación de intel Advanced Processor architecture, la X venía de la letra griega Ji (en inglés, Chi).
Historia
Desarrollo
El proyecto 432, comenzó en 1975 con el nombre de 8800, llamado de esta manera para indicar la continuación de los CPU existentes, 8008 y 8080. El diseño fue pensado desde el principio para ser puramente de 32 bits, y para ser la espina dorsal de Intel en las ofertas de procesadores para los años 1980. Como tal, tenía que ser considerablemente más poderoso y complejo que sus "simples" ofertas existentes. Sin embargo el diseño estaba muy por arriba de las capacidades de la existente tecnología de proceso del momento, y tuvo que ser dividido en varios chips individuales.
El núcleo del diseño fue el Procesador de Datos General (General Data Processor, GDP), que conformaron el procesador principal. El GDP estaba dividido en dos, un chip, el 43201, que manejaban la lectura (fetching) y el decodificado de las instrucciones, el otro, el 43202, que las ejecutaba. La mayoría de los sistemas también incluirían el Procesador de Interfaz (Interface Processor, IP) 43203 que funcionó como controlador de canal para la I/O (entrada/salida). En conjunto, el sistema de tres chips usaba cerca de 250.000 puertas lógicas, haciéndole uno de los diseños más grandes de su época. El contemporáneo Motorola 68000, por ejemplo, tenía cerca de 68.000 puertas lógicas con alrededor de 1/3 de eso para su microcódigo.
En 1983 Intel lanza dos circuitos integrados adicionales para la Arquitectura Interconectada (Interconnect Architecture) del iAPX 432, la Unidad de Interface de Bus 43204 (Bus Interface Unit, BIU) y la Unidad de Control de Memoria 43205 (Memory Control Unit, MCU). Estos chips permitieron sistemas multiprocesadores con hasta 63 nodos casi sin circuitos auxiliares (glueless).
Las fallas del proyecto
Varias características de diseño del iAPX 432 conspiraron para hacerlo mucho más lento de lo que tenía que ser ser. La implementación del GDP en dos chips lo limitó a la velocidad del cableado eléctrico de la tarjeta madre, aunque esto era un problema de menor importancia. La carencia de cachés de tamaño razonable y la carencia de registros fue un problema considerablemente más serio. El conjunto de instrucciones también obstaculizó el desempeño, haciendo compleja y lenta la decodificación de las mismas debido a que el procesador usaba instrucciones de longitud variable alineadas a nivel de bits, al contrario de las instrucciones usadas en la mayoría de los otros diseños de procesadores en donde las instrucciones de longitud fija estaban alineadas a la palabra del CPU. Además el BIU fue diseñado para soportar sistemas tolerantes a fallas, y al hacerlo así, agregó una considerable sobrecarga al bus, con hasta 40% del tiempo de éste en estados de espera (wait states).
Investigaciones posteriores al proyecto sugirieron que el mayor problema estaba en el compilador. Este usaba en todos los casos instrucciones "generales" de alto costo en vez de, donde hubiera tenido sentido, instrucciones más simples y de alto rendimiento. Por ejemplo el iAPX 432 incluyó una muy costosa instrucción de llamada a procedimiento entre módulos, que el compilador usaba para todas las llamadas a pesar de la existencia de instrucciones de bifurcar y enlazar (branch and link) que eran mucho más rápidas. Otra llamada muy lenta era el enter_environment, que instalaba la protección de la memoria. El compilador corría esta instrucción por cada simple variable en el sistema, incluso aunque la extensa mayoría estaba corriendo en un ambiente existente y no necesitaba ser chequeada. Para hacer las cosas peor, el compilador pasaba los datos, a, y desde los procedimientos, por valor en vez de por referencia, requiriendo en muchos casos enormes y lentas copias de memoria a memoria.
Impacto y diseños similares
Un resultado del fracaso del 432 fue que los diseñadores de microprocesadores concluyeron que el soporte de objetos en el chip conducía a un diseño complejo que invariablemente correría lentamente y el 432 fue a menudo citado como un contraejemplo por los que proponían los diseños RISC. Sin embargo, es sostenido por algunos, que el soporte de OO no fue el problema primario con los 432 y que los defectos de la implementación mencionados arriba habrían hecho lento cualquier diseño de chip. Desde el iAPX 432 nadie ha intentado un diseño similar, aunque el soporte de proceso del INMOS Transputer fue similar, y muy rápido.
Intel había invertido considerable tiempo, dinero, y mentes, en el 432, tenía un equipo experto dedicado a él y era reacia abandonarlo enteramente después de su fracaso en el mercado. Un nuevo arquitecto, Glenford Myers, fue traído para producir una arquitectura enteramente nueva y para implementar el núcleo del procesador que sería construido en un proyecto en conjunto de Intel y Siemens (posteriormente BiiN), resultando en los procesadores de la serie i960. Por un tiempo, el subconjunto del procesador RISC i960 llegó a ser popular en el mercado del procesador embebido, pero el más sofisticado 960MC y el 960MX, de tagged-memory, fueron mercadeados solamente para aplicaciones militares y tuvieron incluso menos uso que el 432.
Arquitectura
Memoria y capacidades orientadas a objetos
El iAPX 432 tenía soporte en hardware y microcódigo para la programación orientada a objetos. El sistema usaba memoria segmentada con hasta 224 segmentos de hasta 64 kilobytes cada uno, proporcionando un espacio total de dirección virtual de 240 bytes. El espacio de dirección física era de 224 bytes (16 megabytes).
Los programas no podían hacer referencias a datos o instrucciones por medio de direcciones. En lugar de ello, debían especificar un segmento y un offset (desplazamiento) dentro del segmento. Los segmentos eran referidos por Descriptores de Acceso (Access Descriptors, AD), que proporcionaban un índice en la tabla de objetos de sistema y un conjunto de derechos (capacidades) gobernando los accesos a ese segmento. Los segmentos podían ser segmentos de acceso, que podían contener solamente Descriptores de Acceso, o segmentos de datos que no podían contener ADs. El hardware y el microcódigo hacían cumplir rígidamente la distinción entre los segmentos de datos y de acceso, y no permitían al software tratar datos como Descriptores de Acceso, o viceversa.
Los objetos definidos del sistema consistían en un solo segmento de acceso, o un segmento de acceso y uno de datos. los segmentos definidos del sistema contenían descriptores de datos o acceso para los datos definidos del sistema en los offsets designados. El sistema operativo o el software del usuario podía ampliar éstos con datos adicionales. Cada objeto del sistema tenía un campo de tipo que era comprobado por el microcódigo, de tal manera que un Objeto de Puerto (Port Object) no podía ser usado donde un Objeto Portador (Carrier Object) era necesario. El programa de usuario podía definir nuevos tipos de objetos, con lo que se conseguirían el beneficio completo de la comprobación de tipos por hardware con el uso de Objetos de Control de Tipos (Type Control Objects, TCO).
En el primer lanzamiento de la arquitectura del iAPX 432, un objeto definido del sistema consistía típicamente de un segmento de acceso, y opcionalmente, dependiendo del tipo de objeto, un segmento de datos especificado por un descriptor de acceso en un offset fijo dentro del segmento del acceso.
En el tercer lanzamiento de la arquitectura, para mejorar el rendimiento, los segmentos de acceso y de datos fueron combinados en segmentos únicos de hasta 128 kilobytes, divididos en una parte de acceso y una de datos con un tamaño de entre 0 y 64K cada una. Esto redujo dramáticamente el número de búsquedas en la tabla de objetos, y dobló el máximo espacio de dirección virtual.
Multitarea y comunicación interproceso
El microcódigo del iAPX 432 implementaba la multitarea usando objetos en memoria para representar el procesador, procesos, puertos de comunicación, y puertos de despacho. Cada procesador estaba asociado a un puerto de despacho, y cuando estaba desocupado procuraría despachar un proceso de ese puerto de despacho. Cuando el proceso se bloqueaba o expiraba su quantum de tiempo, el procesador ponía de nuevo en la cola (re-enqueues) ese proceso en su puerto de despacho, entonces despachaba un nuevo proceso del puerto de despacho.
La comunicación entre procesos era soportada con el uso de los puertos de comunicación. Un puerto de comunicación era esencialmente un FIFO que podía poner en cola los mensajes que esperaban para ser recibidos por un proceso, o procesos esperando recibir un mensaje (pero nunca ambos). Un programa podía usar instrucciones Send, Receive, Conditional Send, Conditional Receive, Surrogate Send, o Surrogate Receive, para comunicarse con otros procesos enviando o recibiendo mensajes por puertos de comunicación. Si no había ningún mensaje en cola en un puerto de comunicación, una instrucción Receive normal en ese puerto bloquearía el proceso actual hasta que un mensaje estaba disponible. Similarmente, una instrucción Send normal bloquearía el proceso actual si el puerto estaba lleno. Las instrucciones Conditional Send y Conditional Receive no bloqueaban, sino que retornan un resultado booleano indicando si la operación tuvo éxito. Las instrucciones Surrogate Send y Surrogate Receive proporcionaban un objeto Carrier que podía bloquear en lugar del proceso.
Uno de los aspectos elegantes de la arquitectura del iAPX 432 era que un puerto despachador era de hecho justo un puerto de comunicación cuyos mensajes eran objetos de proceso, así, unificando la operación del despacho de procesos y la comunicación entre procesos y simplificando la implementación subyacente.
Multiprocesamiento
El iAPX 432 tenía compatibilidad con hardware para el multiprocesamiento, usando hasta 64 procesadores (combinación de GDPs y de IPs). Usualmente todos los GDPs compartían una carga de trabajo común usando un solo puerto de despacho a lo ancho del sistema, aunque era posible repartir la carga de trabajo asignando algunos procesadores a diversos puertos de despacho. Con hardware convenientemente diseñado, los procesadores se podían agregar o extraer de un sistema en marcha.
Tolerancia a fallas
Desde el principio, el iAPX 432 incluía soporte para la tolerancia a fallas. Todos los chips 432 se podían configurar en pares para el Chequeo de Redundancia Funcional (Functional Redundancy Checking, FRC), en la cual un componente, el amo (master), funcionado normalmente, y un segundo, el chequeador (checker), realizaron las mismas operaciones internas en paralelo y verificaron sus resultados contra los del amo (master).
El FRC preveía la detección de falla, pero la tolerancia de avería completa requería un mecanismo de recuperación. Los sistemas basados en la Arquitectura de Interconexión apoyaron la recuperación automática de falla al combinar pares de módulos FRC para la Redundancia Modular Cuádruple (QMR). En una configuración QMR, en un momento dado, un módulo de FRC era un primario y el otro era una sombra. Los dos módulos funcionaban en lockstep, pero los papeles se alternan para detectar fallas latentes. El módulo de sombra no manejaba el bus. Si una falla se detectaba en cualquiera de los módulos de FRC, ese módulo era desactivado mientras que el módulo sin fallas podía continuar la operación. El software era notificado, y podía elegir dejar el sistema continuar funcionando (sin la tolerancia a fallas para ese módulo), aparear el módulo con un repuesto, o dejar el módulo fuera de línea (desplazando su carga de trabajo a otros procesadores en el sistema con una elegante degradación de desempeño).
Entrada/Salida (I/O)
El 43203, Procesador de Interface (Interface Processor, IP), permitía que un microprocesador más convencional fuera interconectado como Procesador Unido (Attached Processor, AP) a un sistema iAPX 432. El AP actuaba como un controlador inteligente de I/O. El IP permitía al AP acceder objetos en la memoria del iAPX 432 por medio del uso de ventanas mapeadas en memoria, pero reforzaría los derechos de acceso aplicables a los objetos.
El IP proporcionaba cinco ventanas de memoria. Cuatro eran usadas para mapear objetos para operaciones de I/O, la quinta era la ventana de control y era usada por el AP para realizar operaciones de control tales como peticiones de cambios al mapeo de las otras ventanas.
El IP también ofrecía un modo "físico" especial en el cual el AP tenía acceso sin restricción a todo el espacio de dirección del iAPX 432. El modo físico se pensó para ser usado solamente para el soporte de arranque y depuración del sistema.
Enlaces externos
- Intel iAPX 432 (Computer Science project paper) – By David King, Liang Zhou, Jon Bryson, David Dickson