Por que alguém iria querer CISC?

Em nossa palestra sobre sistemas de computadores, fomos apresentados ao processador MIPS. Foi (re) desenvolvido ao longo do prazo e, de fato, foi bastante fácil de entender. Ele usa um design RISC , ou seja, seus comandos elementares são codificados regularmente e existem apenas alguns deles para manter os fios simples.

Foi mencionado que o CISC segue uma filosofia diferente. Olhei brevemente para o conjunto de instruções x86 e fiquei chocado. Não consigo imaginar como alguém iria querer construir um processador que usa um conjunto de comandos tão complexo!

Portanto, acho que deve haver bons argumentos para que grandes porções do mercado de processadores usem arquiteturas CISC. O que eles são?

Há uma tendência histórica geral.

Antigamente, as memórias eram pequenas e, portanto, os programas eram forçosamente pequenos. Além disso, os compiladores não eram muito inteligentes e muitos programas foram escritos em assembler, portanto, foi considerado bom poder escrever um programa usando poucas instruções. Os pipelines de instruções eram simples e os processadores pegavam uma instrução de cada vez para executá-la. A maquinaria dentro do processador era bastante complexa; instruções de decodificação não foram consideradas um fardo.

Na década de 1970, os designers de CPU e compilador perceberam que ter instruções tão complexas não era tão útil, afinal. Era difícil projetar processadores nos quais essas instruções eram realmente eficientes, e era difícil projetar compiladores que realmente aproveitavam essas instruções. A área de chips e a complexidade do compilador foram mais bem gastas em atividades mais genéricas, como registros de uso geral. O artigo da Wikipedia sobre RISC explica isso com mais detalhes.

O MIPS é a arquitetura RISC final, e é por isso que é ensinada com tanta frequência.

A família x86 é um pouco diferente. Era originalmente uma arquitetura CISC destinada a sistemas com memória muito pequena (sem espaço para grandes instruções) e passou por muitas versões sucessivas. O conjunto de instruções x86 de hoje não é apenas complicado porque é CISC, mas porque é realmente um 8088 com um 80386 com um Pentium, possivelmente com um processador x86_64.

No mundo de hoje, RISC e CISC não são mais a distinção em preto e branco que poderiam ter sido uma vez. A maioria das arquiteturas de CPU evoluiu para diferentes tons de cinza.

No lado do RISC, algumas variantes modernas do MIPS adicionaram instruções de multiplicação e divisão, com uma codificação não uniforme. Os processadores ARM tornaram-se mais complexos: muitos deles têm um conjunto de instruções de 16 bits chamado Thumb , além das instruções "originais" de 32 bits, sem mencionar Jazelle para executar instruções da JVM na CPU. Os processadores ARM modernos também têm instruções SIMD para aplicativos multimídia: algumas instruções complexas pagam, afinal.

No lado CISC, todos os processadores recentes são, de certa forma, RISC dentro. Eles possuem microcódigo para definir todas essas instruções macro complexas. A grande complexidade do processador faz com que o design de cada modelo leve vários anos, mesmo com um design RISC, com o grande número de componentes, com pipelining e execução preditiva e outros enfeites.

Então, por que os processadores mais rápidos permanecem fora do CISC? Parte disso, no caso da família x86 (32 bits e 64 bits), é compatibilidade histórica. Mas isso não é tudo. No início dos anos 2000, a Intel tentou promover a arquitetura Itanium . Itanium é um caso extremo de instruções complexas (embora não seja realmente o CISC: seu design foi apelidado de EPIC ). Ele acaba com a idéia antiquada de executar instruções em sequência: todas as instruções são executadas em paralelo até a próxima barreira. Uma das razões pelas quais o Itanium não adotou é que ninguém, na Intel ou em outro lugar, poderia escrever um compilador decente para ele. Agora, um bom e antigo processador seqüencial como o x86_64, é algo que entendemos.

O conjunto de instruções x86 é um caso especial. Eu acho que o 68K da Motorola e o VAX da DEC são exemplos um pouco melhores do CISC. Nos dias de muitos códigos em linguagem assembly, as pessoas pensavam que um ISA muito regular e muito inclusivo era melhor: acredito que eles chamavam a diferença entre código assembly e a maneira como as pessoas pensavam o " gap semântico ". Teoricamente, você queria um conjunto de instruções que correspondesse à sua forma de pensar.

