RISC: diferenças entre revisões
Conteúdo apagado Conteúdo adicionado
m +correções semiautomáticas (v0.50/3.1.38); -texto em inglês que nunca vai ser traduzido e que só polui o código-fonte da página; +tag |
|||
Linha 1:
{{Reciclagem|data=outubro de 2016}}
RISC ([[acrônimo]] de '''''Reduced Instruction Set Computer'''''; em português, "Computador com um conjunto reduzido de instruções") é uma linha de [[arquitetura de processador|arquitetura de processadores]] que favorece um conjunto simples e pequeno de [[Conjunto de instruções|instruções]] que levam aproximadamente a mesma quantidade de tempo para serem executadas. Muitos dos [[microprocessadores]] modernos são RISCs, por exemplo [[DEC Alpha]], [[SPARC]], [[arquitetura MIPS|MIPS]], e [[PowerPC]]. Os computadores atuais misturam as duas arquiteturas, criando o conceito de [[arquitetura híbrida]], incorporando os conceitos das duas arquiteturas e a inclusão de um núcleo RISC aos seus processadores. O tipo de microprocessador mais comum em desktops, o [[x86]], é mais semelhante ao [[CISC]] do que ao RISC, embora [[Circuito integrado|chips]] mais novos traduzam [[instruções x86]] baseadas em arquitetura CISC em formas baseadas em arquitetura RISC mais simples, utilizando prioridade de execução.
Os processadores baseados na computação de conjunto de instruções reduzidas não têm [[micro-programação]], as instruções são executadas diretamente pelo [[hardware]]. Como característica, esta arquitetura, além de não ter [[microcódigo]], tem o conjunto de instruções reduzidas, bem como baixo nível de complexidade.
Linha 59 ⟶ 60:
Como é usual acontecer em qualquer área da atividade humana, é raro que algum conceito ou tecnologia importante obtenha unanimidade entre pesquisadores, técnicos, projetistas e administradores. Este é o caso da arquitetura CISC, a qual sempre foi alvo de críticas e comentários sobre desvantagens e problemas. Neste texto não cabe posicionamento por este ou aquele fato ou tecnologia, mas sim apresentar todos os elementos possíveis das diversas tendências, no caso entre CISC e RISC. No entanto, para se compreender o surgimento de processadores com arquitetura RISC deve-se analisar os eventuais problemas indicados para a arquitetura CISC, que levaram pesquisadores e projetistas de sistemas a criar uma alternativa, considerada por eles mais vantajosa.
Para entender melhor as raízes do surgimento da filosofia RISC, pode-se mencionar alguns pontos das arquiteturas CISC citados como problemáticos por um dos criadores de máquinas RISC, David Patterson, em um de seus artigos, induzindo ao projeto de processadores que pudessem, com sua especificação mais simples, reduzir ou eliminar os citados problemas. Na realidade, parece ter sido Patterson quem primeiro definiu as arquiteturas com muitas e poderosas instruções de CISC e sua máquina protótipo de RISC (o nome escolhido foi RISC-1):
* '''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 II|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.
Linha 78 ⟶ 76:
Uma força importante incentivar a complexidade era o fato das memórias principais serem muito limitadas (da ordem de kilobytes). Foi, portanto, vantajosa para a densidade de informações contidas em programas de computador a ser elevado, levando a características tais como alta codificação, instruções de comprimento variável, fazendo o carregamento de dados, bem como o cálculo (como mencionado acima). Estas questões foram de maior prioridade que a facilidade de decodificação de instruções.
Uma razão igualmente importante foi que as memórias principais foram bastante lentas (um tipo comum foi a memória de núcleo de ferrite), usando a embalagem de informação densa, pode-se reduzir a
== Filosofia de Desenvolvimento RISC ==
Em meados de 1970 investigadores (em especial John Cocke) da IBM (e projetos semelhantes em outros lugares) demonstraram que a maioria das combinações desses modos ortogonais de endereçamento e as instruções não foram utilizados pela maioria dos programas gerados por compiladores disponíveis no momento. Ele revelou-se difícil em muitos casos, para escrever um compilador com mais que a capacidade limitada de tirar proveito dos recursos oferecidos pelos processadores convencionais.
Também foi descoberto que, em implementações de arquiteturas microcodificadas, certas operações complexas tendem a ser mais lentas do que uma sequência de operações mais simples fazendo a mesma coisa. Isso foi em parte um efeito do fato de que muitos projetos foram levados às pressas, com pouco tempo para otimizar ou sintonizar todas as instruções, mas sim apenas aquelas usadas com mais
Como mencionado anteriormente, a memória de núcleo há muito havia sido mais lenta do que muitos projetos de CPU. O advento de memórias de semicondutores reduziu essa diferença, mas ainda era aparente que mais registradores (e mais tarde caches) permitiria maior
Contudo um outro impulso de ambos os RISC e outros projetos veio a partir de medições práticas em programas no mundo real. [[Andrew Tanenbaum]] resumiu muitos destes, demonstrando que os processadores tiveram muitas vezes tamanhos desproporcionais imediatos. Por exemplo, ele mostrou que 98% de todas as constantes em um programa iriam caber em 13 bits, mas muitos projetos CPU dedicam de 16 ou 32 bits para armazená-los.
Linha 110 ⟶ 108:
Em meados de 1970 investigadores (em especial John Cocke) da IBM (e projetos semelhantes em outros lugares) demonstraram que a maioria das combinações desses modos ortogonais de endereçamento e as instruções não foram utilizados pela maioria dos programas gerados por compiladores disponíveis no momento. Ele revelou-se difícil em muitos casos, para escrever um compilador com mais que a capacidade limitada de tirar proveito dos recursos oferecidos pelos processadores convencionais.
Também foi descoberto que, em implementações de arquiteturas microcodificadas certas operações complexas tendem a ser mais lentas do que uma sequência de operações mais simples fazendo a mesma coisa. Isso foi em parte um efeito do fato de que muitos projetos foram levados às pressas, com pouco tempo para otimizar ou sintonizar todas as instruções, mas sim apenas aquelas usadas com mais
Como mencionado anteriormente, a memória de núcleo há muito havia sido mais lenta do que muitos projetos de CPU. O advento de memórias de semicondutores reduziu essa diferença, mas ainda era aparente que mais registradores (e mais tarde caches) permitiria maior
Contudo um outro impulso de ambos os RISC e outros projetos veio a partir de medições práticas em programas no mundo real. [[Andrew Tanenbaum]] resumiu muitos destes, demonstrando que os processadores tiveram muitas vezes tamanhos desproporcionais imediatos. Por exemplo, ele mostrou que 98% de todas as constantes em um programa iriam caber em 13 bits, mas muitos projetos CPU dedicam de 16 ou 32 bits para armazená-los. Isto sugere que, para reduzir o número de acessos à memória, uma máquina de comprimento fixo pode armazenar constantes em bits não utilizados da palavra de instrução em si, de modo que eles seriam imediatamente prontos quando a CPU precisa deles (muito parecido com endereçamento imediato em um desenho convencional). Estes necessários e pequenos opcodes, ocorreram a fim de deixar espaço para uma constante com um tamanho razoável em uma palavra de instrução de 32 bits.
Linha 134 ⟶ 132:
- execução rápida de cada instrução (uma a cada ciclo de clock).
'''Menor quantidade de instruções:
Com o conjunto de instruções reduzido e cada uma delas tendo suas funções otimizadas, os sistemas possuíam um resultado melhor em questão de desempenho. Em virtude do conjunto reduzido das instruções, acarretavam em programas um pouco mais longos.
Linha 145 ⟶ 143:
A busca pelas instruções foi facilitada porque todas as instruções possuem o mesmo tamanho em bits e alinhadas a largura da palavra. Por isso não é mais necessário verificar o tamanho do contador de instruções, pois ele é incrementado sempre com o mesmo valor. Com isso, não tem risco da instrução ocupar duas páginas de dados diferentes, porque traria problemas para o sistema operacional na hora do acesso.
'''Execução otimizada de chamadas de função:
Em virtude disso, na arquitetura RISC foram utilizados mais registradores. As chamadas de função que na arquitetura CISC ocorriam com acessos a memória, mas na RISC isso era feito dentro do processador mesmo, utilizando os registradores que foram colocados a mais.
'''Modo de execução com Pipelining:
Imaginando estágios de uma linha de montagem, não é interessante que um estágio termine antes do outro, pois nesse caso perde-se a vantagem da linha de montagem. O objetivo de cada instrução, é completar um estágio de pipeline em um ciclo de [[clock]], mas esse objetivo nem sempre é alcançado.
Linha 155 ⟶ 153:
O processamento de uma instrução é composto pelo menos por cinco fases:
* Instruction fetch;
* Instruction decode;
* Operand fetch;
Linha 234 ⟶ 231:
Isso não é necessariamente correto se considerarmos que uma menor quantidade de instruções nem sempre acarreta menor quantidade de bits (e é a quantidade efetiva de bits que consome menos memória e a menor custo). Se cada instrução CISC possuir mais operandos que as instruções RISC e se cada um de seus operandos ocupar uma boa quantidade de bits na instrução, então poderemos ter um programa CISC maior em bits do que um programa em máquina RISC, apesar de o programa para o processador RISC possuir maior quantidade de instruções.
Por exemplo, um programa escrito para rodar em um processador CISC pode gastar 150 instruções de máquina; cada uma das instruções possui código de operação de 8 bits, podendo ser de um, dois, e três operandos. Cada campo operando ocupa 18 bits e ainda há um campo para outras ações, com
As instruções são, em sua esmagadora maioria, de dois operandos, porém os operandos são valores em registradores e, por isso, as instruções não consomem muitos bits para endereçar os dois registradores.
O programa para a máquina CISC gastaria 7.500 bits, enquanto o programa para a máquina RISC, mesmo possuindo mais 70 instruções que o processador CISC, consumiria 7.040 bits.
Linha 252 ⟶ 249:
Características CISC
* Controle microprogramado;
* Instruções de dois operandos ADD CX,mem;
Linha 263 ⟶ 260:
Características RISC
* Controle por hardware;
* Pequeno conjunto de instruções;
Linha 298 ⟶ 295:
* SuperH Hitachi, originalmente em amplo uso na Super Sega 32X, Saturn e Dreamcast, agora no coração de muitos dispositivos eletrônicos de consumo. O SuperH é a plataforma base para a Mitsubishi - Hitachi grupo de semicondutores comuns. Os dois grupos se fundiram em 2002, caindo arquitetura RISC própria Mitsubishi, o M32R.
* Atmel AVR usado em uma variedade de produtos, incluindo desde os controladores de Xbox portátil para carros BMW.
{{Referências}}
== Ligações externas ==
*
*
*
{{Portal3|Tecnologias de informação}}
|