De acordo com o Digital Design and Computer Architecture da Harris and Harris, existem várias maneiras de implementar um processador MIPS, incluindo o seguinte:
A microarquitetura de ciclo único executa uma instrução inteira em um ciclo. (...)
A microarquitetura multiciclo executa instruções em uma série de ciclos mais curtos. (...)
A microarquitetura em pipeline aplica pipelining à microarquitetura de ciclo único.
As arquiteturas são frequentemente classificadas como RISC ou CISC. De RISC vs. CISC :
Os processadores RISC usam apenas instruções simples que podem ser executadas dentro de um ciclo de clock.
Como o MIPS é a arquitetura RISC, estou um pouco confuso com as definições acima e me pergunto se não há algum tipo de contradição entre elas. Mais especificamente:
- Se uma instrução RISC pode ser dividida em ciclos mais curtos (Buscar, Decodificar, ...), como podemos dizer que são necessários apenas um ciclo de clock para executar toda a instrução? Não é necessário um ciclo de relógio para executar cada uma das etapas?
- Será que ela realmente assumir um ciclo de clock para executar uma instrução RISC? O que acontece, por exemplo, se ocorrer uma falha no cache e o processador precisar aguardar a DRAM lenta? Isso não deveria prolongar bastante a execução da instrução?
- O que exatamente é um ciclo de instruções? É o tempo que leva para uma instrução terminar (ou seja, um / vários ciclos de clock)?
- Quanto tempo uma instrução CISC leva em ciclos de relógio / instrução?
Respostas:
As definições práticas de RISC e CISC são tão turvas e borradas agora que são quase sem sentido. Agora é melhor pensar nelas como mais sobre "filosofia", no sentido de que uma arquitetura CISC possui um conjunto de instruções mais rico com instruções individuais mais poderosas (por exemplo, DIV e similares), enquanto um conjunto de instruções RISC é simples e rápido, e deixa para o compilador implementar operações complexas. Até mesmo supostos conjuntos de instruções CISC (como x86) são traduzidos em instruções internas nos chips Intel e AMD e implementados mais como processadores RISC. Para responder suas perguntas:
Os processadores RISC acadêmicos originais (e acho que talvez as primeiras versões comerciais) realmente executaram uma instrução por ciclo, incluindo busca e decodificação. Isso foi possível porque os caminhos de dados eram super limpos porque as operações de cada estágio eram simples e bem definidas. (a troca aqui é apenas instruções muito simples podem ser implementadas dessa maneira). Quando chegou ao mundo real, as coisas ficaram borradas. Coisas como pipelining e arquitetura superescalar tornam impossível uma simples dicotomia RISC / CISC.
Os chips RISC originais tentaram executar uma instrução por ciclo e poderiam fazê-lo se os dados estivessem disponíveis no arquivo de registro. Obviamente, se o processador tivesse que ir para a DRAM, levaria muito mais tempo. O RISC é sobre "tentar" executar uma instrução por ciclo.
Um ciclo de instrução é o tempo que leva entre as buscas.
Depende enormemente da instrução e da arquitetura do conjunto de instruções. Mesmo em uma arquitetura CISC, algumas instruções podem ser executadas muito rapidamente (como um deslocamento para a esquerda ou direita, por exemplo). Alguns são executados muito lentamente (10s de ciclos ou mais). A arquitetura VAX (provavelmente o auge da filosofia CISC) tinha instruções realmente complexas. Aliás, uma arquitetura CISC é geralmente mais fácil de programar em assembly do que uma arquitetura RISC porque é quase como uma linguagem de alto nível!
fonte
A resposta curta
As etapas de decodificação e execução da instrução são executadas em paralelo com a próxima etapa da instrução anterior. Essa técnica é conhecida como pipelining. Veja Em processadores RISC abaixo.
Uma arquitetura RISC de emissão única normalmente mede em média um pouco menos de uma instrução por ciclo devido a estados de espera e tempo gasto para operações de carregamento / armazenamento que atingem a memória, em vez de apenas serem registradas para se registrar. Os slots de atraso oferecem um gancho arquitetural que pode permitir que você recupere parte desse tempo. Consulte Processadores RISC abaixo.
Um ciclo de instruções é o período de tempo necessário para executar uma instrução. Isso varia de acordo com a arquitetura e (em alguns casos) as instruções. Por exemplo, a maioria das instruções sobre algo como um MIPS R2000 / 3000 leva um ciclo. As instruções que envolvem o acesso à memória (carregamento / armazenamento, ramificação) levam mais de um ciclo, embora os slots de atraso signifiquem que você possa executar outra coisa (possivelmente apenas um NOP) no slot de atraso. Arquiteturas sem pipeline podem ter ciclos de instruções de vários ciclos de clock, geralmente variando com o modo de endereçamento. Consulte Processadores RISC, arquiteturas CISC tradicionais e arquiteturas conectadas abaixo.
Projetos de questões múltiplas podem embaçar esse conceito, executando mais de uma instrução em paralelo.
Os processadores CISC podem ter instruções que levam diferentes períodos de tempo. O número exato de ciclos de clock depende da arquitetura e das instruções. O número variável de ciclos de clock adotados nos ISA da CISC é uma das razões pelas quais é difícil incorporar arquiteturas com pipelines pesadas. Veja as arquiteturas tradicionais do CISC abaixo.
A resposta mais longa
Para um único problema MIPS, SPARC ou outra CPU, todas as instruções (para uma primeira aproximação) são emitidas em um ciclo, embora possam ter algo conhecido como 'slot de atraso'.
Em processadores RISC
Nesse contexto, uma única CPU de problema é aquela em que a CPU não faz nenhuma análise de dependência imediata e emissão paralela de instruções da mesma forma que as CPUs modernas, ou seja, elas têm apenas uma unidade de execução que executa as instruções em a ordem em que são lidos da memória. Mais sobre isso mais tarde.
A maioria dos processadores RISC mais antigos são de edição única e esses tipos ainda são amplamente utilizados em sistemas embarcados. Um núcleo RISC inteiro de edição única de 32 bits pode ser implementado em cerca de 25.000 a 30.000 portas, portanto, os núcleos de CPU desse tipo têm consumo de energia muito baixo e pegadas muito pequenas. Isso os torna fáceis e baratos de integrar nos produtos SOC (sistema no chip).
Os projetos de CPU do RISC são canalizados - o processamento da instrução é feito em vários estágios, com cada instrução sendo passada pelo pipeline para o próximo estágio a cada ciclo de clock. Na maioria dos casos, uma CPU em pipeline de um único problema executará algo próximo a uma instrução por ciclo de clock.
Algumas arquiteturas têm instruções como ramificação ou carregamento / armazenamento da memória, onde o ciclo adicional utilizado pelo acesso à memória é visível para o código.
Por exemplo, em um projeto SPARC V7 / V8 , a próxima instrução após a execução de uma ramificação antes da ocorrência da ramificação. Normalmente, você colocaria um NOP no slot após a ramificação, mas poderia colocar outra instrução nele se encontrasse algo útil para fazer.
A arquitetura MIPS R2000 / R3000 tinha um slot de atraso semelhante nas instruções de carregamento / armazenamento. Se você carregasse um valor da memória, ele não seria exibido no registro por outro ciclo. Você poderia colocar um NOP no slot ou fazer outra coisa se pudesse encontrar algo útil para fazer que não dependesse da operação de carregamento que você acabou de emitir.
Se a memória estiver mais lenta que a CPU, o que geralmente ocorre, você poderá obter estados de espera adicionais nos acessos à memória. Os estados de espera congelam a CPU por um ou mais ciclos de clock até que o acesso à memória seja concluído. Na prática, esses estados de espera e tempo extra para acessos à memória significam que os designs de CPU de emissão única têm em média um pouco menos de uma instrução por ciclo de clock. Os slots de atraso oferecem algumas oportunidades possíveis para otimizar o código executando outras instruções enquanto ocorre uma operação de memória.
Processadores CISC tradicionais
Os processadores CISC eram projetos que podiam ter instruções com duração variável. Freqüentemente, eles tinham instruções mais complexas implementadas diretamente no hardware que precisavam ser executadas no software em uma CPU RISC.
A maioria das arquiteturas de mainframe e praticamente todos os projetos de PCs até o M68K e o intel 386 eram CPUs CISC microcodificadas tradicionais. Esses projetos provaram ser mais lentos por relógio e usavam mais portas do que as CPUs RISC.
Microcódigo
Um exemplo de uma arquitetura microcodificada (MOS 6502) pode ser visto em emulação aqui . O microcódigo pode ser visto na parte superior da imagem.
O microcódigo controla os fluxos de dados e as ações ativadas na CPU para executar instruções. Ao percorrer as etapas do microcódigo, você pode ativar as partes de uma CPU, mover dados pelas ALUs ou executar outras etapas. Componentes reutilizáveis na CPU podem ser coordenados em vários ciclos de clock para executar uma instrução. No caso do 6502, algumas ações em pipeline também podem ser executadas pelo microcódigo.
Os projetos de microcodificação usavam menos silício do que os chips conectados à custa de potencialmente levar vários ciclos de relógio para concluir uma instrução. Dependendo do design, essas CPUs levariam vários períodos de tempo por instrução.
Arquiteturas conectadas
Os projetos conectados (não necessariamente mutuamente exclusivos com microcódigo) executam uma instrução de forma síncrona ou podem ter seus próprios coordenadores para fazer algo em vários ciclos de clock. Eles geralmente são mais rápidos às custas de hardware mais dedicado e, portanto, são mais caros de implementar do que um design microcodificado de funcionalidade equivalente.
Um exemplo famoso disso foi a CPU Amdahl 470/6 original , que foi um substituto para a CPU em certos modelos IBM System / 370. A CPU da Amdahl era um design com fio no momento em que as 370 CPUs da IBM eram fortemente baseadas em microcódigo. A CPU da Amdahl foi cerca de três vezes mais rápida que as da IBM substituídas.
Desnecessário dizer que a IBM não se divertiu e isso resultou em uma batalha judicial que acabou forçando a IBM a abrir sua arquitetura de mainframe até que o decreto de consentimento expirasse alguns anos atrás.
Normalmente, um design com fio desse tipo ainda não era tão rápido como uma CPU RISC quanto os diferentes tempos e formatos das instruções não permitiam tanto espaço para pipelines quanto um design RISC.
Projetos de várias edições
As CPUs mais modernas são várias arquiteturas de problemas que podem processar mais de uma instrução por vez em um único encadeamento. O chip pode fazer uma análise de dependência dinâmica no fluxo de instruções recebidas e emitir instruções em paralelo, onde não há dependência do resultado de um cálculo anterior.
A taxa de transferência desses chips depende de quanto paralelismo pode ser alcançado no código, mas a maioria das CPUs modernas calcula a média de várias instruções por ciclo na maioria dos códigos.
A Intel moderna e outras CPUs ISA x86 / X64 têm uma camada que interpreta o conjunto de instruções CISC da velha escola em micro instruções que podem ser alimentadas através de um núcleo de múltiplos problemas no estilo RISC em pipeline. Isso adiciona alguma sobrecarga que não está presente nas CPUs com ISAs projetadas para pipelining (ou seja, arquiteturas RISC, como ARM ou PowerPC).
Projetos VLIW
Os projetos VLIW, dos quais o Intel Itanium é talvez o mais conhecido, nunca decolaram como arquiteturas convencionais, mas no IIRC existem várias arquiteturas DSP que usam esse tipo de design. Um design VLIW torna vários problemas explícitos com uma palavra de instrução contendo mais de uma instrução emitida em paralelo.
Isso dependia de bons compiladores de otimização, que identificavam dependências e oportunidades de paralelismo, colocando instruções nos vários slots disponíveis em cada palavra de instrução.
As arquiteturas VLIW funcionam muito bem para aplicativos numéricos, pois as operações de matriz / matriz tendem a oferecer oportunidades para um paralelismo extensivo. O Itanium possuía um nicho de mercado em aplicativos de supercomputação por um tempo e havia pelo menos uma arquitetura de supercomputador - o Multiflow TRACE - foi produzida usando um ISA desse tipo.
Memória e cache
As CPUs modernas são muito, muito mais rápidas que a memória; portanto, as leituras diretas da memória podem gerar centenas de estados de espera que bloqueiam a CPU até que o acesso à memória seja concluído. O cache, agora feito em várias camadas, mantém os locais de memória usados mais recentemente no cache. Como as CPUs normalmente passam a grande maioria do tempo executando o código em loops, isso significa que você obtém boas taxas de acerto ao reutilizar os locais de memória usados recentemente. Essa propriedade é chamada 'localidade de referência'.
Onde você obtém a localidade de referência, a CPU pode operar na velocidade ideal. As falhas de cache até o próximo nível incorrem em vários estados de espera; falhas de cache na memória principal podem incorrer em centenas.
Assim, a taxa de transferência real dos chips da CPU pode ser fortemente dependente da eficiência dos padrões de acesso à memória. Livros inteiros foram escritos sobre como otimizar código para isso, e é um tópico complexo por si só.
fonte
É uma simplificação para os alunos.
Todo processador não trivial é canalizado. Há uma unidade de pré-busca que limpa as instruções em uma extremidade, várias unidades de execução no meio realizando o trabalho real e uma unidade de problema responsável por declarar as instruções concluídas após a gravação no registro ou a memória ter sido concluída. Se houver várias unidades de execução (por exemplo, uma ALU inteira, uma ALU de ponto flutuante e unidade vetorial), poderá ser possível emitir (às vezes chamado "aposentar") várias instruções por ciclo de clock. Como uma CPU pode fornecer mais de uma instrução por ciclo? entra em muitos mais detalhes sobre isso.
Como você diz, e se houver um atraso de falta de cache? O Intel Hyperthreading é uma solução nova para isso: dois lotes de registros de estado da CPU, um lote de lógica de controle e unidades de problemas. Assim que uma CPU virtual parar, troque para o estado da outra. (esta é uma simplificação excessiva)
O resultado disso é que os manuais modernos da CPU fornecem tempos de instruções muito mais vagos e é muito mais difícil escrever um código de tempo com precisão de ciclo, se, por exemplo, você está tentando produzir vídeo em tempo real a partir de hardware que não deveria ser capaz .
(Resposta específica para "Quanto tempo uma instrução CISC leva em ciclos de relógio / instrução?" É "consulte o manual de referência do fabricante e terá tempos por instrução")
fonte
Os outros caras escreveram muito material bom, então vou manter minha resposta curta: antigamente (aqui nos anos 80), os processadores de 8 bits do dia (6800, 6502, Z80, 6809 e outros) eram considerados CISC. Algumas instruções podem ser executadas em dois estilos de relógio, mas essas são simples instâncias, como definir / limpar bits de flag em um registro de status do processador. Outras instruções podem levar de 2 a 6 e até 9 ciclos de execução. Esses processadores tinham algumas instruções bastante poderosas, o Z80 possuía algumas instruções de limpeza de bloco de memória que gravariam o mesmo valor em uma série de bytes na memória, limpando efetivamente um bloco grande em uma única instrução, apenas configurando alguns registros e executando o Instrução LDIR (carregar, incrementar e repetir).
O processador 6502 (da memória) tinha 56 instruções, mas 13 modos de endereçamento, criando um poderoso conjunto de instruções.
O RISC veio longo e adotou uma abordagem diferente, com algumas instruções que são executadas em um único ciclo de relógio. Os programas tendem a ser mais longos e ocupam mais memória, porque as instruções são simples nas operações que eles executam, e você precisa de mais delas.
Se bem me lembro, a primeira tentativa de uma arquitetura RISC foi o transputador ou o processador Acorn Risc?
fonte