O outro grande driver de design do CISC parece ser a "ortogonalidade": todas as instruções funcionariam com todos os modos de endereçamento (registrador, endereço absoluto, deslocamento relativo, etc etc). Você pode ver o truque da ortogonalidade aparecer no design da API no Distributed Computing Environment (DCE) e no CORBA. Essa ideia não se limita ao design de cenários de instruções.

Um motivo para o CISC era ter uma codificação densa para obter instruções (a memória era cara) A idéia do RISC era acelerar a CPU, buscando as mesmas instruções de tamanho o tempo todo (sem etapas complexas e lentas de "descobrir o tamanho da instrução"), fazê-las fazer coisas simples (por isso é rápido descobrir o que fazer) . A memória era barata. Essa área de circuitos liberados na CPU para outras coisas (mais registros, mais unidades de processamento, para que várias instruções possam ser executadas em paralelo, se forem independentes). Como a CPU era muito mais lenta que a RAM, isso valeu a pena. Mas as CPUs ficaram mais rápidas (e fizeram mais em paralelo e ...) enquanto a RAM não ficou mais rápida (pelo menos não na mesma taxa que o consumo de dados da CPU devido ao aumento do paralelismo). Conheça a memória cache, rápida como a CPU, mas pequena. Portanto, agora a memória está em alta novamente, não por razões de custo, mas por velocidade. Tempo de renascimento da CISC. Enquanto isso, as CPUs ficaram mais complexas, a tal ponto que o microprocessador de hoje faz muito do que um compilador RISC fez: Divida as operações em partes elementares, reordene as instruções internas do RISCy para que possam ser executadas simultaneamente sempre que possível. O RISC foi falado como "Aliviar Coisas Importantes ao Compilador" por um motivo ...

A vantagem real do CISC é a pressão reduzida de memória e cache, o que, por si só, o torna melhor para aplicações exigentes de alto desempenho, já que um grande gargalo nesses sistemas é a largura de banda da memória. Dada a memória cache do mesmo tamanho, os processadores CISC podem descrever mais informações que o RISC. Além disso, como as instruções CISC envolvem várias micro-operações, podem ser possíveis aprimoramentos arquiteturais que podem fornecer o caminho de execução mais rápido para essa instrução que a escrita de instruções individuais poderia fornecer. Em resumo, os processadores CISC são mais eficientes na utilização da largura de banda da memória, o que geralmente se traduz em ganhos de desempenho para aplicativos com uso intenso de memória.

Por exemplo, para executar R1 = R2 + R3 + R4 + R5 + R6e enviar o resultado para a pilha, digamos que o código RISC seja gravado como,

ADD  R1, R2, R3 (4-byte)
ADD  R1, R4, R5 (4-byte)
ADD  R1, R6, R0 (4-byte, R0=0)
PUSH R1         (4-byte)

e, como tal, requer 16 bytes de espaço.

Chegando ao CISC, devido à possibilidade de diferentes estilos de codificação, as mesmas informações podem ser representadas da seguinte forma ...

ADD R1, R2, R3 (4-byte)
ADD R1, R4, R5 (4-byte)
ADD R1, R6     (2-byte)
PUSH R1        (1-byte) 

que leva apenas 12 bytes de memória. Assim, a utilização da memória é aprimorada, permitindo que o processador veja mais instruções e, assim, reduza os ciclos inativos.

Um aspecto importante que ninguém mencionou é que quase todas as CPUs CISC são arquiteturas microcodificadas. Um microsequenciador e uma loja de controle consomem muito menos espaço do que um controlador com fio, e o conjunto de instruções pode ser modificado sem modificar o hardware.

Microprocessadores eram dispositivos inovadores quando entrei em campo. Uma prática muito comum nos anos setenta e início dos anos oitenta era montar uma CPU usando ALUs de fatia de bits, uma unidade de controle baseada em micro sequenciadores e um armazenamento de controle no qual o conjunto de instruções microcodificado era carregado ou soprado. Esses computadores foram baseados na lógica transistor-transistor 7400 (TTL) da série 7400. A ALU de 4 bits 78181 foi usada para construir muitos processadores, incluindo os computadores DEC PDP-11 e VAX 11, os Data General Nova, Xerox Alto e Wang.

