Intel iAPX 432

El proyecto 432 de Intel comenzó en 1976, un año después de que se completara el Intel 8080 de 8 bits y un año antes de que comenzara su proyecto 8086 de 16 bits . El proyecto 432 se denominó inicialmente 8800 , ^{[ 5 ]} como su siguiente paso más allá de los microprocesadores Intel 8008 y 8080 existentes . Esto se convirtió en un paso muy importante. Los conjuntos de instrucciones de estos procesadores de 8 bits no eran muy adecuados para los lenguajes compilados típicos tipo Algol . Sin embargo, el principal problema eran sus pequeños rangos de direccionamiento nativo, solo 16 KB para el 8008 y 64 KB para el 8080, demasiado pequeños para muchos sistemas de software complejos sin usar algún tipo de conmutación de bancos , segmentación de memoria o mecanismo similar (que se incorporó al 8086, unos años más tarde). Intel se propuso construir un sistema completo y sofisticado con unos pocos chips LSI, funcionalmente igual o superior a los mejores miniordenadores y mainframes de 32 bits que requerían gabinetes enteros de chips antiguos. Este sistema admitiría multiprocesadores, expansión modular, tolerancia a fallos , sistemas operativos avanzados, lenguajes de programación avanzados, aplicaciones de gran tamaño, fiabilidad extrema y seguridad extrema. Su arquitectura satisfaría las necesidades de los clientes de Intel durante una década. ^{[ 10 ]}

El equipo de desarrollo del iAPX 432 estaba dirigido por Bill Lattin, con Justin Rattner (quien más tarde se convertiría en CTO de Intel) como ingeniero jefe ^{[ 11 ] [ 12 ] [ 13 ]} (aunque una fuente ^{[ 1 ]} afirma que Fred Pollack era el ingeniero jefe). Inicialmente, el equipo trabajaba desde Santa Clara , pero en marzo de 1977 Lattin y su equipo de 17 ingenieros se trasladaron a la nueva sede de Intel en Portland. ^{[ 12 ]} Posteriormente, Pollack se especializó en superescalaridad y se convirtió en el arquitecto jefe del Intel Pentium Pro . ^{[ 1 ]}

Pronto quedó claro que diseñar todo esto llevaría varios años y muchos ingenieros. De igual manera, se necesitarían varios años más de progreso en la Ley de Moore antes de que la mejora en la fabricación de chips permitiera integrar todo esto en unos pocos chips de alta densidad. Mientras tanto, Intel necesitaba urgentemente un producto intermedio más sencillo para hacer frente a la competencia inmediata de Motorola , Zilog y National Semiconductor . Así que Intel inició un proyecto apresurado para diseñar el 8086 como una evolución incremental de bajo riesgo a partir del 8080, utilizando un equipo de diseño independiente. El 8086 para el mercado masivo se lanzó en 1978.

El 8086 fue diseñado para ser retrocompatible con el 8080, en el sentido de que el lenguaje ensamblador del 8080 podía mapearse a la arquitectura del 8086 mediante un ensamblador especial. De este modo , el código fuente ensamblador existente del 8080 (aunque no el código ejecutable ) se hizo compatible con el nuevo 8086 hasta cierto punto. En contraste, el 432 no tenía requisitos de compatibilidad de software ni de migración. Los arquitectos tuvieron total libertad para crear un diseño novedoso desde cero, utilizando las técnicas que consideraran más adecuadas para sistemas y software a gran escala. Aplicaron conceptos de informática de moda en las universidades, en particular máquinas de capacidad , programación orientada a objetos, máquinas CISC de alto nivel , Ada e instrucciones densamente codificadas. Esta ambiciosa combinación de características novedosas hizo que el chip fuera más grande y complejo. La complejidad del chip limitó la velocidad de reloj y alargó el cronograma de diseño.

El núcleo del diseño —el procesador principal— se denominó Procesador General de Datos ( GDP ) y se construyó como dos circuitos integrados : uno (el 43201) para obtener y decodificar instrucciones, y el otro (el 43202) para ejecutarlas. La mayoría de los sistemas también incluían el Procesador de Interfaz ( IP ) 43203, que funcionaba como controlador de canal para E/S , y un Procesador Adjunto ( AP ), un Intel 8086 convencional que proporcionaba "potencia de procesamiento en el subsistema de E/S". ^{[ 4 ]}

Estos fueron algunos de los diseños más grandes de la época. El chip GDP de dos chips tenía un total de aproximadamente 97 000 transistores , mientras que el chip IP de un solo chip tenía aproximadamente 49 000. En comparación, el Motorola 68000 (presentado en 1979) tenía aproximadamente 40 000 transistores.  

En 1983, Intel lanzó dos circuitos integrados adicionales para la arquitectura de interconexión iAPX 432: la unidad de interfaz de bus ( BIU ) 43204 y la unidad de control de memoria ( MCU ) 43205. Estos chips permitieron la creación de sistemas multiprocesador prácticamente sin interconexión, con hasta 63  nodos.

