RISC-V: Eles deveriam ter sabido melhor

Artigo original ↗ Discussão no Hacker News ↗

Críticos do RISC‑V argumentam que seu design altamente modular e pesado em extensões leva à fragmentação, dificulta a detecção de recursos e a criação de binários portáveis, e desperdiça lições aprendidas ao longo de décadas de evolução de x86, ARM e MIPS. Outros contrapõem que a ISA aberta e isenta de royalties do RISC‑V, o suporte crescente da cadeia de ferramentas e perfis emergentes como o RVA23 o tornam “bom o suficiente” na prática — especialmente para microcontroladores e sistemas embarcados — mesmo que ainda não seja competitivo com os melhores cores ARM ou x86 em desktops e servidores. A troca destaca uma tensão mais ampla entre o design elegante de ISA e as forças econômicas, legais e de ecossistema que, em última análise, determinam quais arquiteturas vencem.

ISA vs. Importância do Software

  • Vários comentadores argumentam que a história mostra que “o software importa; as ISAs não”: x86 sobreviveu apesar da feiura técnica porque executa software existente muito bem.
  • Outros contrapõem que os detalhes da ISA importam sim nas margens: tamanho do código, complexidade de decodificação e semântica limpa afetam custo e viabilidade, especialmente para cores pequenos ou baratos.

Opcionalidade, Fragmentação e Perfis

  • Uma crítica central é a opcionalidade extrema do RISC‑V: muitas extensões, muitos subconjuntos opcionais e codificações sobrepostas.
  • Isso torna difícil distribuir binários que sejam ao mesmo tempo portáveis e rápidos, especialmente para binários/blobs que não conhecem o core exato de antemão.
  • Alguns dizem que isso é aceitável em MCUs, onde fornecedor e alvo estão fortemente acoplados; outros apontam casos do mundo real (binary blobs, trocas de cores) em que isso quebra.
  • Perfis como o RVA23 são vistos como uma correção parcial — definindo conjuntos obrigatórios curados para certos mercados — mas alguns acham que chegaram tarde e ainda deixam casos de borda.

Detecção de Recursos e Configuração

  • Há queixas de que não existe uma forma simples e confiável para o software consultar quais extensões estão presentes; gerar trap em instruções ilegais é ambíguo porque sobreposições podem pertencer a extensões diferentes.
  • Outros respondem que baselines do SO, device trees e mecanismos futuros como mconfigptr atenuam isso, embora os detalhes ainda estejam evoluindo.

Densidade de Código e Codificação de Instruções

  • Grande subthread sobre densidade de código: RISC‑V compressed (16/32-bit) vs AArch64 32 bits fixos vs x86 de comprimento variável.
  • Alguns afirmam que RV64GC(+RVC/RVA23) supera x86‑64 e é pelo menos competitivo com AArch64; outros argumentam que o RISC‑V “paga” pelo comprimento variável, mas não o explora totalmente.
  • Debate sobre complexidade do front-end: decodificação de comprimento variável adiciona custo de hardware, mas defensores dizem que é modesto e comparável a instruções ARM com múltiplos writebacks.

Embedded vs Desktop / Alto Desempenho

  • Muitos veem o lar natural do RISC‑V em deep‑embedded e MCUs, onde custo e abertura importam mais do que desempenho de pico.
  • Céticos duvidam que o RISC‑V vá desafiar AArch64/x86 no topo, argumentando que a ISA não foi moldada para grandes cores out-of-order e que o ecossistema está atrasado.
  • Outros acham que o tempo e os designs abertos vão fechar a diferença de desempenho à medida que os orçamentos de transistores se estabilizam.

Abertura, Patentes e Motivação

  • Uma visão forte é que o principal ganho do RISC‑V é jurídico: uma ISA aberta não controlada por um único fornecedor, atraente especialmente para a China e para empresas que evitam licenciamento de ARM/x86.
  • Reconhecimento de que “sem patentes” não pode ser formalmente provado, mas o RISC‑V é intencionalmente um “MIPS legalmente distinto” para reduzir risco.

Experiências Práticas e Ferramentas

  • Entusiastas e alguns usuários comerciais relatam que as grandes vantagens do RISC‑V são: suporte principal no GCC/LLVM e a liberdade de questões jurídicas de licenciamento.
  • Pontos de dor do mundo real mencionados: prólogos de interrupção pesados em alguns MCUs RISC‑V, ausência de recursos de depuração/watchpoint no estilo x86, e a necessidade de subir do mínimo RV64I para RV64GC/RVA23 para executar distros mainstream.
  • Consenso de que, apesar dos defeitos, o RISC‑V é “bom o suficiente” e utilizável hoje, especialmente quando se controla tanto o hardware quanto o software.