Você terá dificuldade em encontrar qualquer computador desktop que não esteja usando um processador compatível com x86. Esse conjunto de instruções venceu o MIPS, venceu o Sparc, venceu o Alpha, venceu o Titanic (talvez eu tenha escrito esse nome errado). O MIPS, por outro lado, mal existe hoje. Portanto, não importa o que você pense hoje, as pessoas muito inteligentes pensaram que o conjunto de instruções x86 era realmente uma boa ideia e eles ganharam muito dinheiro com isso.

Os computadores começaram como RISC porque um conjunto de instruções complexo estava além das habilidades dos implementadores. Se você deseja ver um conjunto de instruções RISC, consulte o CDC 6400-6600 e o CDC Cyber ​​170-175. Isso é o RISC adequado. Há cerca de dez anos, perguntei a alguns projetistas de chips quanto espaço seria necessário (no canto de um chip GPU avançado e razoável). Eles me falaram sobre 1mm2 - incluindo a RAM da máquina, que ocuparia 99% desse espaço.

Quando as pessoas podiam construir máquinas CISC, elas estavam realmente em vantagem. Lembre-se de que o x86 foi lançado muito antes do MIPS, 1978 x 1985. Naquela época, você precisava de ciclos do processador para ler as instruções, decodificá-las e executá-las. O MIPS em 1978 teria levado quatro ciclos por instrução e por operação. Se você seguir uma instrução x86 como "adicionar registrador à memória", isso levaria talvez 7 ciclos para a instrução, mas a execução de 3 operações. Essa foi uma grande vantagem. E quanto mais instruções diferentes você tiver, e quanto mais poderosa for cada instrução, maior será a vantagem.

E quando o conjunto de instruções x86 de 64 bits com seus códigos de prefixo de pesadelo foi desenvolvido, a complexidade do conjunto de instruções não importava mais. Atualmente, o CISC é apenas traduzido para o RISC, e todo o negócio de tradução é talvez um por cento do chip.

Essa questão tem muito a ver com tendências muito recentes na computação que favorecem uma mudança maciça para a computação móvel e tablet, favorecendo o RISC cpus, e flagraram a Intel (provavelmente o maior fornecedor CISC do mundo) em desvantagem na chamada "inflexão" ponto " exatamente como o tipo que Grove chamou a atenção e alertou. A história resumida é que o CISC parece estar começando a derreter sob o massivo ataque de mudança de paradigma / mudança de jogo da computação móvel por causa de seu consumo de energia aparentemente intrinsecamente alto.

Presumivelmente, o CISC sempre estará presente no desktop, mas o celular é amplamente considerado como o novo futuro da computação. Muitos países em desenvolvimento (com grandes populações potenciais de usuários de computador) realmente ignoram a fase de desktop. Veja, por exemplo, Ascensão e queda da computação em desktop

Um excelente estudo de caso desta questão é ler sobre Mike Bell, que está trabalhando para a Intel em uma nova posição, tentando posicionar a Intel melhor no mercado móvel através da CPU Atom através de um projeto / iniciativa semelhante a "skunkworks", com executivos muito fortes Apoio, suporte. O mercado móvel está altamente acoplado à arquitetura RISC e, principalmente, aos processadores ARM, devido em grande parte à sua alta eficiência energética (consumo de energia), um novo critério-chave para a computação mencionado na pergunta e nenhuma outra resposta. Aqui estão dois artigos recentes nesse sentido que revelam grande parte do pensamento corporativo interno (e conseqüente disputa!) Sobre o assunto:

• Intel descarta 'imposto x86', não vê futuro para a ARM ou qualquer de seus concorrentes

• Um império contra-ataca: Intel entra no mercado móvel