Algunas de las características innovadoras del iAPX 432 resultaron perjudiciales para su buen rendimiento. En muchos casos, el iAPX 432 tenía un rendimiento de instrucciones significativamente más lento que los microprocesadores convencionales de la época, como el National Semiconductor 32016 , el Motorola 68010 y el Intel 80286. Un problema era que la implementación de dos chips del GDP lo limitaba a la velocidad del cableado eléctrico de la placa base. Un problema mayor era que la arquitectura de capacidades requería grandes cachés asociativas para funcionar de manera eficiente, pero los chips no tenían espacio suficiente para ello. El conjunto de instrucciones también utilizaba instrucciones de longitud variable alineadas a bits en lugar de los formatos habituales de byte semifijo o alineados a palabras utilizados en la mayoría de los diseños de computadoras. Por lo tanto, la decodificación de instrucciones era más compleja que en otros diseños. Si bien esto no perjudicaba el rendimiento en sí mismo, utilizaba transistores adicionales (principalmente para un gran desplazador de barril ) en un diseño que ya carecía de espacio y transistores para cachés, buses más amplios y otras características orientadas al rendimiento. Además, la BIU fue diseñada para admitir sistemas tolerantes a fallos, y al hacerlo, hasta el 40% del tiempo del bus se mantenía en estados de espera .

Otro problema importante fue su compilador Ada inmaduro y desoptimizado . Utilizaba instrucciones orientadas a objetos de alto costo en todos los casos, en lugar de las instrucciones escalares más rápidas donde habría sido más conveniente. Por ejemplo, el iAPX 432 incluía una instrucción de llamada a procedimiento entre módulos muy costosa , que el compilador utilizaba para todas las llamadas, a pesar de la existencia de instrucciones de bifurcación y enlace mucho más rápidas . Otra llamada muy lenta era `enter_environment`, que configuraba la protección de memoria. El compilador la ejecutaba para cada variable del sistema, incluso cuando las variables se utilizaban dentro de un entorno existente y no era necesario comprobarlas. Para empeorar las cosas, los datos que se pasaban a los procedimientos y desde ellos siempre se pasaban por valor de retorno en lugar de por referencia. Al ejecutar la prueba de rendimiento Dhrystone , el paso de parámetros tardaba diez veces más que todos los demás cálculos combinados. ^{[ 14 ]}

Según el New York Times , "el i432 funcionaba de 5 a 10 veces más lento que su competidor, el Motorola 68000". ^{[ 15 ]}

El iAPX 432 fue uno de los primeros sistemas en implementar el nuevo estándar IEEE-754 para aritmética de punto flotante. ^{[ 16 ]}

Una consecuencia del fracaso del 432 fue que los diseñadores de microprocesadores concluyeron que la compatibilidad con objetos en el chip conlleva un diseño complejo que, inevitablemente, se ejecuta lentamente. El 432 fue citado a menudo como contraejemplo por los defensores de los diseños RISC . Sin embargo, algunos sostienen que la compatibilidad con OO no fue el principal problema del 432, y que las deficiencias de implementación (especialmente en el compilador) mencionadas anteriormente habrían ralentizado cualquier diseño de CPU. Desde el iAPX 432, solo ha habido otro intento de diseño similar, el procesador Rekursiv , aunque la compatibilidad con procesos del INMOS Transputer era similar y muy rápida.

Intel había invertido mucho tiempo, dinero y recursos en el 432, contaba con un equipo altamente cualificado dedicado a él y no estaba dispuesta a abandonarlo por completo tras su fracaso comercial. Se contrató a un nuevo arquitecto, Glenford Myers , para desarrollar una arquitectura e implementación totalmente nuevas para el procesador central, que se construiría en un proyecto conjunto de Intel y Siemens (posteriormente BiiN ), dando como resultado los procesadores de la serie i960 . El subconjunto RISC i960 gozó de popularidad durante un tiempo en el mercado de procesadores integrados, pero los modelos de gama alta 960MC y el 960MX con memoria etiquetada se comercializaron exclusivamente para aplicaciones militares.

Según el New York Times , la colaboración de Intel con HP en el procesador Merced (más tarde conocido como Itanium) fue el intento de la compañía de regresar al mercado de gama muy alta. ^{[ 15 ]}

El iAPX 432 tiene soporte de hardware y microcódigo para programación orientada a objetos y direccionamiento basado en capacidades . ^{[ 18 ] [ 19 ]} El sistema utiliza memoria segmentada , con hasta 2 ²⁴ segmentos de hasta 64 KB cada uno, lo que proporciona un espacio de direcciones virtuales total de 2 ⁴⁰ bytes. El espacio de direcciones físicas es de 2 ²⁴ bytes (16 MB ).  

