Cómo diseñar una ISA

Artículo original ↗ Discusión en Hacker News ↗

Los debates sobre cómo diseñar arquitecturas de conjunto de instrucciones (ISA) como RISC‑V, Arm y x86 se centran menos en cualquier función aislada y más en las compensaciones entre simplicidad, rendimiento, energía, densidad de código y costes del ecosistema a largo plazo. Los comentaristas destacan cómo detalles como la fusión de instrucciones, las codificaciones comprimidas, los movimientos condicionales, los modelos de memoria y las extensiones específicas de lenguajes o dominios pueden ayudar o perjudicar según los mercados objetivo, desde núcleos embebidos diminutos hasta servidores de gama alta. Muchos concluyen que la base pequeña y extensible de RISC‑V, junto con su licencia abierta, la convierten en una probable base a largo plazo, pero señalan que el éxito en el mundo real dependerá de la implementación microarquitectónica y de las herramientas de software más que de la elegancia de la ISA por sí sola.

Matices en el diseño de ISA y comparaciones con RISC‑V

  • Los participantes enfatizan que el diseño de una ISA es multidimensional; los debates en internet a menudo se fijan en un solo aspecto (simplicidad de decodificación, una forma de salto condicional, etc.).
  • Se elogia a RISC‑V por su simplicidad y buena densidad de código, especialmente en 64 bits, con la fusión de instrucciones prevista explícitamente en la especificación.
  • La “longitud de ruta” medida (conteo dinámico de instrucciones) frente a Arm se informa como muy cercana; algunos lo llaman “genial”, otros dicen que es solo “no peor”, especialmente dado que solo se evaluó rv64g y se ignoraron la fusión y las extensiones.
  • Muchos ven la simplicidad y un rendimiento similar al de Arm como una gran victoria.

Movimientos condicionales, modos de direccionamiento e instrucciones comprimidas

  • Hay debate sobre la ausencia de movimiento condicional y de modos de direccionamiento más ricos en la RISC‑V base.
    • Una postura: quienes proponen funciones extra deberían demostrar beneficios con silicio real y datos.
    • La otra postura: la experiencia de otras ISA sugiere mejoras no triviales, aunque los números son escasos.
  • La extensión comprimida (C):
    • Sus defensores dicen que mejora el tamaño del código y el comportamiento de la caché de instrucciones; los diseñadores de núcleos grandes informan que es manejable si se diseña desde el inicio.
    • Los críticos destacan la complejidad: desalineación, problemas en límites de página/PMA/PMP, interacción con CHERI; algunos proveedores han propuesto codificaciones alternativas e incluso cambios de “big bang”, que otros rechazan firmemente.

Compatibilidad, comportamiento indefinido y especificaciones de facto

  • Una historia sobre un “error” de un flag en el 486, del que dependían los juegos, ilustra cómo el comportamiento “indefinido” de una especificación puede convertirse en un requisito de facto, obligando a chips futuros a emularlo.
  • Esto se vincula con la idea más amplia de que las especificaciones reales a menudo terminan siendo “lo que haga la implementación dominante”, no solo el documento escrito.

Instrucciones específicas de dominio y objetivos de lenguaje

  • Algunos abogan por explorar automáticamente grandes espacios de diseño de instrucciones complejas adaptadas a lenguajes como JavaScript/Python.
  • Contraargumentos:
    • No existe un único cuello de botella para esos lenguajes, y las cargas de trabajo evolucionan.
    • Las funciones ISA específicas de dominio pasadas (p. ej., ejecución JVM, ventanas de registros pesadas) a menudo tuvieron condiciones de victoria estrechas o un retorno decepcionante en el mundo real.
    • Los aceleradores especializados (medios, ML) ya son comunes y más apropiados para muchas tareas.

ISA frente a microarquitectura, energía y rendimiento

  • Una visión: decir que una ISA es “más rápida” es como decir que la sintaxis de un lenguaje es más rápida; la mayoría de los resultados dependen de la implementación.
  • Otros responden que la semántica de la ISA constriñe las implementaciones, de forma similar a las APIs de un lenguaje, y puede imponer sobrecostes persistentes (p. ej., asignación obligatoria en heap frente a asignación en stack en la analogía del lenguaje).

Ecosistema de RISC‑V, extensibilidad y futuro

  • Algunos predicen que RISC‑V dominará y congelará el diseño de ISA; otros esperan una fragmentación sustancial mediante extensiones personalizadas y posiblemente un futuro “RISC‑VI” si las necesidades de gama alta divergen.
  • La ISA base pequeña más el mecanismo estandarizado de extensiones se considera tanto una fortaleza (reutilización, apertura) como una fuente de tensión (extensiones superpuestas o competidoras, perfiles de compatibilidad).
  • La especificación y los sistemas operativos incluyen mecanismos para consultar extensiones compatibles en tiempo de ejecución; qué tan bien los ecosistemas manejan muchas extensiones personalizadas se considera un problema abierto de software.

ISA de aficionados y experimentales

  • Varios describen ISA y CPUs personales (inspiradas en x86 pero simplificadas, núcleos RISC‑like de procesamiento de señales con garantías temporales, codificaciones compactas de 2 operandos y 16 bits parecidas a SuperH).
  • Estas ilustran las compensaciones entre densidad de código, conteo de instrucciones, complejidad del compilador y simplicidad del hardware, y muestran que la experimentación con ISA continúa fuera de los grandes proveedores.

Ecosistema de software y documentación

  • Un gran obstáculo para las nuevas ISA es el tooling y el ecosistema: kernels, grandes compiladores/JITs, bibliotecas de matemáticas/cripto/medios.
  • El código abierto ha reducido algo esta barrera, y está surgiendo la generación semiautomática de backends de compilador.
  • Otro desafío es la falta de datos microarquitectónicos y modelos de temporización compartidos públicamente; la mayoría de los resultados prácticos siguen siendo propietarios.
  • Las GPUs se citan como un extremo: las ISA de hardware se ocultan deliberadamente detrás de IRs del proveedor, permitiendo cambios radicales sin romper el software, a diferencia de las ISA de CPU de larga vida.