Um fator não mencionado em outras respostas é econômico. Também é sobre a Intel. A arquitetura CISC é amplamente representada pelas famílias x86 e x64. Todos eles descendem dos humildes 8088 usados ​​no IBM PC original. O domínio inicial do mercado dessa série de computadores significava que a Intel tinha um sólido fluxo de receita para P&D. Juntamente com o fato de a Intel ter conseguido refrear a concorrência renegando / cancelando seus acordos de segunda fonte, os preços da CPU poderiam subir a níveis extremos, garantindo margens de lucro brutas muito ricas.

Assim, enquanto outros fabricantes de CPU lutavam para acompanhar o ritmo, a Intel conseguiu despejar bilhões de dólares no desenvolvimento de produtos mais novos e mais rápidos. A competição RISC não podia gastar quase tanto dinheiro. Muitos processadores RISC saíram do mercado. Alguns foram:

DEC Alpha, Fairchild Clipper, AMD 29000, SPARC, MIPS, POWER (para uso em PC), Hitachi SuperH ...

Lembro-me de especialistas da época anunciando que a guerra RISC vs CISC havia terminado e a CISC vencera. Não tinha. Apenas superou todos os outros.

Essa dinâmica pode mudar? Já é. Nenhuma vantagem econômica é absoluta.

O único calcanhar de Aquiles do x86 é o apetite voraz por poder. Isso permitiu que um concorrente menor e mais ágil (ARM) prosperasse em mercados (como telefones / tablets / etc) onde a economia de energia importava.

Um ótimo vídeo sobre isso de um membro da equipe ARM é o ARM Processor - Sowing the Seeds of Success - Computerphile por volta das 8:30

O segundo problema do x86 é o sucesso da estratégia da Intel. Eles conseguiram eliminar quase toda a concorrência. Eles desaceleraram. Há anos, os novos processadores Intel oferecem apenas melhorias muito modestas. Pior ainda, margens super-ricas são uma dieta difícil de desistir de qualquer empresa.

Hoje, o Systems on Chip (SOC) e os chips x64 concorrentes da AMD estão novamente tornando o mercado de CPUs um lugar interessante. (NA MINHA HUMILDE OPINIÃO)

Há muitas razões pelas quais alguém escolheria implementar um CISC. O motivo mais importante é a compatibilidade binária com um conjunto de instruções CISC existente. Embora a tecnologia de tradução binária de software tenha melhorado, a compatibilidade baseada em hardware tem algumas vantagens técnicas (bem como a desvantagem de menos cache de tradução) e a vantagem menos técnica de parecer mais confiável.

A densidade do código é talvez o segundo motivo mais significativo para a escolha do CISC. O Renesas RX foi projetado como um CISC especificamente para a densidade de código, pois visa microcontroladores onde o tamanho da memória de código é um fator de custo significativo. Instruções de comprimento variável, instruções complexas (principalmente modos de endereçamento), operandos implícitos e registro mais baixo contam toda a densidade do código de benefício.

Uma razão histórica (e na minha opinião equivocada) para escolher o CISC foi fechar a lacuna semântica entre os programadores que usam uma linguagem de nível superior e o processador. Como instruções complexas geralmente podem ser substituídas por uma sequência de instruções mais simples, a complexidade de um compilador de linguagem de nível superior para um RISC não precisa ser muito mais complexa do que para um CISC de correspondência de idioma. O RISC evita "conflito semântico" (onde uma instrução do processador funciona mais ou menos do que uma declaração de idioma correspondente) e facilita a redução de força e otimizações de programação. (Consulte "Quais são as vantagens e desvantagens no esforço de desenvolvimento do compilador relacionadas ao CISC vs. RISC?" Para obter mais detalhes.)

Pode haver um custo fixo significativo associado à execução de uma instrução. Isso incentiva o uso de instruções relativamente complexas para espalhar essa sobrecarga por trabalhos mais reais; reduzir a contagem dinâmica de instruções pode melhorar o desempenho. Quando o custo da lógica e da RAM era muito maior que o custo da ROM, o incentivo para instruções complexas era significativo, uma vez que uma instrução era decodificada ao procurar o microcódigo.