Los programas no pueden hacer referencia a datos o instrucciones mediante direcciones; en su lugar, deben especificar un segmento y un desplazamiento dentro de este. Los segmentos se referencian mediante descriptores de acceso (DA) , que proporcionan un índice en la tabla de objetos del sistema y un conjunto de derechos ( capacidades ) que rigen el acceso a dicho segmento. Los segmentos pueden ser "segmentos de acceso", que solo pueden contener descriptores de acceso, o "segmentos de datos", que no pueden contener DA. El hardware y el microcódigo imponen rigurosamente la distinción entre segmentos de datos y de acceso, y no permiten que el software trate los datos como descriptores de acceso, ni viceversa.

Los objetos definidos por el sistema constan de un único segmento de acceso o de un segmento de acceso y un segmento de datos. Estos segmentos contienen descriptores de datos o de acceso para datos definidos por el sistema en desplazamientos específicos, aunque el sistema operativo o el software de usuario pueden ampliarlos con datos adicionales. Cada objeto del sistema tiene un campo de tipo que es verificado por el microcódigo, de modo que no se puede usar un objeto de puerto donde se necesita un objeto portador. Los programas de usuario pueden definir nuevos tipos de objetos que aprovecharán al máximo la verificación de tipo del hardware mediante el uso de objetos de control de tipo (TCO) .

En la versión 1 de la arquitectura iAPX 432, un objeto definido por el sistema generalmente consistía en un segmento de acceso y, opcionalmente (dependiendo del tipo de objeto), un segmento de datos especificado por un descriptor de acceso en un desplazamiento fijo dentro del segmento de acceso.

En la versión 3 de la arquitectura, para mejorar el rendimiento, los segmentos de acceso y los segmentos de datos se combinaron en segmentos únicos de hasta 128  kB, divididos en una parte de acceso y una parte de datos de 0 a 64  KB cada una. Esto redujo drásticamente el número de búsquedas en la tabla de objetos y duplicó el espacio máximo de direcciones virtuales. ^{[ 20 ]}

El iAPX432 reconoce catorce tipos de objetos del sistema predefinidos : ^{[ 21 ] : pp.1-11–1-12}

• El objeto de instrucción contiene instrucciones ejecutables.
• El objeto de dominio representa un módulo de programa y contiene referencias a subrutinas y datos.
• El objeto de contexto representa el contexto de un proceso en ejecución.
• El objeto de definición de tipo representa un tipo de objeto definido por software.
• El objeto de control de tipos representa un privilegio específico de tipo.
• La tabla de objetos identifica la colección de descriptores de objetos activos del sistema.
• El objeto de recurso de almacenamiento representa un grupo de almacenamiento libre
• El objeto de almacenamiento físico identifica los bloques de almacenamiento libres en la memoria.
• Los objetos de reclamación de almacenamiento limitan el almacenamiento que pueden asignar todos los objetos de recursos de almacenamiento asociados.
• El objeto proceso identifica un proceso en ejecución
• El objeto puerto representa un puerto y una cola de mensajes para la comunicación entre procesos.
• Los transportistas llevan mensajes hacia y desde los puertos.
• El procesador contiene información de estado para un procesador en el sistema.
• El objeto de comunicación del procesador se utiliza para la comunicación entre procesadores.

El software que se ejecuta en el 432 no necesita liberar explícitamente los objetos que ya no se necesitan. En su lugar, el microcódigo implementa parte de la sección de marcado del algoritmo de recolección de basura paralela en tiempo real de Edsger Dijkstra (un recolector de estilo marcado y barrido ). ^{[ 22 ]} Las entradas en la tabla de objetos del sistema contienen los bits utilizados para marcar cada objeto como blanco, negro o gris según lo requiera el recolector. El sistema operativo iMAX 432 incluye la parte de software del recolector de basura. ^{[ 23 ]}

Las instrucciones ejecutables están contenidas dentro de un "objeto de instrucción" del sistema. ^{[ 21 ] : p.7-3} Debido a que las instrucciones están alineadas por bits, un desplazamiento de 16 bits dentro del objeto de instrucción permite que el objeto contenga hasta 65 536 bits (8192 bytes) de instrucciones.

Las instrucciones constan de un operador , compuesto por una clase y un código de operación , y de cero a tres referencias a operandos . "Los campos están organizados para presentar la información al procesador en la secuencia requerida para la decodificación". Los operadores más utilizados se codifican con menos bits. ^{[ 21 ] : p.7-6} La instrucción comienza con el campo de clase de 4 o 6 bits que indica el número de operandos , denominado orden de la instrucción, y la longitud de cada operando. A esto le sigue opcionalmente un campo de formato de 0 a 4 bits que describe los operandos (si no hay operandos, el formato no está presente). A continuación, vienen de cero a tres operandos, según lo descrito por el formato. La instrucción finaliza con el código de operación de 0 a 5 bits, si lo hay (algunas clases contienen solo una instrucción y, por lo tanto, no tienen código de operación). "El campo Formato permite que el GDP aparezca al programador como una arquitectura de cero, una, dos o tres direcciones". El campo de formato indica que un operando es una referencia de datos, o el elemento superior o siguiente a la parte superior de la pila de operandos. ^{[ 21 ] : pp.7-3–7-5}