Como Projetar uma ISA

Artigo original ↗ Discussão no Hacker News ↗

As discussões sobre como projetar arquiteturas de conjunto de instruções (ISAs) como RISC‑V, Arm e x86 giram menos em torno de qualquer recurso isolado e mais em torno de trade-offs entre simplicidade, desempenho, energia, densidade de código e custos de ecossistema no longo prazo. Os comentaristas destacam como detalhes como fusão de instruções, codificações comprimidas, movimentos condicionais, modelos de memória e extensões específicas de linguagem ou domínio podem ajudar ou prejudicar dependendo do mercado-alvo, de pequenos núcleos embarcados a servidores de alto desempenho. Muitos concluem que a base pequena e extensível do RISC‑V, junto com seu licenciamento aberto, o tornam uma provável fundação de longo prazo, mas observam que o sucesso no mundo real dependerá da implementação microarquitetural e das ferramentas de software, e não apenas da elegância da ISA.

Nuances no design de ISA e comparações com RISC‑V

  • Os participantes enfatizam que o design de ISA é multidimensional; discussões na internet frequentemente se fixam em um único aspecto (simplicidade de decodificação, uma forma de desvio condicional, etc.).
  • O RISC‑V é elogiado pela simplicidade e boa densidade de código, especialmente em 64 bits, com a fusão de instruções explicitamente prevista na especificação.
  • O “path length” medido (contagem dinâmica de instruções) em comparação com Arm é relatado como muito próximo; alguns chamam isso de “ótimo”, enquanto outros dizem que é apenas “não pior”, especialmente porque apenas rv64g foi avaliado e fusão/extensões foram ignoradas.
  • Simplicidade e desempenho semelhante ao Arm são vistos por muitos como um grande ganho.

Movimentos condicionais, modos de endereçamento e instruções comprimidas

  • Há debate sobre a falta de conditional move e de modos de endereçamento mais ricos no RISC‑V base.
    • Um lado: os defensores de recursos extras deveriam provar os benefícios com silício real e dados.
    • Outro lado: a experiência de outras ISAs sugere ganhos não triviais, embora os números sejam escassos.
  • A extensão comprimida (C):
    • Os apoiadores dizem que ela melhora o tamanho do código e o comportamento do cache de instruções; projetistas de grandes núcleos relatam que é administrável se for pensada desde o início.
    • Os críticos destacam a complexidade: desalinhamento, problemas em fronteiras de página/PMA/PMP, interação com CHERI; alguns fornecedores propuseram codificações alternativas e até mudanças de “big bang”, que outros resistem fortemente.

Compatibilidade, comportamento indefinido e especificações de facto

  • Uma história sobre um “bug” de flag no 486, do qual jogos dependiam, ilustra como o comportamento “indefinido” de uma especificação pode se tornar requisito de facto, forçando chips futuros a emulá-lo.
  • Isso se liga ao ponto mais amplo de que especificações reais muitas vezes acabam sendo “o que a implementação dominante faz”, e não apenas o documento escrito.

Instruções específicas de domínio e alvos de linguagem

  • Alguns defendem explorar automaticamente grandes espaços de design de instruções complexas adaptadas a linguagens como JavaScript/Python.
  • Contra-argumentos:
    • Não existe um único gargalo para essas linguagens, e as cargas de trabalho evoluem.
    • Recursos de ISA específicos de domínio do passado (por exemplo, execução de JVM, janelas de registradores pesadas) muitas vezes tiveram condições de vitória estreitas ou retorno decepcionante no mundo real.
    • Aceleradores especializados (mídia, ML) já são comuns e mais apropriados para muitas tarefas.

ISA vs microarquitetura, energia e desempenho

  • Uma visão: dizer que uma ISA é “mais rápida” é como dizer que a sintaxe de uma linguagem é mais rápida; a maioria dos resultados depende da implementação.
  • Outros respondem que a semântica da ISA constrange as implementações, de forma semelhante às APIs de uma linguagem, e pode impor sobrecargas persistentes (por exemplo, alocação obrigatória em heap vs alocação em stack na analogia com linguagens).

Ecossistema RISC‑V, extensibilidade e futuro

  • Alguns preveem que o RISC‑V dominará e congelará o design da ISA; outros esperam fragmentação substancial por meio de extensões personalizadas e possivelmente um futuro “RISC‑VI” se as necessidades de alto desempenho divergirem.
  • A ISA base pequena mais o mecanismo padronizado de extensões é visto tanto como uma força (reuso, abertura) quanto como uma fonte de tensão (extensões sobrepostas ou concorrentes, perfis de compatibilidade).
  • Existem mecanismos na especificação e nos sistemas operacionais para consultar extensões suportadas em tempo de execução; quão bem os ecossistemas lidarão com muitas extensões personalizadas é visto como um problema de software em aberto.

ISAs amadoras e experimentais

  • Vários descrevem ISAs e CPUs pessoais (inspiradas em x86, mas simplificadas, núcleos RISC-like de processamento de sinais com garantias de temporização, codificações compactas de 2 operandos e 16 bits semelhantes ao SuperH).
  • Isso ilustra trade-offs entre densidade de código, contagem de instruções, complexidade do compilador e simplicidade do hardware, e mostra que a experimentação de ISA continua fora dos grandes fornecedores.

Ecossistema de software e documentação

  • Um grande obstáculo para novas ISAs é a ferramenta e o ecossistema: kernels, grandes compiladores/JITs, bibliotecas de matemática/cripto/mídia.
  • O open source reduziu um pouco essa barreira, e a geração semiautomatizada de backends de compilador está surgindo.
  • Outro desafio é a falta de dados microarquiteturais e modelos de temporização compartilhados publicamente; a maioria dos resultados práticos permanece proprietária.
  • GPUs são citadas como um extremo: as ISAs de hardware são escondidas deliberadamente atrás de IRs do fornecedor, permitindo mudanças radicais sem quebrar o software, ao contrário das ISAs de CPU de longa duração.