Risc E Cisc

COMPARAÇÃO ENTRE ARQUITETURAS RISC E CISC - RESUMO

Talvez a abordagem mais comum para a comparação entre RISC e CISC seja a de listar as características de ambas e colocá-las “lado-a-lado” para comparação, discutindo o modo como cada característica ajuda ou não o desempenho. Esta abordagem é correta se estivermos a comparar duas peças de tecnologia contemporâneas, como os sistemas operativos, placas de vídeo, CPU’s específicos, etc., mas ela falha quando aplicada ao nosso debate. Falha porque RISC e CISC não são exatamente tecnologias, são antes estratégias de projeto de CPU’s – abordagens para atingir um certo número de objetivos definidos em relação a um certo conjunto de problemas. Ou, para ser um pouco mais abstrato, poderíamos chamar-lhes filosofias de projeto de CPU’s, ou maneiras de pensar acerca de um determinado conjunto de problemas e das suas soluções. Comparar as arquiteturas RISC e CISC ,não requer apenas listar suas características mais sim 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 a VLSI, memória/armazenamento e compiladores nos anos 70 e inicio dos anos 80.

Memória e armazenamento

É difícil subestimar os efeitos que a tecnologia de armazenamento tinha no projeto de um 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. Apenas a título ilustrativo, em finais dos anos 70, 1 MB de memória RAM podia custar centenas de contos. Em meados dos anos 90, essa mesma quantidade de memória custaria apenas poucos (1-2) milhares de escudos . Adicionado ao preço da memória, o armazenamento secundário era caro e lento, por isso, colocar grandes volumes de código na memória desde o armazenamento secundário era, por si só, um grande impedimento ao desempenho.

O grande custo da memória e a lentidão do armazenamento secundário “conspiraram” para fazer com que a escrita de código fosse um assunto muito sério.

Compiladores

O trabalho de um compilador era relativamente simples nesta altura: traduzir código escrito numa linguagem de alto nível, como C ou Pascal, em assembly. O assembly era depois convertido para código máquina por um assemblador. A compilação demorava bastante tempo e o resultado dificilmente se poderia dizer óptimo. O melhor que se poderia esperar era que a tradução da linguagem de alto nível para o assembly fosse correta. Se realmente se quisesse código compacto e optimizado, a única solução era programar 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, quer porque os compiladores eram muito pobres e pouco robustos, quer porque a memória era lenta e cara causando 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 investigadores e projetistas defendiam que a única maneira de contornar os grandes problemas que viriam era mudar a complexidade do (cada vez mais caro) software e transportá-la para o (cada vez mais barato) 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 este objetivo. Aqui está 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.

RISC 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ário uma solução num único chip, uma solução que fizesse melhor uso dos escassos recurso disponibilizados (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 otimizar 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