Actualizado a: 16 de abril de 2024
Cada CPU suele comprender y trabajar con una sola ISA. Pero… ¿existen CPUs o microprocesadores que puedan trabajar con varias de ellas? Es una pregunta bastante compleja y que necesita de una explicación compleja. Vamos allá:
También te recomiendo leer nuestro artículos sobre:
¿Qué es una ISA?
Una ISA (Instruction Set Architecture), o arquitectura de conjunto de instrucciones, es un set de instrucciones que define las operaciones que una CPU (Central Processing Unit) puede ejecutar, además de los tipos de datos que puede manejar, los modos de direccionamiento, los registros, y la longitud de palabra.
La ISA es importante porque define la interfaz entre el hardware y el software de un sistema de computación. El software, en particular el sistema operativo y las aplicaciones, se escriben en un lenguaje de programación de alto nivel como C o Java, que se compila a un conjunto de instrucciones de bajo nivel que son específicas para una ISA en particular. La CPU, a su vez, está diseñada para ejecutar estas instrucciones de manera eficiente y rápida, decodificándolas en la unidad de control como tantas veces he comentado.
Hay muchas ISAs diferentes en el mercado, cada una con sus propias fortalezas y debilidades. Algunas más comunes incluyen:
- x86-64 (EM64T o AMD64): una CISC utilizada en la mayoría de las PC y servidores basados en Intel y AMD, entre otras marcas, ya que también existen procesadores como los VIA, etc.
- ARM: RISC utilizada en la mayoría de los dispositivos móviles y sistemas embebidos, aunque también están ganando terreno en chips de alto rendimiento para PC y HPC, como es el caso de los Apple M1, M2, los Graviton, A64FX, etc.
- MIPS: RISC utilizadA en sistemas embebidos y algunos routers. Esta ISA era en el pasado como ARM en la actualidad, pero poco a poco ha ido perdiendo terreno. No obstante, en el pasado también se construyeron chips MIPS de altas prestaciones.
- SPARC: es otra ISA de tipo RISC diseñada inicialmente por Sun Microsystems y ahora licenciada para otros muchos procesadores.
- POWER ISA: se trata de una ISA RISC de alto rendimiento de IBM. Usada para chips PowerPC e IBM POWER.
- z/Architecture: otra ISA CISC de IBM, esta vez para mainframes.
- RISC-V: una ISA de código abierto diseñada para sistemas de todo tipo, y un posible rival de ARM con mucho potencial para el PC, el HPC, o para IoT, etc.
A medida que la tecnología de computación ha evolucionado, también lo ha hecho la ISA. Las nuevas ISA a menudo agregan nuevas características y extensiones para mejorar el rendimiento, la seguridad y la eficiencia energética. También se han desarrollado ISA especializadas para tareas específicas, como el aprendizaje automático y la criptografía. O al menos, se han incluido extensiones especificas para ello.
Tipos de ISA
Existen varios tipos de ISA, que se diferencian en cómo se organizan las instrucciones y cómo se procesan en el hardware del procesador. A continuación, se describen algunos de los tipos más comunes de ISA:
- CISC (Complex Instruction Set Computing): es una arquitectura de procesador que se caracteriza por tener un conjunto de instrucciones complejas y amplio. Las instrucciones CISC se pueden ejecutar en una sola instrucción y pueden manipular múltiples operaciones de memoria. Los procesadores CISC son más adecuados para tareas generales y manejo de datos grandes.
- RISC (Reduced Instruction Set Computing): es una arquitectura de procesador que se caracteriza por tener un conjunto de instrucciones simples y reducido. Las instrucciones RISC se ejecutan en ciclos de reloj más cortos y sólo realizan una sola operación en cada ciclo. Los procesadores RISC son más adecuados para tareas de procesamiento de señales y aplicaciones de red.
- ZISC (Zero Instruction Set Computing): es una arquitectura de procesador que se caracteriza por no tener un conjunto de instrucciones predefinido. En cambio, utiliza una red de células de procesamiento que se comunican entre sí para realizar operaciones y cálculos. Los procesadores ZISC son más adecuados para aplicaciones de inteligencia artificial y procesamiento de patrones.
- SISC (Single Instruction Set Computing): es una arquitectura de procesador que se caracteriza por tener sólo una instrucción en su conjunto de instrucciones. Esta instrucción se utiliza para especificar la operación que se realizará en todos los datos de entrada. Los procesadores SISC son más adecuados para aplicaciones de procesamiento de señales.
- VISC (Very Long Instruction Word Computing): es una arquitectura de procesador que se caracteriza por tener instrucciones largas que contienen múltiples operaciones que se ejecutan simultáneamente. Los procesadores VISC son más adecuados para aplicaciones de procesamiento de gráficos y multimedia.
- DISC (Distributed Instruction Set Computing): es una arquitectura de procesador que se caracteriza por tener un conjunto de instrucciones distribuido, donde cada instrucción se ejecuta en un procesador diferente. Los procesadores DISC son más adecuados para aplicaciones de procesamiento paralelo.
- NISC (Network Instruction Set Computing): es una arquitectura de procesador que se caracteriza por tener múltiples procesadores que se comunican entre sí mediante una red de interconexión. Cada procesador tiene su propio conjunto de instrucciones y puede realizar operaciones independientemente. Los procesadores NISC son más adecuados para aplicaciones de procesamiento de datos grandes.
- MISC (Minimal Instruction Set Computing): es una arquitectura de procesador que se caracteriza por tener un conjunto de instrucciones muy reducido, similar a RISC. Los procesadores MISC son más adecuados para aplicaciones de dispositivos móviles y sistemas empotrados.
- EDGE (Explicit Data Graph Execution): es una arquitectura de procesador que se caracteriza por ejecutar operaciones en un grafo de datos explícito, en lugar de en un conjunto de instrucciones. Los procesadores EDGE son más adecuados para aplicaciones de procesamiento de señales, aplicaciones de baja potencia y alta eficiencia, etc., como por ejemplo los DSP o procesadores de sonido.
- OISC (One Instruction Set Computing): arquitectura de conjunto de instrucciones de una sola instrucción, es un tipo de ISA extremadamente simple que utiliza solo una instrucción. Aunque la OISC es muy limitada en términos de capacidad de procesamiento, puede ser útil para ciertas aplicaciones específicas, como la implementación de algoritmos simples de criptografía.
- VLWI (Very Long Instruction Word): es una ISA que implementa paralelismo a nivel de instrucción, con un arquitectura superscalar en la que se encajan las instrucciones largas gracias al trabajo de optimización del compilador.
Existen diseños que pueden usar una ISA CISC, mientras que a nivel de hardware emplean un sistema RISC-like, como es el caso de los procesadores de Intel y AMD. De esta forma, se consiguen mejoras a nivel de hardware, pero sin dejar atrás la compatibilidad para la vieja ISA x86, que fue diseñada como CISC. Es decir, usan una traducción dinámica durante la etapa de decodificación, traduciendo las coplejas CISC en microops o microoperaciones más simples al estilo RISC.
Extensiones
Las extensiones de una ISA, también conocidas como extensiones de conjunto de instrucciones, son adiciones o mejoras a una ISA existente. Estas extensiones se utilizan para añadir nuevas características o funcionalidades a la ISA base sin tener que reemplazar completamente la ISA original.
Las extensiones de una ISA pueden tomar varias formas. Por ejemplo, pueden incluir nuevas instrucciones que amplíen el conjunto de instrucciones existente, o bien nuevos modos de direccionamiento para facilitar el acceso a la memoria y a otros recursos del sistema. Las extensiones también pueden mejorar la arquitectura de la CPU, como agregar coprocesadores especializados para acelerar tareas específicas.
Las extensiones de una ISA son una forma común de mejorar el rendimiento y la funcionalidad de una arquitectura de CPU existente sin tener que rediseñar completamente la arquitectura. También permiten a los diseñadores de chips personalizar la arquitectura de CPU para aplicaciones específicas, ya que las extensiones se pueden agregar o eliminar según sea necesario.
Algunos ejemplos de extensiones de ISA populares incluyen Intel MMX, Intel SSE, AMD 3D Now!, Intel AVX, ARM SVE, Apple AMX, etc. Evidentemente, estas instrucciones, para ser aprovechadas, necesitan que el código fuente de los programas se compile haciendo uso de ellas.
Taxonomía de Flynn
La taxonomía de Flynn es un modelo conceptual utilizado para clasificar las arquitecturas de las computadoras según la forma en que manejan y ejecutan las instrucciones. La taxonomía de Flynn establece cuatro categorías diferentes según la cantidad de instrucciones y datos que se manejan simultáneamente. Estos cuatro tipos de taxonomía de Flynn son:
- SISD (Single Instruction, Single Data): este tipo ejecuta una sola instrucción y opera sobre un único conjunto de datos a la vez. Es la arquitectura más simple y se utiliza en muchas de las CPUs. Por ejemplo, una instrucción ADD que suma dos operandos presentes en los registros de la CPU.
- SIMD (Single Instruction, Multiple Data): en este caso se ejecuta una instrucción que será aplicada sobre varios conjuntos de datos. Es empleado por GPUs y también para ciertas FPUs donde se ejecutan instrucciones SIMD perteneceintes a las extensiones de la ISA. Por ejemplo, muchos procesadores actuales como los Intel Core, AMD Ryzen, etc., usan extensiones como las AVX, cada instrucción de este set puede aplicarse sobre vectores de datos.
- MISD (Multiple Instruction, Single Data): como su propio nombre indica, se ejecutan de forma paralela varias instrucciones y se aplican a los mismos datos o conjunto de datos. Es un tipo bastante raro, y solo se usa en algunos casos extraños o en sistemas experimentales.
- MIMD (Multiple Instruction, Multiple Data): en esta otra tenemos varias instrucciones ejecutándose al mismo tiempo y siendo aplicadas sobre múltiples datos o vectores. Es otro caso extraño, pero puede usarse para algunas máquinas HPC o de alto rendimiento.
Es importante tener en cuenta que estos tipos de taxonomía de Flynn son una clasificación conceptual, y muchas arquitecturas de CPU modernas pueden tener características que se superponen o no se ajustan exactamente a una sola categoría.
¿Una GPU tiene ISA?
Sí, una GPU (Graphics Processing Unit) también tiene una ISA como la CPU (Central Processing Unit). Aunque las GPU se diseñan de tal forma que la ISA en la mayoría de los casos no se hace pública o no existe un código ensamblador para GPU que los desarrolladores puedan usar como en el caso de la CPU.
Las GPU tienen una ISA que se especializa en paralelizar el procesamiento de datos en múltiples núcleos, lo que les permite procesar grandes cantidades de información simultáneamente. Esta ISA se ha diseñado para adaptarse específicamente a la naturaleza de los cálculos gráficos, como el sombreado y la renderización de imágenes, así como para operaciones matemáticas intensivas, como el procesamiento de señales y el aprendizaje automático.
No obstante, como ya sabes, la GPU también puede programarse para propósito general, para acelerar ciertas cargas de trabajo, especialmente las que necesitan gran cantidad de cálculos de coma flotante, como las aplicaciones científicas, las de IA, etc. Esto es lo que se conoce como GPGPU, como ya sabrás, y en este caso no se usa la ISA en sí de la GPU, sino que se hace a través de APIs que ayudan a los desarrolladores, como OpenCL, CUDA, etc.
¿Qué es una microarquitectura?
La microarquitectura se refiere a la forma en que se implementa una ISA en un procesador específico, ya sea una CPU, una GPU, etc. Es decir, es la forma en que los diseñadores de procesadores organizan los componentes internos de un procesador para ejecutar las instrucciones definidas por la ISA.
La microarquitectura se enfoca en los detalles a nivel de circuito del procesador, incluyendo la organización de los registros internos, la unidad de control, las unidades de ejecución, las cachés, el sistema de interconexión, entre otros elementos. La microarquitectura debe ser diseñada de manera que las instrucciones se puedan ejecutar de manera eficiente, rápida y con el menor consumo de energía posible.
La microarquitectura tiene una gran influencia en el rendimiento del procesador, ya que determina cuántas instrucciones se pueden ejecutar por ciclo de reloj y cuántos ciclos de reloj se necesitan para ejecutar una instrucción. Por lo tanto, la microarquitectura es un factor clave en la mejora del rendimiento de los procesadores y en la reducción de su consumo de energía.
Por este motivo, con cada nueva generación de una microarquitectura de CPU o de GPU, el rendimiento mejora respecto a la generación anterior, aunque la ISA sea la misma. Por ejemplo, la microarquitectura AMD Zen 4 ha mejorado a la Zen 3, aunque ambas son implementaciones de la ISA x86-64.
También te puede interesar: qué son las instrucciones no documentadas o illegal op-codes
¿Puede haber varias microarquitecturas diferentes que ejecuten una misma ISA?
Sí, es posible que haya varias microarquitecturas diferentes para una misma ISA. La ISA es la especificación de un conjunto de instrucciones que un procesador debe ser capaz de entender y ejecutar, mientras que la microarquitectura es la implementación específica de esa ISA en un procesador, como he avanzado en el apartado anterior.
Por lo tanto, aunque dos procesadores puedan implementar la misma ISA, pueden tener microarquitecturas diferentes. Esto significa que pueden tener diferentes diseños internos de hardware, organización de unidades funcionales, tipos y tamaños de caché, entre otros factores. Es el caso de un Intel Core y un AMD Ryzen, ambos tienen microarquitecturas diferentes, pero usan la misma ISA x86-64. Lo mismo ocurre con un AMD Zen 3 y un Zen 4, o entre un Intel Meteor Lake y un Raptor Lake, diferentes microarquitecturas, misma ISA…
La elección de una microarquitectura en particular para implementar una ISA dependerá de muchos factores, como el rendimiento deseado, la eficiencia energética, el costo y el tiempo de desarrollo. Por ejemplo, una microarquitectura que priorice el rendimiento puede tener una mayor cantidad de unidades de ejecución y cachés de mayor tamaño, mientras que una microarquitectura que priorice la eficiencia energética puede tener menos unidades de ejecución y cachés más pequeñas.
En los actuales procesadores heterogéneos, también puede haber varias microarquitecturas en los diferentes núcleos. Por ejemplo, el Intel Core i9-13900K Raptor Lake-S se compone de P-Cores y E-cores, los núcleos de alto rendimiento se basan en la microarquitectura Raptor Cove, mientras que los núcleos de alta eficiencia se basa en los Gracemont. Abos con una ISA igual, pero toleran diferentes extensiones.
Multiple instruction sets architecture (MISA)
Un Composite-ISA core es un tipo de núcleo de procesador que combina diferentes conjuntos de instrucciones, o ISAs, en una sola unidad de procesamiento. La idea detrás de un Composite-ISA core es proporcionar una mayor flexibilidad y eficiencia en la ejecución de diferentes tipos de aplicaciones y tareas sin necesidad de usar software de emulación o capas que puedan afectar al rendimiento.
Esto también se conoce con el término MISA (Multiple Instruction Set Architecture). En otras palabras, un procesador MISA puede cambiar entre diferentes ISAs para adaptarse a diferentes tipos de aplicaciones o tareas.
La idea detrás de MISA es que diferentes tipos de aplicaciones tienen diferentes requisitos de procesamiento y, por lo tanto, pueden beneficiarse de diferentes conjuntos de instrucciones. Y, aunque por lo general los chips con arquitecturas MISA son realmente extraños, y solo ha habido unos pocos a lo largo de la historia, no significa que no sea posible.
MISA puede implementarse de varias maneras. Una forma es tener múltiples núcleos o procesadores, cada uno con su propio conjunto de instrucciones especializado. Otra forma es tener un solo procesador con múltiples unidades de ejecución y múltiples conjuntos de instrucciones, cada uno diseñado para manejar tareas específicas.
También pueden ser prácticas para ciertas CPUs que necesitan ser compatibles con un software compilado para otra ISA, pero que no tienen licencia específica para usar esa ISA, como es el caso de algunos chips desarrollados por China o Rusia para no tener que depender de EE.UU. en tecnología.
¿Y un mismo núcleo?
Cuanto más diferentes sean las ISAs, más difícil sería. Y más gastos generales costaría, especialmente algunas partes de la microarquitectura. No es tan fácil como colocar un front-end diferente en un diseño de microarquitectura de back-end común.
Si fuera solo un costo de área de troquel para diferentes decodificadores, no otras diferencias de potencia o rendimiento, eso sería menor y totalmente viable en estos días, con grandes cantidades de transistores. Además, ten en cuenta que no solo habrá que trabajar en el hardware, también desde el lado del software, especialmente en el sistema operativo, que debe soportar las distintas ISAs empleadas y trabajar de forma adecuada con los diferentes binarios que deberá gestionar.
Agregar la capacidad de compatibilidad con ARM a un procesador x86, por ejemplo, lo haría más lento y menos eficiente en el consumo de energía cuando se ejecuta código x86-64 puro, además de costar más área en el chip al tener que crear un front-end más complejo para poder lidiar con ambas instrucciones. Eso no vale la pena comercialmente, dado el mercado limitado y la necesidad de un sistema operativo especial o un software de hipervisor para incluso aprovecharlo.
Ejecutar las instrucciones de la ISA ARM necesita de un hardware o microarquitectura especialmente optimizada para ganar rendimiento y eficiencia. Hacer lo mismo para x86 también. Pero hacer un procesador de alto rendimiento y eficiente que soporte varias ISAs es palabras mayores. Además, incluso se necesitarían cambiar el back-end, es decir, las unidades de ejecución, ya que una ISA podría necesitar de un tipo de operaciones que otra no necesita…
En el caso del ejemplo que he puesto, mientras en las SIMD de ARM tenemos instrucciones que pueden generar hasta 2 salidas de datos, en las SIMD de x86 tenemos que las instrucciones generan solo una salida de datos. Esto también necesitaría la forma de implementar los registros, los puertos necesarios, etc. Además, en este caso de las x86 y las ARM, estamos hablando de una CISC y una RISC, y aunque hemos dicho antes que los procesadores x86 actuales funcionan como RISC-like a nivel de hardware, esto no quiere decir que sean RISC puros, y tienen diferencias arquitectónicas.
Además, en el caso de meclar binarios de diferentes ISAs, tenemos también otro problema, y es que si se lleva a cabo algún tipo de paralelismo, al nivel que sea, podría implicar cambios de contexto más complejos que cuando se usa solo una ISA, para no mezclar flujos de diferentes instrucciones y llevar a errores. Esto, además de comlejo, también puede resultar más lento.
Las diferencias también se podrían ver a nivel de movimientos de datos o modos de direccionamiento presentes, al nivel de tablas de páginas de la memoria, etc. Todo afectando tanto a la CPU como al sistema operativo. Por ejemplo, el kernel del SO debería saber si se está ejecutando un tipo de ISA u otro, para realizar las llamadas al sistema o syscalls necesarias, ya que no serán iguales en ambos casos.
Por este motivo, lo mejor suele ser emplear emulación o virtualización para estos casos, evitando muchos problemas. Y es por eso que muchos han optado por implementar soluciones a nivel de software, como es el caso de la traducción binaria de Rosetta de Apple para traducir los binarios de la ISA PowerPC a x86 cuando hicieron el cambio a chips de Intel o Rosetta 2 para traducir binarios de x86 a ARM cuando hicieron el cambio a Apple Silicon.
JIT
Apple Computer implementó un emulador de traducción dinámica para el código M68K en su línea PowerPC de Macintosh, que logró un nivel muy alto de confiabilidad, rendimiento y compatibilidad. Y es que recordemos que estas máquinas Mac antes emplearon los procesadores Motorola 68000 antes de pasar a los PowerPC cuando se estableció la alianza AIM (Apple IBM Motorola). Este software de emulación o traductor se empleó para los sistemas operativos denominados macOS Classic, es decir, los que se implementaron antes del paso a sistema Unix (Mac OS X).
Mac OS X 10.4.4 para Mac con procesador Intel introdujo la capa de traducción dinámica de Rosetta 1 para facilitar la transición de Apple del hardware basado en PPC a x86, como he mencionado anteriormente. Desarrollado para Apple por Transitive Corporation, el software Rosetta es una implementación de la solución QuickTransit de Transitive.
Como ya dije antes, también tenemos Rosetta 2, que es similar al caso anterior, pero en este caso para poder seguir ejecutando el software o binarios x86 de los chips de Intel bajo los chips Apple Silicon, como los M-Series. No obstante, como la ISA ARM carecía de ciertas extensiones o funciones para virtualización, por ejemplo, algunos programas como los hipervisores no funcionaban bien y hubo muchos problemas para algunos usuarios que dependían de este software, hasta que se terminó implementado de forma nativa para los chips ARM.
Sin embargo, a lo largo de la historia, Apple no ha sido la única. DEC (Digital Equipment Corp) logró un éxito similar con sus herramientas de traducción para ayudar a los usuarios a migrar de la arquitectura CISC VAX a la arquitectura Alpha RISC. También hicoeron algo parecido para traducir binarios x86 en Alpha, para mejorar la compatibilidad del software para plataformas de este tipo que fueron usadas en HPC y workstations.
Sun Microsystems también desarrolló un software de traducción dinámica de instrucciones x86 en SPARC con objetivos similares a DEC.
HP ARIES es otro ejemplo de traducción binaria dinámica por software, pero en este caso empleado para poder traducir los códigos para HP 9000 HP-UX en HP-UX 11i para servidores HPE.
En enero de 2000, Transmeta Corporation anunció un nuevo diseño de procesador llamado Crusoe, y su sucesor Efficeon, ambos VLIW con diferentes tamaños o longitud de instrucciones, pero que implementaban el Code Morphing que era capaz de tarducir al vuelo las instrucciones x86 del software a VLIW para que fuese compatible, eso sí, el código de Linus tenía que ejecutarse siempre en segundo plano, lo cual no es lo más óptimo para rendimiento.
Intel Corporation desarrolló e implementó una capa de ejecución IA-32, un traductor binario dinámico diseñado para admitir aplicaciones IA-32 en sistemas basados en Itanium, que se incluyó en Microsoft Windows Server para la arquitectura Itanium, así como en varias versiones de Linux, incluidas Red Hat y SUSE que se usaron en supercomputadoras con este procesador. Recuerda que el Itanium se basa en la ISA IA-64, que no es una x86-64, como muchos piensan, sino que se trata de otra diferente, y no compatible con las x86 a no ser por este modo.
Dolphin (un emulador para GameCube/Wii) realiza una compilación JIT del código PowerPC a x86 y AArch64. Y ya conoces todos los emuladores que existen para multitud de plataformas de consolas u ordenadores del pasado. Además de software como puede ser QEMU, que también permite emular una gran cantidad de arquitecturas diferentes sobre sistemas Linux x86, por ejemplo. En cambio, no hay que confundir los JIT con los emuladores, ya que no son lo mismo. Un JIT es un traductor binario, un emulador es una implementación por software de una arquitectura, para engalar al software y que crea que está ejecutándose sobre la ISA original, lo cual también implica traducción, pero también otros aspectos.
- Elbrus: este procesador es desarrollado por la empresa rusa MCST y utiliza una ISA llamada Elbrus. Sin embargo, también es compatible con la ISA x86 de Intel, lo que permite ejecutar software de Windows y Linux diseñado para x86. No obstante, en un inicio, estos procesadores también usaron la ISA SPARC, aunque actualmente hayan desarrollado una propia.
- IBM PowerPC 615: este procesador fue desarrollado por IBM y se utilizó en servidores y estaciones de trabajo. Utiliza una ISA llamada PowerPC, pero también es compatible con la ISA x86 al implementar un núcleo x86. Este procesador podía trabajar tanto en podía trabajar con el sistema operativo corriendo sobre PPC, tanto en modo 32-bit como en modo 64-bit, y también en un modo para x86-32, e incluso en un modo mixto entre las tres, aunque el cambio de contexto en el modo mixto implicaba cierto retraso. Los únicos sistemas operativos que soportaron este chip fueron una versión de OS/2 especial de IBM y Minix.
- Transmeta Crusoe: el procesador fue compatible con las ISA x86 y VLIW (Very Long Instruction Word). La compatibilidad con VLIW permitió que el procesador ejecutara instrucciones complejas de manera más eficiente, lo que resultó en un mayor rendimiento y menor consumo de energía. Lo hacía mediante un código denominado Code Morphing, creado por el mismo Linus Torvalds cuando trabajó en esta compañía, permitiendo ser compatible con software x86 aunque el procesador, a nivel de hardware, era un VLIW.
- AMD e Intel: Intel con su Pentium Pro y AMD con su K5, hicieron algo parecido para seguir siendo compatibles con el software basado en la ISA CISC x86, pero tener las ventajas de una arquitectura RISC a nivel de hardware. Por ejemplo, un dato curioso es que el K5 de AMD usó como base un procesador AMD 29000, que fue un chip RISC bastante popular en su época, y al que agregaron un tarductor de instrucciones CISC a RISC-like en el front-end.
- NVIDIA Tegra K1 Denver: es capaz de traducir instrucciones ARM a través de un decodificador de hardware a instrucciones nativas de microcódigo, usando un traductor binario de software.
En general, la compatibilidad con varias arquitecturas se logra mediante la emulación de software, lo que puede limitar el rendimiento y la velocidad, pero la implementación por hardware puede ser aún peor…
Ejemplos de traducción por software
Apple Computer implementó un emulador de traducción dinámica para el código M68K en su línea PowerPC de Macintosh, que logró un nivel muy alto de confiabilidad, rendimiento y compatibilidad. Y es que recordemos que estas máquinas Mac antes emplearon los procesadores Motorola 68000 antes de pasar a los PowerPC cuando se estableció la alianza AIM (Apple IBM Motorola). Este software de emulación o traductor se empleó para los sistemas operativos denominados macOS Classic, es decir, los que se implementaron antes del paso a sistema Unix (Mac OS X).
Mac OS X 10.4.4 para Mac con procesador Intel introdujo la capa de traducción dinámica de Rosetta 1 para facilitar la transición de Apple del hardware basado en PPC a x86, como he mencionado anteriormente. Desarrollado para Apple por Transitive Corporation, el software Rosetta es una implementación de la solución QuickTransit de Transitive.
Como ya dije antes, también tenemos Rosetta 2, que es similar al caso anterior, pero en este caso para poder seguir ejecutando el software o binarios x86 de los chips de Intel bajo los chips Apple Silicon, como los M-Series. No obstante, como la ISA ARM carecía de ciertas extensiones o funciones para virtualización, por ejemplo, algunos programas como los hipervisores no funcionaban bien y hubo muchos problemas para algunos usuarios que dependían de este software, hasta que se terminó implementado de forma nativa para los chips ARM.
Sin embargo, a lo largo de la historia, Apple no ha sido la única. DEC (Digital Equipment Corp) logró un éxito similar con sus herramientas de traducción para ayudar a los usuarios a migrar de la arquitectura CISC VAX a la arquitectura Alpha RISC. También hicoeron algo parecido para traducir binarios x86 en Alpha, para mejorar la compatibilidad del software para plataformas de este tipo que fueron usadas en HPC y workstations.
Sun Microsystems también desarrolló un software de traducción dinámica de instrucciones x86 en SPARC con objetivos similares a DEC.
HP ARIES es otro ejemplo de traducción binaria dinámica por software, pero en este caso empleado para poder traducir los códigos para HP 9000 HP-UX en HP-UX 11i para servidores HPE.
En enero de 2000, Transmeta Corporation anunció un nuevo diseño de procesador llamado Crusoe, y su sucesor Efficeon, ambos VLIW con diferentes tamaños o longitud de instrucciones, pero que implementaban el Code Morphing que era capaz de tarducir al vuelo las instrucciones x86 del software a VLIW para que fuese compatible, eso sí, el código de Linus tenía que ejecutarse siempre en segundo plano, lo cual no es lo más óptimo para rendimiento.
Intel Corporation desarrolló e implementó una capa de ejecución IA-32, un traductor binario dinámico diseñado para admitir aplicaciones IA-32 en sistemas basados en Itanium, que se incluyó en Microsoft Windows Server para la arquitectura Itanium, así como en varias versiones de Linux, incluidas Red Hat y SUSE que se usaron en supercomputadoras con este procesador. Recuerda que el Itanium se basa en la ISA IA-64, que no es una x86-64, como muchos piensan, sino que se trata de otra diferente, y no compatible con las x86 a no ser por este modo.
Dolphin (un emulador para GameCube/Wii) realiza una compilación JIT del código PowerPC a x86 y AArch64. Y ya conoces todos los emuladores que existen para multitud de plataformas de consolas u ordenadores del pasado. Además de software como puede ser QEMU, que también permite emular una gran cantidad de arquitecturas diferentes sobre sistemas Linux x86, por ejemplo. En cambio, no hay que confundir los JIT con los emuladores, ya que no son lo mismo. Un JIT es un traductor binario, un emulador es una implementación por software de una arquitectura, para engalar al software y que crea que está ejecutándose sobre la ISA original, lo cual también implica traducción, pero también otros aspectos.
Es cierto que hay varios procesadores que soportan varias arquitecturas, como los que mencionaste:
- Elbrus: este procesador es desarrollado por la empresa rusa MCST y utiliza una ISA llamada Elbrus. Sin embargo, también es compatible con la ISA x86 de Intel, lo que permite ejecutar software de Windows y Linux diseñado para x86. No obstante, en un inicio, estos procesadores también usaron la ISA SPARC, aunque actualmente hayan desarrollado una propia.
- IBM PowerPC 615: este procesador fue desarrollado por IBM y se utilizó en servidores y estaciones de trabajo. Utiliza una ISA llamada PowerPC, pero también es compatible con la ISA x86 al implementar un núcleo x86. Este procesador podía trabajar tanto en podía trabajar con el sistema operativo corriendo sobre PPC, tanto en modo 32-bit como en modo 64-bit, y también en un modo para x86-32, e incluso en un modo mixto entre las tres, aunque el cambio de contexto en el modo mixto implicaba cierto retraso. Los únicos sistemas operativos que soportaron este chip fueron una versión de OS/2 especial de IBM y Minix.
- Transmeta Crusoe: el procesador fue compatible con las ISA x86 y VLIW (Very Long Instruction Word). La compatibilidad con VLIW permitió que el procesador ejecutara instrucciones complejas de manera más eficiente, lo que resultó en un mayor rendimiento y menor consumo de energía. Lo hacía mediante un código denominado Code Morphing, creado por el mismo Linus Torvalds cuando trabajó en esta compañía, permitiendo ser compatible con software x86 aunque el procesador, a nivel de hardware, era un VLIW.
- AMD e Intel: Intel con su Pentium Pro y AMD con su K5, hicieron algo parecido para seguir siendo compatibles con el software basado en la ISA CISC x86, pero tener las ventajas de una arquitectura RISC a nivel de hardware. Por ejemplo, un dato curioso es que el K5 de AMD usó como base un procesador AMD 29000, que fue un chip RISC bastante popular en su época, y al que agregaron un tarductor de instrucciones CISC a RISC-like en el front-end.
- NVIDIA Tegra K1 Denver: es capaz de traducir instrucciones ARM a través de un decodificador de hardware a instrucciones nativas de microcódigo, usando un traductor binario de software.
En general, la compatibilidad con varias arquitecturas se logra mediante la emulación de software, lo que puede limitar el rendimiento y la velocidad, pero la implementación por hardware puede ser aún peor…
Ejemplos de traducción por software
Apple Computer implementó un emulador de traducción dinámica para el código M68K en su línea PowerPC de Macintosh, que logró un nivel muy alto de confiabilidad, rendimiento y compatibilidad. Y es que recordemos que estas máquinas Mac antes emplearon los procesadores Motorola 68000 antes de pasar a los PowerPC cuando se estableció la alianza AIM (Apple IBM Motorola). Este software de emulación o traductor se empleó para los sistemas operativos denominados macOS Classic, es decir, los que se implementaron antes del paso a sistema Unix (Mac OS X).
Mac OS X 10.4.4 para Mac con procesador Intel introdujo la capa de traducción dinámica de Rosetta 1 para facilitar la transición de Apple del hardware basado en PPC a x86, como he mencionado anteriormente. Desarrollado para Apple por Transitive Corporation, el software Rosetta es una implementación de la solución QuickTransit de Transitive.
Como ya dije antes, también tenemos Rosetta 2, que es similar al caso anterior, pero en este caso para poder seguir ejecutando el software o binarios x86 de los chips de Intel bajo los chips Apple Silicon, como los M-Series. No obstante, como la ISA ARM carecía de ciertas extensiones o funciones para virtualización, por ejemplo, algunos programas como los hipervisores no funcionaban bien y hubo muchos problemas para algunos usuarios que dependían de este software, hasta que se terminó implementado de forma nativa para los chips ARM.
Sin embargo, a lo largo de la historia, Apple no ha sido la única. DEC (Digital Equipment Corp) logró un éxito similar con sus herramientas de traducción para ayudar a los usuarios a migrar de la arquitectura CISC VAX a la arquitectura Alpha RISC. También hicoeron algo parecido para traducir binarios x86 en Alpha, para mejorar la compatibilidad del software para plataformas de este tipo que fueron usadas en HPC y workstations.
Sun Microsystems también desarrolló un software de traducción dinámica de instrucciones x86 en SPARC con objetivos similares a DEC.
HP ARIES es otro ejemplo de traducción binaria dinámica por software, pero en este caso empleado para poder traducir los códigos para HP 9000 HP-UX en HP-UX 11i para servidores HPE.
En enero de 2000, Transmeta Corporation anunció un nuevo diseño de procesador llamado Crusoe, y su sucesor Efficeon, ambos VLIW con diferentes tamaños o longitud de instrucciones, pero que implementaban el Code Morphing que era capaz de tarducir al vuelo las instrucciones x86 del software a VLIW para que fuese compatible, eso sí, el código de Linus tenía que ejecutarse siempre en segundo plano, lo cual no es lo más óptimo para rendimiento.
Intel Corporation desarrolló e implementó una capa de ejecución IA-32, un traductor binario dinámico diseñado para admitir aplicaciones IA-32 en sistemas basados en Itanium, que se incluyó en Microsoft Windows Server para la arquitectura Itanium, así como en varias versiones de Linux, incluidas Red Hat y SUSE que se usaron en supercomputadoras con este procesador. Recuerda que el Itanium se basa en la ISA IA-64, que no es una x86-64, como muchos piensan, sino que se trata de otra diferente, y no compatible con las x86 a no ser por este modo.
Dolphin (un emulador para GameCube/Wii) realiza una compilación JIT del código PowerPC a x86 y AArch64. Y ya conoces todos los emuladores que existen para multitud de plataformas de consolas u ordenadores del pasado. Además de software como puede ser QEMU, que también permite emular una gran cantidad de arquitecturas diferentes sobre sistemas Linux x86, por ejemplo. En cambio, no hay que confundir los JIT con los emuladores, ya que no son lo mismo. Un JIT es un traductor binario, un emulador es una implementación por software de una arquitectura, para engalar al software y que crea que está ejecutándose sobre la ISA original, lo cual también implica traducción, pero también otros aspectos.
Just-in-time» (JIT) o «dynamic translation» o «run-time compilation» son términos que se refieren a un proceso de compilación que ocurre durante el tiempo de ejecución de un programa en lugar de antes de la ejecución, como ocurre con la compilación estática.
En un sistema de compilación estática, el código fuente se compila en código ejecutable antes de que se ejecute el programa. Por otro lado, en un sistema así no necsita de una compilación previa.
Esto se logra mediante un compilador especial llamado «just-in-time compiler», que toma el código fuente y lo compila en código ejecutable en tiempo real, a medida que se ejecuta el programa. La ventaja de esto es que el código se puede optimizar para la plataforma de hardware y el entorno de ejecución en tiempo real, lo que puede mejorar significativamente el rendimiento del programa.
Una desventaja de la compilación «just-in-time» es que puede llevar un tiempo de inicio más largo para el programa, ya que el proceso de compilación tiene que ocurrir en tiempo real antes de que se ejecute el código. Además, la compilación «just-in-time» puede requerir más memoria y recursos del sistema que la compilación estática.
La compilación «just-in-time» se utiliza comúnmente en lenguajes de programación como Java y JavaScript, y también se utiliza en sistemas de emulación de lenguaje como el CLR de Microsoft en el .NET Framework. No obstante, en la actualidad, también se ha propuesto para traducir binarios de un tipo a otro y mejorar la compatibilidad o soporte de software para una plataforma…
Ejemplos de procesadores que usan varias ISAs
Es cierto que hay varios procesadores que soportan varias arquitecturas, como los que mencionaste:
- Elbrus: este procesador es desarrollado por la empresa rusa MCST y utiliza una ISA llamada Elbrus. Sin embargo, también es compatible con la ISA x86 de Intel, lo que permite ejecutar software de Windows y Linux diseñado para x86. No obstante, en un inicio, estos procesadores también usaron la ISA SPARC, aunque actualmente hayan desarrollado una propia.
- IBM PowerPC 615: este procesador fue desarrollado por IBM y se utilizó en servidores y estaciones de trabajo. Utiliza una ISA llamada PowerPC, pero también es compatible con la ISA x86 al implementar un núcleo x86. Este procesador podía trabajar tanto en podía trabajar con el sistema operativo corriendo sobre PPC, tanto en modo 32-bit como en modo 64-bit, y también en un modo para x86-32, e incluso en un modo mixto entre las tres, aunque el cambio de contexto en el modo mixto implicaba cierto retraso. Los únicos sistemas operativos que soportaron este chip fueron una versión de OS/2 especial de IBM y Minix.
- Transmeta Crusoe: el procesador fue compatible con las ISA x86 y VLIW (Very Long Instruction Word). La compatibilidad con VLIW permitió que el procesador ejecutara instrucciones complejas de manera más eficiente, lo que resultó en un mayor rendimiento y menor consumo de energía. Lo hacía mediante un código denominado Code Morphing, creado por el mismo Linus Torvalds cuando trabajó en esta compañía, permitiendo ser compatible con software x86 aunque el procesador, a nivel de hardware, era un VLIW.
- AMD e Intel: Intel con su Pentium Pro y AMD con su K5, hicieron algo parecido para seguir siendo compatibles con el software basado en la ISA CISC x86, pero tener las ventajas de una arquitectura RISC a nivel de hardware. Por ejemplo, un dato curioso es que el K5 de AMD usó como base un procesador AMD 29000, que fue un chip RISC bastante popular en su época, y al que agregaron un tarductor de instrucciones CISC a RISC-like en el front-end.
- NVIDIA Tegra K1 Denver: es capaz de traducir instrucciones ARM a través de un decodificador de hardware a instrucciones nativas de microcódigo, usando un traductor binario de software.
En general, la compatibilidad con varias arquitecturas se logra mediante la emulación de software, lo que puede limitar el rendimiento y la velocidad, pero la implementación por hardware puede ser aún peor…
Ejemplos de traducción por software
Apple Computer implementó un emulador de traducción dinámica para el código M68K en su línea PowerPC de Macintosh, que logró un nivel muy alto de confiabilidad, rendimiento y compatibilidad. Y es que recordemos que estas máquinas Mac antes emplearon los procesadores Motorola 68000 antes de pasar a los PowerPC cuando se estableció la alianza AIM (Apple IBM Motorola). Este software de emulación o traductor se empleó para los sistemas operativos denominados macOS Classic, es decir, los que se implementaron antes del paso a sistema Unix (Mac OS X).
Mac OS X 10.4.4 para Mac con procesador Intel introdujo la capa de traducción dinámica de Rosetta 1 para facilitar la transición de Apple del hardware basado en PPC a x86, como he mencionado anteriormente. Desarrollado para Apple por Transitive Corporation, el software Rosetta es una implementación de la solución QuickTransit de Transitive.
Como ya dije antes, también tenemos Rosetta 2, que es similar al caso anterior, pero en este caso para poder seguir ejecutando el software o binarios x86 de los chips de Intel bajo los chips Apple Silicon, como los M-Series. No obstante, como la ISA ARM carecía de ciertas extensiones o funciones para virtualización, por ejemplo, algunos programas como los hipervisores no funcionaban bien y hubo muchos problemas para algunos usuarios que dependían de este software, hasta que se terminó implementado de forma nativa para los chips ARM.
Sin embargo, a lo largo de la historia, Apple no ha sido la única. DEC (Digital Equipment Corp) logró un éxito similar con sus herramientas de traducción para ayudar a los usuarios a migrar de la arquitectura CISC VAX a la arquitectura Alpha RISC. También hicoeron algo parecido para traducir binarios x86 en Alpha, para mejorar la compatibilidad del software para plataformas de este tipo que fueron usadas en HPC y workstations.
Sun Microsystems también desarrolló un software de traducción dinámica de instrucciones x86 en SPARC con objetivos similares a DEC.
HP ARIES es otro ejemplo de traducción binaria dinámica por software, pero en este caso empleado para poder traducir los códigos para HP 9000 HP-UX en HP-UX 11i para servidores HPE.
En enero de 2000, Transmeta Corporation anunció un nuevo diseño de procesador llamado Crusoe, y su sucesor Efficeon, ambos VLIW con diferentes tamaños o longitud de instrucciones, pero que implementaban el Code Morphing que era capaz de tarducir al vuelo las instrucciones x86 del software a VLIW para que fuese compatible, eso sí, el código de Linus tenía que ejecutarse siempre en segundo plano, lo cual no es lo más óptimo para rendimiento.
Intel Corporation desarrolló e implementó una capa de ejecución IA-32, un traductor binario dinámico diseñado para admitir aplicaciones IA-32 en sistemas basados en Itanium, que se incluyó en Microsoft Windows Server para la arquitectura Itanium, así como en varias versiones de Linux, incluidas Red Hat y SUSE que se usaron en supercomputadoras con este procesador. Recuerda que el Itanium se basa en la ISA IA-64, que no es una x86-64, como muchos piensan, sino que se trata de otra diferente, y no compatible con las x86 a no ser por este modo.
Dolphin (un emulador para GameCube/Wii) realiza una compilación JIT del código PowerPC a x86 y AArch64. Y ya conoces todos los emuladores que existen para multitud de plataformas de consolas u ordenadores del pasado. Además de software como puede ser QEMU, que también permite emular una gran cantidad de arquitecturas diferentes sobre sistemas Linux x86, por ejemplo. En cambio, no hay que confundir los JIT con los emuladores, ya que no son lo mismo. Un JIT es un traductor binario, un emulador es una implementación por software de una arquitectura, para engalar al software y que crea que está ejecutándose sobre la ISA original, lo cual también implica traducción, pero también otros aspectos.