Arquitectura informática en lenguaje de alto nivel

Una arquitectura informática de lenguaje de alto nivel ( HLLCA ) es una arquitectura informática diseñada para ser dirigida por un lenguaje de programación de alto nivel (HLL) específico, en lugar de que la arquitectura sea dictada por consideraciones de hardware. En consecuencia, también se denomina diseño informático dirigido por lenguaje , acuñado en McKeeman (1967) y utilizado principalmente en los años 1960 y 1970. Las HLLCA fueron populares en los años 1960 y 1970, pero desaparecieron en gran medida en los años 1980. Esto siguió al dramático fracaso del Intel 432 (1981) y la aparición de compiladores optimizadores y arquitecturas informáticas de conjunto de instrucciones reducidas (RISC) y arquitecturas informáticas de conjunto de instrucciones complejas (CISC) similares a RISC, y el desarrollo posterior de la compilación justo a tiempo (JIT) para HLL. Se puede encontrar un estudio y una crítica detallados en Ditzel y Patterson (1980).

Los HLLCA datan casi del comienzo de los HLL, en los grandes sistemas de Burroughs (1961), que fueron diseñados para ALGOL 60 (1960), uno de los primeros HLL. Los HLLCA más conocidos pueden ser las máquinas Lisp de los años 1970 y 1980, para el lenguaje Lisp (1959). En la actualidad los HLLCA más populares son los procesadores Java , para el lenguaje Java (1995), y estos son un éxito calificado, siendo utilizados para ciertas aplicaciones. Una arquitectura reciente en esta línea es la Arquitectura de Sistemas Heterogéneos (2012), que HSA Intermediate Layer (HSAIL) proporciona soporte de conjunto de instrucciones para características HLL como excepciones y funciones virtuales; esto utiliza JIT para asegurar el rendimiento.

Existe una amplia variedad de sistemas bajo este encabezado. El ejemplo más extremo es un lenguaje de ejecución directa (DEL), donde la arquitectura del conjunto de instrucciones (ISA) de la computadora es igual a las instrucciones del HLL, y el código fuente es directamente ejecutable con un procesamiento mínimo. En casos extremos, la única compilación necesaria es tokenizar el código fuente y alimentar los tokens directamente al procesador; esto se encuentra en lenguajes de programación orientados a pila que se ejecutan en una máquina de pila . Para lenguajes más convencionales, las instrucciones del HLL se agrupan en instrucción + argumentos , y el orden infijo se transforma en orden prefijo o posfijo . Los DEL son típicamente solo hipotéticos, aunque fueron defendidos en la década de 1970. ^[1]

En ejemplos menos extremos, el código fuente se analiza primero para obtener bytecode , que luego es el código de máquina que se pasa al procesador. En estos casos, el sistema normalmente carece de un ensamblador , ya que el compilador se considera suficiente, aunque en algunos casos (como Java), se utilizan ensambladores para producir bytecode legal que no sería generado por el compilador. Este enfoque se encontró en Pascal MicroEngine (1979) y actualmente lo utilizan los procesadores Java.

En términos más generales, una HLLCA puede ser simplemente una arquitectura informática de propósito general con algunas características específicas para admitir una HLL determinada o varias HLL. Esto se encontró en las máquinas Lisp a partir de la década de 1970, que ampliaron los procesadores de propósito general con operaciones diseñadas específicamente para admitir Lisp.

Los sistemas grandes de Burroughs (1961) fueron los primeros HLLCA, diseñados para soportar ALGOL (1959), uno de los primeros HLL. En su momento, esto se denominó "diseño dirigido por el lenguaje". Los sistemas medianos de Burroughs (1966) se diseñaron para soportar COBOL para aplicaciones comerciales. Los sistemas pequeños de Burroughs (mediados de la década de 1970, diseñados a fines de la década de 1960) se diseñaron para soportar múltiples HLL mediante un almacén de control escribible . Todos estos eran mainframes.

La serie Wang 2200 (1973) fue diseñada con un intérprete BASIC en microcódigo.

Pascal MicroEngine (1979) fue diseñado para la versión UCSD Pascal de Pascal y utilizó código p (código de bytes del compilador de Pascal) como código de máquina. Esto influyó en el desarrollo posterior de Java y las máquinas Java.

Las máquinas Lisp (décadas de 1970 y 1980) fueron un grupo de HLLCA muy conocido e influyente.

El Intel iAPX 432 (1981) fue diseñado para soportar Ada. Este fue el primer diseño de procesador de 32 bits de Intel y estaba destinado a ser la familia de procesadores principal de Intel para la década de 1980, pero fracasó comercialmente.

Rekursiv (mediados de la década de 1980) era un sistema menor, diseñado para soportar la programación orientada a objetos y el lenguaje de programación Lingo en hardware, y admitía recursión a nivel del conjunto de instrucciones, de ahí el nombre.

