RISC-V: Eles Deveriam Ter Sabido Melhor

Artigo original ↗ Discussão no Hacker News ↗

A rápida ascensão do RISC‑V como um conjunto de instruções de CPU aberto e livre de royalties está sendo contraposta a críticas contundentes sobre suas escolhas técnicas de projeto. Os comentaristas debatem se suas extensões opcionais fragmentadas, codificações de instrução incômodas e detecção fraca de recursos em tempo de execução o tornam uma base ruim para sistemas de alto desempenho ou de uso geral, ou se essas falhas são menores em comparação com os benefícios de um padrão aberto e um ecossistema crescente. Muitos concluem que, mesmo sendo uma oportunidade perdida do ponto de vista de purismo de ISA, o RISC‑V é “bom o suficiente” para substituir núcleos proprietários em projetos embarcados, MCU e aceleradores, onde custo e licenciamento predominam.

Sentimento geral

  • Muitos concordam que o artigo destaca com precisão problemas reais de projeto no RISC‑V (opcionalidade, codificações, traps, interrupções).
  • Outros argumentam que a crítica é exagerada: o RISC‑V é “bom o suficiente”, utilizável em produtos reais, e todas as ISAs têm cantos feios.
  • Vários observam que, como no Linux, “bom o bastante + grátis” pode superar “tecnicamente melhor + licenciado”.

Extensões opcionais e fragmentação

  • Principal preocupação: quase tudo é opcional; cada opção dobra o número de variantes.
  • A falta de uma maneira simples e padronizada de enumerar todas as extensões (incluindo as de fornecedor) dificulta binários portáveis, kernels e blobs.
  • Alguns dizem que isso não é um problema para embarcados (você conhece o chip exato) ou para apps em nível de SO (você mira um profile como RVA23).
  • Outros respondem que bibliotecas compartilhadas, blobs e produtos de longa duração tornam isso um problema prático, não teórico.
  • Profiles (por exemplo, RVA23) são vistos como mitigação parcial, mas não como solução completa.

Codificação de instruções, densidade de código e decodificação

  • Debate entre codificações comprimidas (16/32 bits), de largura fixa e totalmente variáveis:
    • Críticos: o RISC‑V paga os custos de complexidade da largura variável, mas só iguala a densidade de código do AArch64 em vez de superá-la claramente; codificações sobrepostas entre extensões são chamadas de perigosas e confusas.
    • Defensores: núcleos modernos já quebram/fundem instruções complexas (x86, ARM), então a abordagem do RISC‑V é comparável; afirma-se que RV64GC/RVA23 superam x86‑64 e são competitivos com AArch64 em tamanho de texto.
  • Alguns detalhes microarquiteturais (alcance do JAL, ausência de flags, layouts de imediatos) são chamados de “erros não forçados”; outros dizem que são trade-offs razoáveis para projetos de alto desempenho mais simples.

Casos de uso embarcados vs. alto desempenho

  • Muitos veem o RISC‑V como bem adequado a funções fortemente embarcadas e semelhantes a MCU, especialmente como substituto legalmente “limpo” para núcleos da classe 8051 e ARM‑M licenciados.
  • Latência de interrupção e sobrecarga de salvamento de contexto (especialmente com FP) são criticadas; alguns observam que isso pode ser mitigado por convenções melhores ou extensões (por exemplo, Zfinx).
  • Para núcleos de classe desktop/servidor, as opiniões divergem:
    • Céticos: o RISC‑V deixou passar lições do ARMv8/x86, tornando-o uma opção ruim para núcleos OoO de ponta; mercados de alta margem podem simplesmente pagar ARM.
    • Otimistas: com tempo, núcleos abertos e profiles chegarão ao desempenho da classe M-series/A-series; núcleos x86/ARM de ponta já escondem peculiaridades da ISA atrás de micro-ops.

Compatibilidade de software e detecção de recursos

  • Crítica forte de que não é possível fazer trap de instruções indefinidas de forma confiável porque elas podem pertencer a alguma outra extensão, tornando inseguro detectar recursos executando opcodes.
  • Alguns argumentam que a descoberta mediada pelo SO (device tree, /proc/cpuinfo, profiles padronizados) é suficiente para software prático.
  • Desenvolvedores de embarcados observam que muitas vezes precisam suportar famílias de chips; mudanças silenciosas de comportamento entre núcleos semelhantes (especialmente com blobs de fornecedor) são vistas como um risco sério.

Argumentos legais, de mercado e de “abertura”

  • Um tema central pró-RISC‑V: design livre de royalties, consciente de patentes, e status de “padrão aberto” são atraentes, especialmente para:
    • Dispositivos embarcados sensíveis a custo.
    • Empresas e países que querem evitar licenciamento da ARM/x86 ou alavancagem geopolítica.
  • Outros alertam que patentes sobre microarquiteturas e extensões ainda existem, e nenhuma ISA pode ser provada como totalmente imune a trolls.

RISC‑V como “framework de ISA” e direções futuras

  • Alguns tratam o RISC‑V não como uma única ISA, mas como um gerador de muitas ISAs (base + extensões combináveis).
  • Essa flexibilidade é elogiada para aceleradores (IA, GPUs, IP customizado) e núcleos hobby, mas culpada pela fragmentação do ecossistema.
  • Aparecem sugestões para:
    • Um “RISC‑VI” ou um perfil reencodificado e mais estrito que aprenda com o ARMv8 e com os próprios erros do RISC‑V.
    • Mais padronização agressiva em torno de alguns profiles bem definidos e mecanismos de consulta, em vez de adicionar cada vez mais opções granulares.