Um motivo para usar o CISC que talvez seja contradito por evidências históricas é que o microcódigo pode ser otimizado para cada microarquitetura, enquanto as bibliotecas padrão podem demorar para explorar os recursos de uma nova implementação. O nível de otimização das implementações de software de memcopy versus o do microcódigo para REP MOVSB ​​implica que as bibliotecas podem receber mais atenção do que o microcódigo. Parte disso pode vir do fornecedor do processador que visa uma base de usuários mais ampla, pelo que a justificativa do esforço pode ser mais difícil em comparação com o software de código aberto ou interno, onde os interesses localizados de desenvolvedores ou usuários podem influenciar o esforço de implementação.

Ser capaz de enviar uma biblioteca padrão otimizada com o processador tem atrações significativas. O armazenamento e a execução de uma biblioteca padrão de plataforma podem ser significativamente otimizados pelo código de código de hardware e software. A distinção entre uma instrução complexa e uma chamada da camada de abstração da plataforma pode ser sutil (ou inexistente). Um design RISC poderia usar as mesmas técnicas de implementação para lidar com chamadas PAL que um CISC faz para instruções complexas, incluindo o uso de operações não fornecidas no conjunto de instruções geral com hardware especializado, armazenamento em cache e decodificação inteligentes e especificação de operandos de registro (embora um CISC freqüentemente usam registros dedicados semelhantes a uma ABI por função). O modelo mental associado ao CISC pode incentivar essas otimizações. Além disso, os usuários podem ficar menos ofendidos com a inclusão forçada de um "

A decodificação de instruções relativamente complexas pode ter menos sobrecarga (e possivelmente ser mais confiável na intenção de discernir) do que a técnica RISC comparável de reconhecimento de idiomas, onde uma sequência de instruções é reconhecida como uma unidade semântica. Essa diferença de sobrecarga seria mais perceptível em uma implementação menor, mas a sobrecarga de usar essas informações reduz o significado da economia de decodificação.

Informações contextuais adicionais podem facilitar a otimização do hardware. Por exemplo, ao incrementar um valor na memória, o hardware pode reconhecer que o endereço de memória é usado duas vezes (para carregar e armazenar), oferecendo uma oportunidade para armazenamento em cache de memorização e conversão. Instruções complexas podem fornecer essas informações explicitamente. Em uma instrução complexa, os valores intermediários têm uma vida útil explícita (a da instrução); com um registro tradicional RISC, os valores devem ser substituídos explicitamente para indicar o fim da vida útil. (Nota: Um RISC pode especificar um registro que é sempre zerado após cada uso, fornecendo um meio para especificar um valor temporário de uso único. Essas instruções seriam moderadamente mais complexas.)

Se os detalhes da implementação não estiverem ocultos atrás de uma camada de abstração, torna-se mais difícil usar microarquiteturas diferentes para otimizar diferentes tradeoffs. A exposição de detalhes da microarquitetura como garantias arquitetônicas trava a microarquitetura na garantia de compatibilidade. Embora o software PAL possa ser otimizado da mesma forma que as instruções complexas, isso exige um código de hardware e software. A separação e a diversidade organizacional dificultam o design de código.

Instruções complexas podem fornecer acesso protegido ao estado privilegiado. Por exemplo, instruções complexas geralmente são atômicas em relação a interrupções. Embora um conjunto de instruções RISC possa fornecer um mecanismo no nível do usuário para suspender temporariamente as interrupções, possivelmente até algo como carga vinculada, para que o software tente explicitamente a operação se interrompido, desde que isso não seja típico para RISCs.

Da mesma forma, uma instrução complexa pode fornecer acesso controlado e / ou uso de informações privilegiadas. Como a operação executada tem semântica controlada, a violação real de privilégios pode ser evitada. As alternativas orientadas para RISC incluem código PAL (que normalmente possui sobrecarga significativa) e acesso mascarado a registros de configuração (ou cópias de sombra de registros) que possuem algum estado privilegiado. Fornecer uma solução geral (RISC) é mais difícil do que fornecer uma solução para um ou alguns casos especiais (CISC), mas é mais poderoso e menos vulnerável ao acúmulo de casos especiais. Se alguém acredita que os casos especiais importantes são poucos, o CISC pode ser mais atraente.

