RISC X CISC

ARQUITETURA RISC X CISC

RESUMO

É comum em abordagens comparativas as duas arquitetura coloca - lá lado a lado e diferenciar por tópicos. O Fato é que as duas trabalham de modo extremamente diferente.

Lembrando sempre que as duas arquiteturas foram estrategicamente projetadas para de acordo com as condições tecnológicas da época.

Na década de 70 as memórias tinham um custo elevado, isso levava a uma grande exploração dos códigos que eram cada vez mais complexos, os códigos deveriam ser eficientes e ao mesmo curtos devido ao alto custo da memória que os armazenava.

Esses mesmos códigos, eram escritos em linguagem de alto nível, que mais tarde seria compilada, o processo de compilação era demorado, e nem sempre perfeito. Dessa forma um resultado satisfatório só seria alcançado se fosse diretamente feito em linguagem de baixo nível.

Sendo os compiladores demorados e memória lenta, o hardware se tornava mais barato e o software mais caro. A solução adotada para nivelar esse padrão

Palavras-Chavea: Arquitetura CISC e RISC; RSC; CISC; arquitetura da compucação

SUMMARY

It is common in the two comparative approaches architecture places - there side by side and differentiate topics. The fact is that the two work so extremely different.

Remembering that the two architectures have been strategically designed according to the technological conditions of the time.

In the 70's memories had a high cost, this led to greater exploitation of the codes that were increasingly complex, the codes should be efficient and at the same short due to the high cost of memory that stored them.

These same codes were written in high level language, which would later be compiled, the compilation process was time consuming, and not always perfect. Thus a satisfactory result would be achieved only if done directly in low-level language.

Being compilers consuming and slow memory, the hardware became cheaper and more expensive software. The solution adopted to level this pattern

Arquitetura CISC

No inicio dos anos 70, os compiladores eram muito pobres e pouco robustos, e a memória era lenta e muito cara causando assim sérias limitações no tamanho do código, levou a que uma certa corrente previsse uma crise no software. O hardware era cada vez mais barato e o software cada vez mais caro. Um grande número de projetistas defendia que a única maneira de contornar os grandes problemas que se avizinhavam era mudar a complexidade do (cada vez mais caro) software e transporta – lá para o (cada vez mais barato) hardware. Se houvesse uma função mais comum, que o programador tivesse de escrever vezes sem conta num programa, porque não implementar essa função em hardware? Afinal de contas o hardware era barato e o tempo do programador não. Esta ideia de mover o fardo da complexidade do software para o hardware foi a ideia impulsionadora por trás da filosofia CISC, e quase tudo o que um verdadeiro CISC faz tem esse objetivo. Alguns projetistas sugeriram que uma maneira de tornar o trabalho dos programadores mais fácil seria fazer com que o código assembly se parecesse mais com o código das linguagens de alto nível. Este tipo de arquitetura era CISC levado ao extremo. A sua motivação primária era reduzir o custo global do sistema fazendo computadores para os quais fosse mais fácil de programar. Ao simplificar o trabalho dos programadores, pensava – se que os custos seriam mantidos num nível razoável. Aqui estão algumas das principais razões para se promover este tipo de arquitetura:

Reduzir as dificuldades de escrita de compiladores;

Reduzir o custo global do sistema;

Reduzir os custos de desenvolvimento de software;

Reduzir drasticamente o software do sistema;

Reduzir a diferença semântica entre as linguagens de programação e máquina;

Fazer com que os programas escritos em linguagens de alto nível corressem mais eficientemente;

Melhorar a compactação do código;

Facilitar a detecção e correção de erros.

Se uma instrução complexa escrita numa linguagem de alto nível fosse traduzida em, exatamente, uma instrução assembly, então:

Os compiladores seriam mais fáceis de escrever.

Isto pouparia tempo e esforço para os programadores, reduzindo, assim, os custos de desenvolvimento de software;

O código seria mais compacto, o que permitiria poupar em memória, reduzindo o custo global do hardware do sistema;

Seria mais fácil fazer a detecção e correção de erros o que, de novo, permitiria baixar os custos de desenvolvimento de software e manutenção. Até este momento, centramos a atenção nas vantagens econômicas da arquitetura CISC, ignorando a questão do desempenho. A abordagem utilizada neste tipo de arquitetura para melhorar o desempenho das máquinas CISC foi, conforme já foi referido, transferir a complexidade do software para o hardware. Para melhor se compreender como é que este tipo de abordagem afeta o desempenho vamos analisar um pouco a seguinte equação – uma métrica vulgarmente utilizada para avaliar o desempenho de um sistema de computação. Melhorar o desempenho significa reduzir o termo à esquerda do sinal de igual (=), porque quanto menor for

o tempo que um programa demora para ser executado, melhor será o desempenho do sistema. As máquinas CISC tentam atingir este objetivo reduzindo o primeiro termo à direita do sinal de igual, isto é, o número de instruções por programa. Os projetistas pensaram que ao reduzir o número de instruções que a máquina executa para completar uma determinada tarefa, pode – se – ia reduzir o tempo que ela necessita para completar essa mesma tarefa, aumentando, assim, o seu desempenho. Assim, ao reduzir o tamanho dos programas conseguiam – se dois propósitos: por um lado era necessária uma menor quantidade de memória para armazenar o código; e por outro o tempo de execução era, também, diminuído pois havia menos linhas de código para executar. Além de implementar todo o tipo de instruções que faziam um variado número de tarefas como copiar strings ou converter valores para BCD entre muitas outras,