Nasi

1- Como já foi referido, muitas das implementações da arquitetura CISC eram tão complexas que eram distribuídas por vários chips. Esta situação não era, por razões óbvias, ideal. Era necessária uma solução num único chip, uma solução que fizesse melhor uso dos escassos recursos disponibilizado (transístores). No entanto, para que todo um processador coubesse num só chip, algumas das suas funcionalidades teriam que ser deixadas de fora. Nesse intuito, realizaram-se estudos destinados a descobrir que tipos de situações ocorrem mais frequentemente na execução de aplicações. A ideia era descobrir em que tipo de tarefas o processador passava mais tempo e aperfeiçoar essas mesmas tarefas. Se tivessem que ser feitos compromissos, estes deviam ser feitos em favor da velocidade de execução das tarefas nas quais o processador passa mais tempo a trabalhar, ainda que isso pudesse atrasar outras tarefas não tão frequentes.

Esta abordagem quantitativa, de fazer mais rápidas as tarefas mais comuns, provocou a inversão da filosofia iniciada pelos CISC e a complexidade teve que ser retirada do hardware e ser passada para o software. A memória estava a ficar mais barata e os compiladores eram cada vez mais eficientes por isso muitas das razões que conduziram os projetistas a “complicar” o conjunto de instruções deixaram de existir. Os investigadores diziam que o suporte para as linguagens de alto nível poderia ser mais eficiente se fosse implementada em software, gastar recursos (transístores) preciosos para suportar as linguagens de alto nível em hardware era um desperdício. Esses recursos poderiam ser utilizados noutras tecnologias para melhorar o desempenho. Quando os investigadores tiveram que decidir quais as funcionalidades que teriam que ser retiradas, o suporte para o microcódigo foi o primeiro a sair, e com ele saíram também um grupo de instruções complexas que, alegadamente, tornava o trabalho dos compiladores e dos programadores mais fácil. A ideia era que quase ninguém utilizava aquelas instruções tão complexas. Os programadores ao escreverem compiladores, com certeza que não as utilizavam, pois estas eram difíceis de programar. Ao compilar o código, os compiladores preteriam este tipo de instruções em favor da geração de um conjunto de instruções mais simples que realizassem a mesma tarefa.

O que os investigadores concluíram dos estudos realizados foi que um pequeno conjunto de instruções estava a fazer a maioria do trabalho. Aquelas instruções que raramente eram usadas poderiam ser eliminadas sem que houvesse perda de qualquer funcionalidade. Esta ideia da redução do conjunto de instruções, deixando de for a todas as instruções que não fossem absolutamente necessárias, substituindo as instruções mais complexas por conjuntos de instruções mais simples, foi o que esteve na origem do termo Reduced Instruction Set Computer. Ao incluir apenas um pequeno e criteriosamente escolhido grupo de instruções numa máquina, poder-se-ia deixar de fora o suporte do microcódigo e passar a usar a execução direta. Não só o número de instruções foi reduzido, mas também o tamanho das mesmas. Foi decidido que todas as instruções RISC deveriam, sempre que possível, demorar apenas um ciclo de relógio a terminar a sua execução. A razão por trás desta decisão foi baseada em algumas observações feitas pelos investigadores. Em primeiro lugar, apercebeu-se que tudo o que poderia ser feito usando as instruções de microcódigo, também poderia ser feito com pequenas e rápidas instruções de assembly. A memória que estava a ser usada para armazenar o microcódigo poderia simplesmente ser usada para armazenar o assembler, assim a necessidade de microcódigo seria pura e simplesmente eliminada. É por esta razão que muitas das instruções de uma máquina RISC correspondem à micro instruções numa máquina CISC.

• Diferenças de velocidade entre memória e processador – no final da década de 1970, a IBM verificou que essa diferença era um problema em seus sistemas, algumas operações eram realizadas por programas, acarretando muitos acessos a uma memória lenta. A solução encontrada foi criar novas instruções de máquina para executar tais operações, podendo-se acreditar que esse foi o início do aumento da quantidade de instruções no CISC.

• Emprego de microcódigo – o surgimento e a real vantagem de custo/beneficio do emprego de microcódigo sobre programação diretamente no hardware induziram os projetistas a criar mais e mais instruções, devido a facilidade e a flexibilidade decorrentes. Desenvolvimento acelerado de linguagens de alto nível – na década de 1980, havia um crescimento acelerado do emprego de linguagens de alto nível, o que conduzia os projetistas de processadores a incluir cada vez mais instruções de máquinas em seus produtos, como o propósito de manter um suporte adequado na compilação.

• Densidade de código a ser executado – as arquiteturas CISC procuram obter um código compacto após a compilação, de modo a não consumir memória em excesso. Isso era necessário em uma época em que as memórias eram caras e de reduzindo tamanho. Construindo conjuntos de instruções, cada uma delas mais próxima do significado do comando de alto nível, poder-se-ia obter códigos executáveis mais densos, mais compactos. Alega Patterson que isto acarretaria também mais bits nas instruções (códigos de operações com mais bits devido à quantidade delas, bem como mais modos de endereçamento), o que contrabalançaria aquela pretensa vantagem.

• Necessidade de compatibilidade com processadores anteriores – uma das metas sempre seguida pela Intel e outros fabricantes foi a de conservar a compatibilidade entre as versões de seus processadores. Assim o processador 486 veio com apenas algumas instruções novas e todo o código do 386 junto, códigos executáveis para o 386 rodavam também no 486, e os usuários poderiam trocar de computador sem nenhum custo adicional de compilação, etc. O mesmo aconteceu com o Pentium I, II, III e 4. Mesmo isso, embora seja um notório requisito importante de marketing, acarreta uma limitação especificação de novas arquiteturas. Dessa forma, as arquiteturas novas só crescem em quantidade de instruções, visto que o fabricante nunca retira as instruções antigas devido ao problema de compatibilidade.

2- Projetos RISC levaram a certo número de plataformas e arquiteturas bem sucedidas, algumas das maiores sendo:

• ARM - A arquitetura ARM domina o mercado de baixa potência e sistemas de baixo custo embutido (normalmente 100-500 MHz em 2008). ARM Ltda., que licencia propriedade intelectual, em vez de chips de fabricação, relatou que 10 bilhões de chips licenciados tinham sido enviados no início de 2008.