Instruções complexas também podem ocultar o estado do software. Uma vantagem proeminente disso seria para salvar e restaurar o contexto. Com instruções para salvar e restaurar o estado, a arquitetura precisa apenas comunicar o tamanho do contexto ao sistema operacional e não os mecanismos específicos para transferir o estado para a memória. Isso permite que aplicativos executados em um sistema operacional herdado usem extensões ISA que adicionam estado. (Mais uma vez, o software PAL poderia fornecer a mesma funcionalidade.)

Grande parte da complexidade do x86 vem da compatibilidade em várias extensões. Com instruções complexas e menos ortogonais (úteis para a densidade do código), a remoção de algum trabalho que acabou sendo desnecessário, evitando cadeias de dependência desnecessárias (por exemplo, apenas um bit de transporte, apenas um registro de quantidade de deslocamento dinâmico), adicionando algum trabalho que para ser comumente usado e que pode ser otimizado dentro das instruções complexas - qualquer uma delas exigiria adicionar uma nova instrução e tornar o ISA menos esteticamente agradável.

Em muitos casos, um RISC não encontraria esses problemas porque as instruções são altamente ortogonais e primitivas. Em alguns casos, um RISC pode precisar adicionar novas primitivas, mas isso normalmente seria aplicável a mais de um uso.

Além disso, uma vez que a infraestrutura está instalada para oferecer suporte a instruções complexas, as barreiras são reduzidas para instruções complexas adicionais. Ou seja, muito do custo de instruções complexas não é recorrente. Os ISAs fortemente RISC sofrem um impedimento complementar à introdução dos recursos do CISCy.

A frequência de extensão do x86 também pode ser parcialmente atribuída à sua popularidade na computação de uso geral e no modelo de processador comercial (isso também aumenta a importância da compatibilidade binária). Os ISA RISC têm sido frequentemente vinculados aos fornecedores de sistemas, o que incentiva um foco mais restrito nos aplicativos e a falta de concorrência pelas implementações de um ISA RISC específico desencoraja um pouco o uso de extensões de conjunto de instruções para marketing. A popularidade também reduz o custo de desenvolvimento de novas extensões (despesas não recorrentes são menos importantes em volumes mais altos).

A filosofia de compatibilidade do x86 provavelmente também inclina a extensão dos mecanismos existentes, em vez de fornecer uma pausa mais limpa, o que significa que os novos recursos são mais influenciados pelos recursos existentes. Maior frequência de extensão também incentiva mudanças mais incrementais, o que incentiva mecanismos de reutilização, tendendo a reduzir a ortogonalidade.

Comparando uma apresentação acadêmica do MIPS clássico (que é um subconjunto de versões modernas do MIPS e excluindo várias extensões ISA opcionais) com o x86 moderno (que rastreia a compatibilidade binária até o 8086 de 16 bits e a quase compatibilidade no nível de montagem ainda mais atrás) com toda a sua bagagem histórica, não apresenta o melhor argumento para o CISC nem um argumento realista para o RISC.

Antes de haver configurações reduzidas do conjunto de instruções, havia configurações do conjunto de instruções. Eles têm suas aplicações. particularmente em transferências de blocos de memória muito grandes com chipsets de alta capacidade, que precisariam apenas de 4 a 16 bytes para transferir uma página de vídeo inteira, em vez de um loop longo para sempre. isso está mudando e o RISC está se tornando o status quo, à medida que os chipsets estão se tornando mais sofisticados, como as incríveis GPUs encontradas nas placas de vídeo topo de linha.

A CPU CISC tem mais vantagens que a RISC. Porque o CISC usa menos registros de hardware e portas XNOR / XOR do que o RISC muitas vezes !!!! Imagine que os bytes de instrução no CISC serão executados em sequência, existe apenas uma porta lógica e o registro é usado. Se 1 bilhão de transistores puder produzir cerca de 300 milhões de portas lógicas, você poderá processar 300 milhões de operadores ou processos (SE, iguais, matemáticos, variáveis, endereçamento ... etc) e mais programas poderão ser executados no CISC. Mas no RISC, são necessárias dezenas de portas lógicas para a execução de um programa em projeto em pipeline. Então, 300 milhões x 50 vezes (50 instruções) + 15000000000 contadores de bits !!! no chamado RISC. O CISC usa mais hardware para reduzir o algothrim do software, que desacelera o processador.