A finales de los años 1980 y principios de los años 1990 se diseñaron varios procesadores y coprocesadores destinados a implementar Prolog de forma más directa, entre ellos el Berkeley VLSI-PLM, su sucesor (el PLUM) y una implementación de microcódigo relacionada. También hubo varios diseños simulados que no se produjeron como hardware Una metodología basada en VHDL para diseñar un procesador Prolog, Un coprocesador Prolog para superconductores. Al igual que Lisp, el modelo básico de computación de Prolog es radicalmente diferente de los diseños imperativos estándar, y los científicos informáticos y los ingenieros eléctricos estaban ansiosos por escapar de los cuellos de botella causados ​​por la emulación de sus modelos subyacentes.

El proyecto Lilith de Niklaus Wirth incluía una CPU personalizada orientada al lenguaje Modula-2 . ^[2]

El transputer INMOS fue diseñado para soportar programación concurrente, utilizando occam .

El procesador AT&T Hobbit , derivado de un diseño llamado CRISP (Procesador de conjunto de instrucciones reducidas en lenguaje C), fue optimizado para ejecutar código C.

A finales de los años 90, Sun Microsystems y otras empresas tenían planes de fabricar CPU que implementaran directamente (o de forma muy similar) la máquina virtual Java basada en pila . Como resultado, se han fabricado y utilizado varios procesadores Java .

Ericsson desarrolló ECOMP, un procesador diseñado para ejecutar Erlang . ^[3] Nunca se produjo comercialmente.

La capa intermedia HSA (HSAIL) de la arquitectura de sistemas heterogéneos (2012) proporciona un conjunto de instrucciones virtuales para abstraerse de las ISA subyacentes, y tiene soporte para características HLL como excepciones y funciones virtuales, e incluye soporte de depuración.

Las HLLCA se implementan frecuentemente a través de una máquina de pila (como en los sistemas grandes de Burroughs e Intel 432), y se implementan mediante microcódigo en el procesador (como en los sistemas pequeños de Burroughs y Pascal MicroEngine). Las arquitecturas etiquetadas se utilizan con frecuencia para admitir tipos (como en los sistemas grandes de Burroughs y las máquinas Lisp). Los ejemplos más radicales utilizan una arquitectura que no es de von Neumann , aunque normalmente se trata solo de propuestas hipotéticas, no de implementaciones reales.

Algunas HLLC han sido especialmente populares como máquinas de desarrollo (estaciones de trabajo), debido a las compilaciones rápidas y al control de bajo nivel del sistema con un lenguaje de alto nivel. Pascal MicroEngine y las máquinas Lisp son buenos ejemplos de esto.

Los HLLCA se han defendido a menudo cuando un HLL tiene un modelo de computación radicalmente diferente al de la programación imperativa (que es una combinación relativamente buena para los procesadores típicos), en particular para la programación funcional (Lisp) y la programación lógica (Prolog).

En Ditzel y Patterson (1980) se ofrece una lista detallada de posibles ventajas.

Los HLLCA son intuitivamente atractivos, ya que, en principio, la computadora se puede personalizar para un lenguaje, lo que permite un soporte óptimo para el lenguaje y simplifica la escritura del compilador. Además, puede admitir de forma nativa varios lenguajes simplemente modificando el microcódigo. Las principales ventajas para los desarrolladores son: compilación rápida y depuración simbólica detallada desde la máquina.

Otra ventaja es que se puede actualizar la implementación de un lenguaje actualizando el microcódigo ( firmware ), sin necesidad de volver a compilar todo el sistema. Esto es análogo a actualizar un intérprete para un lenguaje interpretado.

Una ventaja que está reapareciendo después del 2000 es la seguridad. La TI convencional se ha movido en gran medida a lenguajes con seguridad de tipo y/o memoria para la mayoría de las aplicaciones. ^{[ cita requerida ]} El software del que dependen, desde el sistema operativo hasta las máquinas virtuales, aprovecha el código nativo sin protección. Se han encontrado muchas vulnerabilidades en dicho código. Una solución es utilizar un procesador creado a medida para ejecutar un lenguaje seguro de alto nivel o al menos entender los tipos. Las protecciones a nivel de palabra del procesador dificultan el trabajo de los atacantes en comparación con las máquinas de bajo nivel que no ven distinción entre datos escalares, matrices, punteros o código. Los académicos también están desarrollando lenguajes con propiedades similares que podrían integrarse con procesadores de alto nivel en el futuro. Un ejemplo de ambas tendencias es el proyecto SAFE ^{[4] . Compare} los sistemas basados ​​en lenguaje , donde el software (especialmente el sistema operativo) se basa en un lenguaje seguro de alto nivel, aunque el hardware no necesita estarlo: la "base confiable" aún puede estar en un lenguaje de nivel inferior.

