ISA não perdoa erros

–X86 é um mal-entendido histórico, - o mestre e em 80 não perderam o entusiasmo polêmico.
"Na verdade, ela é proprietária de 95% do mercado de servidores", respondi lentamente. Eu não queria discutir um tópico cem vezes banal
- e já estou confuso com esses prefixos -, o acadêmico não cedeu. - 15 bytes por instrução, isso é impensável!
- Bem, não gelo, é claro. Mas quem é melhor?
- Sim, alguém, pelo menos ARM-a.
"Eu ainda não entendo." Adições com multiplicações devem ser?
- Devemos.
- E muda com operações lógicas?
- Sim.
- E downloads com salva também. Qual é a diferença em como eles são chamados e codificados?

Como sempre, percebi a correção do professor muito mais tarde. Quando me sentei para escrever um decodificador de comandos em uma noite sombria de inverno para me divertir de alguma forma. Consegui retratar um decodificador simples para ARM em VHDL (e eu sei mais ou menos) em alguns dias. É verdade que me arrependo, tive uma folha de dicas. :)



Para o X86, não foi possível por uma semana, duas ou um mês ... Mesmo para o conjunto básico.

A diferença aqui não está apenas no RISC (Reduced Instruction Set Computing) para ARM e no CISC (Complex Instruction Set) para X86. A diferença está antes no caminho do desenvolvimento histórico. Mais de 40 anos atrás, e tudo começou em 1978, o X86 ISA (Instruction Set Architecture) era um conjunto bastante compacto de comandos com sua própria lógica interna. Mas o tempo passou, a capacidade de barramento aumentou, os registros expandidos (incluindo o SIMD), o número de equipes em constante crescimento. Então, um cara fez uma tentativa interessante de simplesmente contar o número de instruções no X86. Se ele estava com preguiça de abrir o manuale conte-os, ou ele sabia da existência de códigos secretos "sem nome" (equipes que nem sequer têm nome) ou acreditava na onipotência da lógica. É fácil entender que a lógica acabou sendo impotente. :) A propósito, tentei encontrar um gráfico do crescimento no número de instruções do X86 por ano (ou por geração). Ainda não consegui (talvez alguém tenha?). Mas eu achei aqui uma foto assim .



Para ser sincero, não sei quantas instruções existem no X86 ISA. Mas eu me lembro bem de todos aqueles que investi no desenvolvimento, sem perceber que cada novo pedaço do ISA é rotulado como "keep forever". E havia vários milhares de "criadores" como eu na Intel. E os bits para codificar todas as suas fantasias estavam constantemente ausentes. :) Todos os novos prefixos foram adicionados ao conjunto de comandos existente: REX, VEX ... A última extensão de quatro bytes (EVEX) foi introduzida para o AVX-512. A propósito, todo o conjunto de comandos do ARM (mesmo levando em consideração o SVE ) é removido nesses mesmos 4 bytes. A ARM inicialmente seguiu o caminho contrário, construindo seu sistema de comando com os princípios básicos de simplicidade, compacidade e extensibilidade.

A diferença pode ser entendida se mudarmos do ponto de vista do programador para o ponto de vista do projetista de circuitos. E é sabido que o transistor é uma grande coisa, mas ele alterna lentamente e dissipa a energia descaradamente. E, sendo outras coisas iguais, seria melhor se houvesse menos delas. Agora, dê uma olhada no algoritmo de decodificação para obter instruções x86 (o problema que eu estava tentando resolver).



E como eles dizem, sinta a diferença nos caminhos de entrada (front end) para ARM e X86. Aqui pode-se argumentar que o front end é uma parte muito pequena do kernel, apenas cerca de 10%. Sim, mas não esqueça que toda essa lógica é multiplicada pelo número de núcleos no chip. E isso é sério.

Outra consideração é que o front end é apenas a parte responsável pela compatibilidade com versões anteriores. Você pode pá com segurança ou até mesmo jogar de volta. A propósito, a Intel tirou vantagem disso no início dos anos 2000, substituindo a arquitetura NetBurst (P4) pelo Core-M (P3). Mas o front end não pode ser muito reduzido. Embora às vezes eu realmente queira, devido ao ISA X86 existente, agora cerca de 20% é usado. O resto são remanescentes do passado.

Outra desvantagem do enorme comprimento de instruções são as falhas relativamente frequentes no cache de instruções. Grosso modo, com um tamanho igual de caches, o número de erros será maior, maior a duração da instrução. Obviamente, o tamanho dos caches pode ser aumentado. Mas, novamente, esses são transistores que poderiam não ter sido se as instruções fossem mais curtas. Pelo mesmo motivo, sou muito cauteloso com os vários tipos de arquiteturas VLIW (Very Long Instruction World). No entanto, eles também têm a desvantagem de que é muito difícil para eles desenvolver compiladores. Até agora, evitava deliberadamente o tópico dos compiladores, pois nunca os desenvolvi. Gostaria de ouvir o que as pessoas informadas dirão sobre as delícias de desenvolver compiladores para RISC, CISC e VLIW.

E, no entanto, apesar da enorme carga acumulada de legado e, talvez graças a ele, os desenvolvedores do X86 estavam certos. O princípio da compatibilidade com versões anteriores foi respeitado na arquitetura desde o início. Todo o software existente funciona no novo hardware pronto para uso. Foi isso que tornou possível construir um ecossistema tão profundo e desenvolvido em torno da arquitetura. E resta apenas tirar o chapéu na frente dos engenheiros da Intel e AMD, que, apesar do design nada perfeito do ISA, mantêm a liderança no segmento de servidores há muitos anos. No entanto, a carga herdada está ficando mais difícil.