Arquiteturas RISC E CISC

Arquiteturas RISC e CISC

Introdução

A abordagem mais comum para a comparação entre RISC e CISC seria coloca-las “lado-a-lado”. RISC e CISC não são exatamente tecnologias, são estratégias de projetos de CPU’s, ou poderíamos chamar-lhes filosofias de projetos de CPU’s, ou maneiras de pensar acerca de um determinado conjunto de problemas e das suas soluções. Cada uma delas foi uma abordagem ao projeto de maquinas que os projetistas sentiram ser mais eficiente no uso dos recursos tecnológicos existentes na época. Assim sendo, uma comparação entre as arquiteturas RISC e CISC requer mais do que uma listagem de características, benchmarks, etc. Cada uma requer um contexto histórico.

Para entender o contexto histórico e tecnológico de onde evoluíram as arquiteturas RISC e CISC é necessário, em primeiro lugar entender o estado das coisas em relação à VLSI, memória/armazenamento e compiladores nos anos 70 e inicio dos 80.

Memória e armazenamento

Nos anos 70 os computadores usavam memória de cariz magnético para armazenar o código dos programas, memória que era, não só, cara como também bastante lenta. Depois da introdução da RAM as coisas melhoraram em termos de velocidade, no entanto o seu preço era ainda proibitivo.

Compiladores

O trabalho de um compilador era relativamente simples nesta altura: traduzir códigos escritos numa linguagem de alto nível, como C ou Pascal, em assembly.

VLSI

Em termos de VLSI (Very Large Scale Integration) a tecnologia da altura apenas permitia densidades de transístores que seriam muito baixas quando comparadas com os Standards de hoje. Era simplesmente impossível colocar muitas funcionalidades num único chip. No início dos anos 80, quando se começou a desenvolver a arquitetura RISC, um milhão de transístores num único chip era já bastante. Devido à falta de recursos (transístores) as máquinas CISC da altura tinham as suas unidades funcionais espalhadas por vários chips. Isto era um problema por causa do alto tempo de espera nas transferências de dados entre os mesmos, o que desde logo era um óbice ao desempenho. Uma implementação num único chip seria o ideal.

CISC

No inicio dos anos 70, os compiladores eram muito pobres e pouco robustos, porque a memória era lenta e cara causando sérias limitações no tamanho do código, levou a que 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 investigadores e 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 transportá-la para o (cada vez mais barato) hardware. Se houvesse uma função mais comum, que o programador tivesse de escrever 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 à ideia impulsionadora por trás da filosofia CISC, e quase tudo o que um verdadeiro CISC faz tem este objetivo. Alguns investigadores 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 (C ou Pascal).

Uma listagem 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 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 de manutenção.

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. Melhorar o desempenho significa reduzir o tempo porque quanto menor for o tempo que um programa demora a ser executado, melhor será o desempenho do sistema. As máquinas CISC tentam atingir este objetivo, isto é, o número de instruções por programa. Os investigadores pensaram que ao reduzir o número de instruções que a máquina executa para completar uma determinada tarefa, poderia reduzir o tempo que ela necessita para completar essa mesma tarefa, aumentando assim seu desempenho.

Ao reduzir o tamanho dos programas conseguiam-se dois propósitos: uma menor quantidade de memória para armazenar o código; e por outro o tempo de execução também era diminuído, pois havias menos linha 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, havia outra táctica que os projetistas utilizavam para reduzir o tamanho do código e a sua complexidade: os modos de endereçamento complexos.

A figura seguinte ilustra um esquema de armazenamento para um computador genérico. Se quiséssemos multiplicar dois números, teríamos primeiro que carregar cada um dos operandos de uma localização na memória para um dos registos.

Figura 1. Esquema de armazenamento para um computador genérico.

Uma vez carregados nos registos, os operandos poderiam ser multiplicados pela unidade de execução (ALU – Aritmetric Logic Unit). Utilizaríamos as seguintes linhas de código para multiplicar o