Una crítica detallada se ofrece en Ditzel y Patterson (1980).

La razón más simple para la falta de éxito de los HLLCA es que a partir de 1980, la optimización de los compiladores dio como resultado un código mucho más rápido y era más fácil de desarrollar que la implementación de un lenguaje en microcódigo. Muchas optimizaciones de compiladores requieren un análisis complejo y una reorganización del código, por lo que el código de máquina es muy diferente del código fuente original. Estas optimizaciones son imposibles o poco prácticas de implementar en microcódigo, debido a la complejidad y la sobrecarga. Los problemas de rendimiento análogos tienen una larga historia con los lenguajes interpretados (que datan de Lisp (1958)), y solo se resolvieron adecuadamente para su uso práctico mediante la compilación justo a tiempo , iniciada en Self y comercializada en la máquina virtual Java HotSpot (1999).

El problema fundamental es que los HLLCA solo simplifican el paso de generación de código de los compiladores, que normalmente es una parte relativamente pequeña de la compilación y un uso cuestionable de la potencia de cálculo (transistores y microcódigo). Como mínimo, se necesita la tokenización y, por lo general, se seguirán realizando análisis sintácticos y verificaciones semánticas básicas (variables no vinculadas), por lo que no hay ningún beneficio para la parte inicial, y la optimización requiere un análisis previo, por lo que no hay ningún beneficio para la parte intermedia.

Un problema más profundo, que sigue siendo un área de desarrollo activa en 2014 ^[actualizar], ^[5] es que proporcionar información de depuración de HLL a partir del código de máquina es bastante difícil, básicamente debido a la sobrecarga de la información de depuración y, más sutilmente, porque la compilación (en particular la optimización) hace que la determinación de la fuente original de una instrucción de máquina sea bastante compleja. Por lo tanto, la información de depuración proporcionada como parte esencial de los HLLCA limita gravemente la implementación o agrega una sobrecarga significativa en el uso ordinario.

Además, los HLLCA suelen estar optimizados para un lenguaje, y su compatibilidad con otros lenguajes es más deficiente. Surgen problemas similares en las máquinas virtuales multilenguaje, en particular la máquina virtual Java (diseñada para Java) y el Common Language Runtime de .NET (diseñado para C# ), donde otros lenguajes son ciudadanos de segunda clase y, a menudo, deben ceñirse estrechamente al lenguaje principal en cuanto a semántica. Por esta razón, los ISA de nivel inferior permiten que se admitan varios lenguajes, siempre que exista compatibilidad con compiladores. Sin embargo, surge un problema similar incluso para muchos procesadores aparentemente neutrales en cuanto al lenguaje, que tienen un buen soporte para el lenguaje C y donde la transpilación a C (en lugar de apuntar directamente al hardware) produce programas eficientes y compiladores simples.

Las ventajas de los HLLCA se pueden conseguir de forma alternativa en sistemas informáticos HLL ( sistemas basados ​​en lenguajes ) de otras formas, principalmente a través de compiladores o intérpretes: el sistema sigue estando escrito en un HLL, pero hay una base fiable en software que se ejecuta en una arquitectura de nivel inferior. Este ha sido el enfoque seguido desde aproximadamente 1980: por ejemplo, un sistema Java en el que el entorno de ejecución en sí está escrito en C, pero el sistema operativo y las aplicaciones están escritas en Java.

Desde la década de 1980, el foco de la investigación y la implementación en arquitecturas informáticas de propósito general se ha centrado principalmente en arquitecturas similares a RISC, típicamente arquitecturas de carga y almacenamiento internamente ricas en registros , con ISA bastante estables, no específicas del lenguaje, que presentan múltiples registros, canalización y, más recientemente, sistemas multinúcleo, en lugar de ISA específicas del lenguaje. El soporte del lenguaje se ha centrado en los compiladores y sus entornos de ejecución, y en los intérpretes y sus máquinas virtuales (en particular, las que funcionan con JIT), con poco soporte de hardware directo. Por ejemplo, el entorno de ejecución Objective-C actual para iOS implementa punteros etiquetados , que utiliza para la comprobación de tipos y la recolección de basura, a pesar de que el hardware no es una arquitectura etiquetada.

En la arquitectura informática, el enfoque RISC ha demostrado ser muy popular y exitoso, y es opuesto a los HLLCA, ya que enfatiza una arquitectura de conjunto de instrucciones muy simple. Sin embargo, las ventajas de velocidad de las computadoras RISC en la década de 1980 se debieron principalmente a la adopción temprana de caché en chip y espacio para registros grandes, en lugar de ventajas intrínsecas de RISC. ^{[ cita requerida ]} .

• ASIC
• Procesador Java
• Sistema basado en el lenguaje
• Máquina Lisp
• Prolog#Implementación en hardware
• Compilador de silicio