RISC-V: Deberían haberlo sabido mejor

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

El rápido ascenso de RISC‑V como conjunto de instrucciones de CPU abierto y libre de regalías se está contrastando con una crítica aguda de sus decisiones técnicas de diseño. Los comentaristas debaten si sus extensiones opcionales fragmentadas, codificaciones de instrucciones incómodas y débil detección de características en tiempo de ejecución lo convierten en una base pobre para sistemas de alto rendimiento o de propósito general, o si esos defectos son menores frente a los beneficios de un estándar abierto y un ecosistema en crecimiento. Muchos concluyen que, aunque sea una oportunidad perdida desde una perspectiva purista de la ISA, RISC‑V es “suficientemente bueno” para desplazar núcleos propietarios en diseños embebidos, MCU y aceleradores donde dominan el costo y las licencias.

Sentimiento general

  • Muchos coinciden en que el artículo resalta con precisión defectos reales de diseño en RISC‑V (opcionalidad, codificaciones, traps, interrupciones).
  • Otros sostienen que la crítica está exagerada: RISC‑V está “bien”, es utilizable en productos reales, y todas las ISA tienen rincones feos.
  • Varios señalan que, como Linux, “suficientemente bueno + gratis” puede vencer a “técnicamente mejor + con licencia”.

Extensiones opcionales y fragmentación

  • Preocupación principal: casi todo es opcional; cada opción duplica el número de variantes.
  • La falta de una forma simple y estándar de enumerar todas las extensiones (incluidas las de proveedores) dificulta binarios portables, kernels y blobs.
  • Algunos dicen que esto no es un problema para sistemas embebidos (sabes el chip exacto), ni para aplicaciones a nivel de sistema operativo (apuntas a un perfil como RVA23).
  • Otros responden que las bibliotecas compartidas, los blobs y los productos de larga vida hacen que esto sea un problema práctico, no teórico.
  • Los perfiles (p. ej., RVA23) se ven como una mitigación parcial, pero no una solución completa.

Codificación de instrucciones, densidad de código y decodificación

  • Debate sobre codificaciones comprimidas (16/32 bits) frente a ancho fijo frente a longitud totalmente variable:
    • Críticos: RISC‑V paga costos de complejidad de longitud variable, pero solo iguala la densidad de código de AArch64 en lugar de superarla claramente; las codificaciones superpuestas entre extensiones se califican de peligrosas y confusas.
    • Defensores: los núcleos modernos ya descomponen/fusionan instrucciones complejas (x86, ARM), así que el enfoque de RISC‑V es comparable; se afirma que RV64GC/RVA23 superan a x86‑64 y compiten con AArch64 en tamaño de texto.
  • Algunos detalles microarquitectónicos (alcance de JAL, ausencia de flags, disposición de inmediatos) se califican como “errores no forzados”; otros dicen que son compensaciones razonables para diseños de alto rendimiento más simples.

Casos de uso embebidos frente a alto rendimiento

  • Muchos ven a RISC‑V como muy adecuado para roles profundamente embebidos y similares a MCU, especialmente como reemplazo legalmente “limpio” de núcleos de clase 8051 y ARM‑M con licencia.
  • Se critican la latencia de interrupción y la sobrecarga de guardado de contexto (especialmente con FP); algunos señalan que esto puede mitigarse con mejores convenciones o extensiones (p. ej., Zfinx).
  • Para núcleos de clase escritorio/servidor, las opiniones divergen:
    • Escépticos: RISC‑V no aprendió las lecciones de ARMv8/x86, lo que lo convierte en una mala opción para núcleos OoO de gama alta; los mercados de alto margen pueden simplemente pagar ARM.
    • Optimistas: con el tiempo, los núcleos abiertos y los perfiles alcanzarán rendimiento de clase M‑series/A‑series; los núcleos x86/ARM de gama alta ya ocultan las peculiaridades de la ISA detrás de micro‑ops.

Compatibilidad de software y detección de características

  • Crítica fuerte: no puedes capturar de forma fiable instrucciones indefinidas porque podrían pertenecer a otra extensión, lo que hace inseguro sondear ejecutando opcodes.
  • Algunos argumentan que el descubrimiento mediado por el sistema operativo (device tree, /proc/cpuinfo, perfiles estandarizados) es suficiente para software práctico.
  • Los desarrolladores embebidos señalan que a menudo deben dar soporte a familias de componentes; los cambios silenciosos de comportamiento entre núcleos similares (especialmente con blobs de proveedores) se consideran un riesgo serio.

Argumentos legales, de mercado y de “apertura”

  • Un tema central a favor de RISC‑V: el diseño libre de regalías, consciente de patentes, y el estatus de “estándar abierto” son convincentes, especialmente para:
    • Dispositivos embebidos sensibles al costo.
    • Empresas y países que quieren evitar la concesión de licencias de ARM/x86 o el apalancamiento geopolítico.
  • Otros advierten que las patentes sobre microarquitecturas y extensiones siguen existiendo, y que no se puede demostrar que ninguna ISA sea totalmente inmune a trolls.

RISC‑V como “marco de ISA” y direcciones futuras

  • Algunos presentan RISC‑V no como una sola ISA, sino como un generador de muchas ISAs (base + extensiones combinables).
  • Esa flexibilidad se elogia para aceleradores (IA, GPUs, IP personalizada) y núcleos de aficionados, pero se culpa de la fragmentación del ecosistema.
  • Aparecen sugerencias de:
    • Un “RISC‑VI” o una versión recodificada y más estricta que aprenda de ARMv8 y de los propios tropiezos de RISC‑V.
    • Una estandarización más agresiva en torno a unos pocos perfiles bien definidos y mecanismos de consulta, en lugar de añadir cada vez más opciones de grano fino.