Arquitectura de Computadores II

Transcrição

1 Departamento de Ciências e Tecnologias da Informação Arquitectura de Computadores II Textos de apoio Pipelines Versão 0.02 Junho de 2010 Tomás Brandão.

2 ISCTE-IUL - DCTI 2

3 Índice 1. ITRODUÇÃO FUCIOAMETO COFLITOS CONFLITOS DE DADOS CONFLITOS ESTRUTURAIS CONFLITOS DE CONTROLO DESEMPEHO BIBLIOGRAFIA LISTA DE REVISÕES ISCTE-IUL - DCTI 3

4 ISCTE-IUL - DCTI 4

5 1. Introdução othing is particularly hard if you divide it into small jobs. Henry Ford ( ) Actualmente, a utilização de técnicas de pipelining é um dos factores mais importantes no projecto e implementação de processadores com elevado desempenho. A principal ideia do funcionamento em pipeline consiste em processar cada instrução segundo várias etapas. Desta maneira, conseguem-se processar várias instruções em simultâneo, estando cada uma delas numa determinada etapa do seu processamento. Pode-se estabelecer uma analogia entre um processador em pipeline e uma linha de montagem numa fábrica de automóveis. Na fábrica de automóveis, cada carro é construído ao longo de vários pontos de montagem, cada um deles especializado numa dada etapa da sua construção. Por exemplo: chassis carroçaria motor interiores pintura. Como em cada momento se tem um automóvel em cada etapa, é fácil de concluir podem estar a ser construídos vários automóveis em simultâneo na linha de montagem. A construção dos automóveis usando uma linha de montagem é também mais eficiente do que uma construção carro a carro. No caso de um pipeline, a ideia é muito semelhante, mas em vez de uma fábrica tem-se um processador, e em vez de automóveis têm-se instruções. ISCTE-IUL - DCTI 5

6 M U X Inc End. salto Tipo salto Const Controlo de saltos P C Memória de instruções Ra Banco Rb de registos Rd M U X ALU Memória de dados M U X Figura 1 Esquema genérico de um processador com uma unidade de controlo uni-ciclo. 2. Funcionamento Para compreender o funcionamento de um processador em pipeline, considere em primeiro lugar a Figura 1, que representa a arquitectura de um processador com uma unidade de controlo uni-ciclo. No lado esquerdo da figura está o registo program counter (PC), que guarda o endereço da próxima instrução a executar. Esta é lida da memória de instruções e, a partir do seu códigomáquina extrai-se o opcode e os operandos. Para o processador representado, e consoante o tipo de instrução a executar, os operandos poderiam ser índices dos registos fonte (R a e R b ) e destino (R d ), uma constante (endereçamento imediato), um endereço de destino de salto, etc. Esta arquitectura simplificada inclui também uma ALU, que realiza operações sobre os dados que são lidos dos registos, ou constantes que são operandos imediatos. O resultado pode ser escrito na memória de dados ou num registo. Para o caso das instruções de salto, existe também um módulo de controlo de saltos que, com base nas flags da ALU, permite a realização de saltos condicionais. Este módulo gera um sinal que actua no multiplexer associado ao PC, escolhendo entre o valor de PC+1 e o endereço destino do salto (caso o salto seja tomado). A arquitectura do processador anterior sugere que processamento de cada instrução possa ser feito de acordo com as seguintes etapas (representadas na Figura 2): Fetch da instrução (IF instruction fetch) leitura da instrução a processar, relembre que a instrução é lida da posição de memória indicada pelo program counter (PC); Descodificação da instrução (ID instruction decode) é obtido o opcode e os operandos da instrução; são também lidos os valores que estão nos registos fonte. Execução (EXE) são feitas as operações aritméticas-lógicas que envolvem os operandos. No caso da instrução a executar ser uma instrução de salto condicional, vai-se assumir que é também nesta etapa que é feita a verificação da condição de salto. Acesso à memória (MEM) é feito o acesso à memória para leitura ou escrita de dados. Escrita do resultado (WB write-back) é escrito um resultado no registo de destino. Esse resultado pode vir da ALU ou ser um valor que foi lido da memória. ISCTE-IUL - DCTI 6

7 Fetch da instrução Descodificação Execução Acesso à memória Escrita do resultado M U X End. salto Tipo salto Controlo de saltos Inc Const P C Memória de instruções Ra Banco Rb de registos Rd M U X ALU Memória de dados M U X Figura 2 Acções envolvidas durante o processamento de uma instrução. IF ID EXE MEM WB Figura 3 Etapas de processamento de uma instrução. Esquematizando, e de acordo com a divisão que foi feita, por cada instrução têm-se portanto a sequência de etapas que se encontram esquematizadas na Figura 3. Vamos agora supor que cada uma das etapas demora um certo tempo T etapa a ser realizada, e que esse tempo é igual para cada uma das etapas. Dentro desta assumpção, o tempo necessário para processar uma instrução é então dado por etapas T etapa, em que etapas é o número total de etapas envolvidas no processamento de uma instrução (neste exemplo, que vai ser seguido ao longo do texto, etapas = 5). A duração do ciclo de relógio do processador teria que ser de pelo menos o tempo necessário para realizar todas as etapas, i.e.: T = T ou, se preferir: f clock etapas etapa clock = etapas 1 T etapa. Suponha agora que se colocam registos (buffers) a separar as várias etapas e que se sincronizam todos esses registos com o mesmo sinal de relógio. Isto é, introduziam-se esses registos separadores entre as várias etapas do modo esquematizado na Figura 4. Como os registos separadores estão todos sincronizados pelo mesmo sinal, vão todos reagir ao mesmo tempo. Quer isto dizer que, por cada impulso do sinal de relógio, o resultado de uma dada etapa vai passar para a etapa que se segue, acontecendo isto em simultâneo para todas as etapas. ISCTE-IUL - DCTI 7

8 IF ID EXE MEM WB Clock Figura 4 Separação e sincronização das várias etapas de processamento de instruções. Sendo assim, o tempo necessário para uma instrução ser processada continua a ser o correspondente ao tempo que demoram a ser feitas as 5 etapas, mas acontece agora um fenómeno muito importante: por cada impulso de relógio uma etapa calcula um resultado que é passado à etapa que se segue, e recebe os dados que são o resultado da etapa anterior. Ao fim de alguns impulsos de relógio vão estar várias instruções a serem processadas em simultâneo, cada uma delas a realizar uma certa etapa tem-se agora um pipeline. Por outro lado, como todas as etapas são realizadas ao mesmo tempo, a duração de um ciclo do sinal de relógio do processador é agora o correspondente ao tempo de propagação associado à etapa mais demorada. No caso ideal em que cada etapa demora T etapa a ser processada, a duração mínima de um ciclo do sinal de relógio passa a ser a correspondente a esse tempo. O ganho de um processador em pipeline face ao processador sem pipeline pode então ser escrito como: Ts / pipeline etapas Tetapa G = = = etapas. T T c / pipeline etapa Ou seja, consegue-se um processador que, em termos ideais e teóricos, tem um ganho correspondente ao número de etapas ( etapas ). Vejamos agora o que acontece com o CPI (clock pulses per instruction). No caso do processador com controlo uni-ciclo sem pipeline (ver Figura 1) o CPI tem o valor 1. Relembre que em cada ciclo do sinal relógio, faz-se o fetch e executa-se uma instrução. Para o caso do pipeline, o número de ciclos de relógio necessários para processar uma determinada instrução é agora o correspondente ao número de etapas etapas. No entanto, como estão a ser processadas etapas instruções diferentes em simultâneo (cada uma delas está numa etapa), o CPI do processador em pipeline também vai ser 1. Note que este é um valor teórico e ideal como se verá mais à frente, nem sempre é possível manter todas as etapas ocupadas com uma instrução, facto que tem implicações negativas no CPI (se isso acontecer, o CPI fica com um valor superior a 1). ISCTE-IUL - DCTI 8

9 3. Conflitos Tal como foi visto na secção anterior, o valor ideal para ganho de um processador em pipeline face a uma versão sem pipeline corresponde ao número de etapas do pipeline. No entanto, existem situações em que uma determinada instrução não pode imediatamente passar à etapa seguinte, o que causa atrasos ao funcionamento do pipeline. Estas situações designam-se por conflitos (hazards). Consoante a sua causa, os conflitos podem ser classificados em: Conflitos de dados quando uma instrução utiliza dados que dependem do resultado de uma outra instrução cujo processamento ainda não foi concluído. Conflitos estruturais quando duas instruções (em etapas diferentes) tentam aceder ao mesmo recurso hardware, sem que a arquitectura do processador o permita. Conflitos de controlo causados por instruções que alteram o fluxo sequencial de um programa (i.e., instruções de salto, ou quaisquer outras que alterem o valor de PC para um valor que não seja o de PC+1). Os conflitos são na realidade o factor que mais contribui para a degradação do ganho de desempenho ideal num pipeline. Nas sub-secções que se seguem, cada um dos tipos de conflito mencionados é analisado com maior detalhe Conflitos de dados Um conflito de dados ocorre devido a dependências de dados entre instruções. Para ilustrar melhor este conceito, considere a seguinte sequência de instruções:... add R0, R1, R2 sub R5, R0, R4... // R0 R1 + R2 // R5 R0 R4 Repare que a instrução sub lê o conteúdo de R0, que é o local onde é escrito o resultado da instrução add. Existe portanto uma dependência de dados que envolve ambas as instruções e o registo R0. Para este caso, o conflito de dados ocorre se a instrução sub tentar ler o conteúdo de R0 antes da instrução add lá escrever o resultado. Este tipo particular de conflitos de dados designa-se por conflito RAW (read after write). Em geral, um conflito RAW acontece quando se têm duas instruções inst_1 e inst_2 em que inst_1 é a que entra primeiro no pipeline (e portanto é para ser executada antes de inst_2). Suponha agora que inst_2 vai ler dados do mesmo registo onde inst_1 escreve o resultado (ou seja, inst_2 depende de inst_1). O conflito de dados ocorre no caso de inst_2 tentar ler o registo antes de inst_1 escrever o resultado. Esquematizando: inst_1: escreve no registo Rx... inst_2: lê o conteúdo do registo Rx ISCTE-IUL - DCTI 9

10 Voltando ao exemplo anterior (do add e do sub), e aplicando a sequência de instruções ao pipeline de 5 etapas da secção anterior, pode-se concluir que a instrução sub terá que ficar em espera na fase ID (a fase em que são lidos os registos) até que a instrução add chegue à fase de WB, onde se escreve o resultado da soma em R0. Tal comportamento pode ser ilustrado com a seguinte tabela, que representa as etapas em que cada uma das instruções está em cada ciclo: Instrução Ciclo k k+1 k+2 k+3 k+4 k+5 k+6 k+7 k+8... add R0, R1, R2 IF ID EXE MEM WB sub R5, R0, R4 IF ID ID ID EXE MEM WB... Uma possível resolução para estes conflitos é a introdução das chamadas bolhas, que correspondem basicamente a palavras de controlo que fazem com que uma etapa fique desocupada. Para o caso anterior, uma maneira diferente de visualizar o mesmo conceito é a que está representada na Figura 5. SUB R5,R0,R4 BB B ADD R0,R1,R2 IF ID EXE MEM WB Clock Figura 5 Conflito de dados resolvido através da introdução de bolhas. A forma de resolver este conflito foi a introdução de duas bolhas para atrasar a instrução sub. A introdução destas duas bolhas faz com que percam dois ciclos de processamento. Para resolver de uma forma mais eficiente os conflitos de dados do tipo RAW podem ser utilizados circuitos de forwarding. A ideia consiste em tirar partido do facto dos resultados de instruções já estarem calculados em etapas anteriores à da escrita nos registos. No exemplo que foi apresentado, o resultado da instrução add encontra-se calculado após a conclusão da etapa EXE. Como a instrução sub vai implicitamente utilizar esse resultado, uma forma de evitar a introdução de bolhas seria passar o resultado de add à instrução sub, assim que tal fosse possível. A instrução sub, em vez de utilizar o valor que foi lido de R0, utilizaria esse resultado (indo-o buscar ao buffer que separa a fase EXE da fase MEM). Este conceito pode ser observado na Figura 6. ISCTE-IUL - DCTI 10

11 R1 + R2 R0 IF ID EXE MEM WB Clock SUB R5,R0,R4 ADD R0,R1,R2 Figura 6 Circuitos de forwarding que possibilitam passar para a fase EXE resultados calculados pela instrução anterior. a fase EXE, em vez da instrução sub utilizar o valor que foi lido de R0, utiliza o resultado de R1+R2, calculado no ciclo anterior pela instrução add. Etapa EXE Etapa MEM Índ. R a Comparador Índ. R d Sel. Valor lido de R a Valor lido de R b 1 0 M U X MUX Sel. M U 0 X 1 ALU Memória de dados Índ. R b Comparador Índ. R d Figura 7 Detalhe dos circuitos de forwarding que possibilitam passar para a fase EXE resultados calculados pela instrução anterior. Para que o processador possa saber quando é que deve utilizar os circuitos de forwarding, é necessário um circuito que compare o índice do registo destino da instrução que entrou primeiro com os índices dos registos fonte da instrução que entrou depois. Caso de detecte uma situação em que o destino é igual à fonte, então selecciona-se o resultado da instrução da frente, descartando-se o valor que foi lido do registo pela instrução de trás. Esta selecção pode ser feita com base em multiplexers, como pode ser evidenciado na Figura 7. A utilização de circuitos de forwarding pode ser generalizada para mais etapas do pipeline, podendo ser colocados sempre que tal seja vantajoso. Para o pipeline tradicional de 5 etapas em estudo, seria vantajoso ter todos os circuitos de forwarding esquematizados na Figura 8. ISCTE-IUL - DCTI 11

12 IF ID EXE MEM WB Clock Figura 8 Circuitos de forwarding típicos num pipeline de 5 etapas. M[A] R0 IF ID EXE MEM WB Clock INC R0 BB LOAD R0, A Figura 9 Introdução de uma bolha apesar de serem usados circuitos de forwarding. No entanto, mesmo utilizando circuitos de fowarding sempre que possível, existem algumas dependências de dados particulares que continuam a causar conflitos, sendo necessária a introdução de bolhas para os resolver. Um exemplo de um conflito deste género é o que se apresenta no seguinte fragmento de código:... load R0, A // R0 M[A] inc R0 // R0 R Para este caso, será necessária a introdução de uma bolha, uma vez que o resultado da instrução load só está disponível depois desta concluir a fase de acesso à memória (MEM) apenas nessa altura é que a instrução inc pode passar à etapa EXE, utilizando os circuitos de forwarding, tal como é exemplificado na Figura Conflitos estruturais Um conflito estrutural ocorre quando duas instruções que estão em fases diferentes do pipeline tentam aceder ao mesmo recurso, sem que o hardware tenha suporte para que tal seja possível. Para ilustrar melhor uma situação deste género, suponha que se utiliza a mesma memória tanto para instruções como para dados. Nestas condições, pode acontecer uma situação em que o processador está a fazer o fetch de uma instrução (na etapa IF) e ao mesmo tempo uma instrução do tipo load ou store pode estar na fase de acesso à memória (etapa MEM) para ler ou escrever dados. Nesse caso, seria necessário atrasar o fetch de uma nova instrução, uma vez que os barramentos de dados e de endereços que ligam o processador à memória estariam ocupados com o acesso causado pela instrução do tipo load ou store. Para ilustrar o conceito, considere a seguinte sequência de instruções: ISCTE-IUL - DCTI 12

13 Instrução Ciclo k k+1 k+2 k+3 k+4 k+5 k+6 k+7 k+8... load R0, A IF ID EXE MEM WB add R1, R2, R3 IF ID EXE MEM WB sub R4, R4, R5 IF ID EXE MEM WB xor R6, R2, R3 IF ID EXE MEM WB... As fases que estão a sombreado são aquelas em que é feito um acesso à memória. Repare que, caso se use a mesma memória para dados e instruções, existe um conflito estrutural no ciclo k+3, pois ao mesmo tempo que a instrução load acede à memória para ler o conteúdo do endereço A, está ser feito o fetch da instrução xor, estando a ser acedido o endereço que está no registo program counter. Atendo à arquitectura do processador, fazer dois acessos diferentes no mesmo ciclo de relógio não é possível. Caso a memória de dados e instruções seja a mesma, uma possível hipótese de resolver o conflito seria atrasar o fetch da instrução xor um ciclo, introduzindo uma bolha no pipeline. Instrução Ciclo k k+1 k+2 k+3 k+4 k+5 k+6 k+7 k+8... load R0, A IF ID EXE MEM WB add R1, R2, R3 IF ID EXE MEM WB sub R4, R4, R5 IF ID EXE MEM WB xor R6, R2, R3 IF ID EXE MEM WB... B SUB R4,R4,R5 ADD R1,R2,R3 LOAD R0, A IF ID EXE MEM WB Clock (a) Ciclo k+3: o fetch da instrução xor não pode ser feito, uma vez que a instrução load acede à memória. XOR R6,R2,R3 B SUB R4,R4,R5 ADD R1,R2,R3 LOAD R0, A IF ID EXE MEM WB Clock (b) Ciclo k+4: após se ter imposto um atraso com a bolha, o conflito estrutural entre xor e load foi resolvido. Figura 10 Introdução de uma bolha para resolução de um conflito estrutural. ISCTE-IUL - DCTI 13

14 Em teoria, podem também existir conflitos estruturais no caso de haverem várias etapas de WB ao longo do pipeline, ou então várias etapas em que é possível aceder à memória. No primeiro caso não poderiam ser feitas escritas em simultâneo no mesmo registo; para o segundo caso, poderiam também acontecer conflitos entre instruções do tipo load / store. Quando se utiliza um espaço de endereçamento comum para dados e instruções (que é o que se passa nos processadores actuais), pode-se minimizar a introdução de bolhas devido a conflitos deste género, utilizando uma das seguintes técnicas: Caches separadas para dados e instruções apesar de haver um espaço de endereçamento comum para dados e instruções, colocando caches de primeiro nível separadas para instruções e para dados faz com que a maioria dos acessos à memória sejam efectivamente acessos a cada uma dessas caches. Deste modo, desde que não ocorram cache misses em simultâneo nas duas caches, não ocorrem conflitos estruturais devido ao acesso à memória. Pre-fetch de instruções outra possibilidade é, sempre que possível, ir carregando várias instruções para uma fila de espera (buffer) dentro do processador. Esse carregamento é feito aproveitando-se os instantes em que os barramentos CPU-memória estão desocupados. Caso se consigam manter sempre instruções nessa fila de espera, então a fase de fetch só acede ao buffer, evitando-se assim os conflitos estruturais. Mas note que não existe nenhuma técnica que consiga resolver a totalidade dos conflitos deste género, a não ser utilizar memória de programa e dados em separado, o que é desvantajoso para a gestão do espaço de endereçamento. Por outras palavras, as técnicas mencionadas diminuem (e em muito) a probabilidade de ocorrência dos conflitos, mas essa probabilidade não é nula Conflitos de controlo O último tipo de conflitos são os chamados conflitos de controlo. Este tipo de conflitos ocorre quando aparecem instruções que causem uma alteração na ordem sequencial no processamento das instruções de um programa. Exemplos de instruções deste género são as instruções de salto. Relembre que uma instrução de salto faz (ou pode fazer) com que a próxima instrução a executar não seja a que se encontra na posição PC+1, mas sim a que se encontra no endereço de destino do salto, alterando-se assim o fluxo sequencial do programa. Para compreender melhor o que se passa numa situação de conflito deste tipo, considere-se o seguinte fragmento de código: LBL1: inc R2... store A, R0 jump LBL1 load R1, A... Quando é iniciado o processamento da instrução de salto jump LBL1, vai em primeiro lugar ser feita a etapa de fetch (IF) dessa instrução. No final da fase IF, o processador ainda desconhece o ISCTE-IUL - DCTI 14

15 tipo de instrução foi lida da memória, pois o seu opcode só é analisado na etapa ID. Quer isto dizer que, no próximo ciclo de relógio a instrução jump passa para a fase de ID, mas entretanto o pipeline começa a fazer o fetch da instrução que está na posição de memória que se segue à da instrução de salto, neste exemplo a instrução load. Resumindo, a instrução load entra erradamente no pipeline, quando o correcto seria entrar a instrução inc, pois o salto faz com que seja essa a próxima a processar. Entretanto, quando a instrução jump chega à fase de ID, o processador descobre que esta é uma instrução de salto incondicional. Se houver uma forma de actualizar o valor de PC ainda nesse ciclo, então a próxima instrução que entra no pipeline é a instrução inc. Mas note que como entretanto entrou o load, esta terá que ser transformada numa bolha. A sequência de acções que foi descrita encontra-se sistematizada na seguinte tabela: Instrução Ciclo k k+1 k+2 k+3 k+4 k+5 k+6 k+7 k+8... store A, R0 IF ID EXE MEM WB jump LBL1 IF ID EXE MEM WB load R1, A IF inc R2 IF ID EXE MEM WB... Outra forma de ver é através dos seguintes esquemas: JUMP LBL1 STORE A, R0 IF ID EXE MEM WB Clock (a) Ciclo k+1: está a ser feito o fetch da instrução jump. LOAD R1, A JUMP LBL1 STORE A, R0 IF ID EXE MEM WB Clock (b) Ciclo k+2: na fase ID, o processador descobre que entrou a instrução jump, mas entretanto já está ser feito o fetch da instrução load. INC R2 B JUMP LBL1 STORE A, R0 IF ID EXE MEM WB Clock c) Ciclo k+3: assumindo que há hardware para tal, o program counter foi actualizado com o destino do salto, entrando agora a instrução correcta. A instrução que entrou erradamente (load) foi transformada numa bolha. Figura 11 Introdução de uma bolha para resolução de um conflito de controlo. ISCTE-IUL - DCTI 15

16 No exemplo que foi visto, o salto é incondicional e admitiu-se que seria possível concretizar o salto assim que o processador descobrisse que de facto se estava a processar uma condição de salto. Uma situação mais complicada pode acontecer se entrar no pipeline uma instrução de salto condicional. Nesse caso, para além do processador ter que descobrir que se trata de uma instrução de salto, é ainda necessária a verificação da condição de salto, cujo resultado conduz a efectivar o salto ou não. No esquema da arquitectura do pipeline, está-se a assumir que as condições de salto são testadas na fase EXE. Quer isto dizer que, no caso de um salto condicional que vai ser tomado, vão entrar erradamente duas instruções no pipeline (as que se situam nas posições de memória que se seguem à da instrução de salto). Quando a condição de salto é verificada, já está uma instrução (a seguinte) na fase ID e uma outra já está na fase IF. Para minimizar o efeito dos atrasos causados pelos conflitos de controlo, as técnicas mais frequentes são as seguintes: Branch delay slot esta é uma técnica de software. Como entram no pipeline as instruções que estão nas posições de memória que se seguem à da instrução de salto, pode-se aproveitar esse facto e reorganizar o código do programa de maneira a mudar a posição de instruções que façam processamento útil para as posições que se seguem à instrução de salto. No caso de não se encontrarem instruções nessas condições, usam-se instruções do tipo nop (no operation) nessas posições que se seguem à da instrução de salto. Previsão de saltos (Branch prediction) nos saltos condicionais, uma forma de minimizar a introdução de bolhas devido à espera pela verificação da condição de salto, é o processador fazer assunções sobre se o salto vai ser tomado ou não. Estas assunções designam-se geralmente por predict taken e predict not-taken, respectivamente. O predictor de saltos basicamente tenta adivinhar se o salto vai ser tomado ou não caso o predictor esteja correcto, evita-se a introdução das bolhas que seriam necessárias até que se verificasse a condição de salto; no caso do predictor se enganar, então aí é necessário anular as acções que entretanto foram feitas pelas instruções que entraram erradamente no pipeline e introduzir as bolhas respectivas. Entre estas duas técnicas, nos dias que correm a previsão de saltos é provavelmente a mais popular, principalmente em processadores cujos pipelines têm um elevado número de etapas. ISCTE-IUL - DCTI 16

17 4. Desempenho Na secção 2 foi visto que o ganho de desempenho, em termos teóricos e ideais, de um processador em pipeline face a uma versão sem pipeline é igual ao número de etapas. No entanto, para se atingir este valor ideal seria necessário reunir as seguintes condições: Todas as etapas terem o mesmo tempo de propagação; Os registos que separam as etapas terem um tempo de carregamento nulo; O pipeline ter sempre todas as etapas ocupadas ou seja, nunca ser necessária a introdução de bolhas ou nops. Se não for possível que todas as etapas tenham o mesmo tempo de propagação, a frequência do sinal de relógio irá ser limitada pela duração da etapa que demora mais tempo. Por exemplo, assumindo que os tempos das várias etapas são os seguintes: IF 8 ns; ID 6 ns; EXE 10 ns; MEM 10 ns; WB 6 ns, o período do sinal de relógio seria limitado pelo tempo da etapa EXE ou da etapa MEM (10 ns). A frequência máxima de funcionamento em pipeline seria 1/10 ns = 100 MHz. Numa versão sem pipeline, o período de funcionamento seria de = 40 ns, ao que corresponderia uma frequência de 25 MHz. Idealmente, o ganho seria 5, pois o pipeline é composto por 5 etapas. No entanto, utilizando os dados obtidos nos parágrafos anteriores, chega-se a um ganho real de 40 ns / 10 ns = 4 (ou, se preferir, 100 MHz / 25 MHz = 4). Por outras palavras, passou-se de um ganho ideal de 5, para um ganho real de 4. A única forma de colmatar estas diferenças de tempos de propagação associados a cada etapa é fazer uma divisão mais equilibrada do pipeline, o que eventualmente conduz ao desdobramento de etapas (por exemplo, dividir as etapas EXE e MEM em duas etapas mais curtas EXE1/EXE2 e MEM1/MEM2, de modo a ter um maior equilíbrio). No entanto, o desdobramento de etapas conduz a que seja necessária a introdução de um maior número de bolhas para resolver os conflitos, um factor prejudicial que é preciso ter conta. Outro aspecto não ideal é o facto dos registos que separam as etapas não terem tempos de preparação e propagação nulos, o que também faz com que a duração de cada ciclo do sinal de relógio tenha que ser maior. Se esses tempos não forem desprezáveis, mesmo que todas as etapas demorassem o mesmo tempo T etapa o ganho desvia-se do seu valor ideal. Supondo que os registos têm um tempo de preparação T setup e um tempo de propagação T PD não nulos, então o ganho é dado por: T G= T s / pipeline c / pipeline = T etapa etapas + T T setup etapa + T PD = Tsetup 1+ T etapas + T etapa PD ISCTE-IUL - DCTI 17

18 A expressão evidencia que o ganho depende também da relação entre os tempos associados ao carregamento dos registos e a duração de cada etapa. Quanto mais pequeno esse rácio (i.e., à medida que T setup + T PD << T etapa ) menor a influência no valor do ganho ideal. Para concluir, é necessário ter em a conta a introdução de bolhas. A introdução de bolhas tem uma influência directa no CPI do processador, cujo valor ideal é 1. Assumindo que, em média, por cada instrução é necessária a introdução de B bolhas, o valor do CPI passa a ser de 1+B. Nessas condições, e mantendo os restantes factores ideais (etapas equilibradas e desprezando os tempos de carregamento dos registos) o ganho do processador em pipeline é: etapas G=. 1 + B O número de bolhas que são necessárias introduzir depende de diversos factores. O mais importante desses factores é possivelmente o comprimento (em etapas) do pipeline. Em geral o número de bolhas que têm que ser inseridas cresce à medida que o número de etapas aumenta. ISCTE-IUL - DCTI 18

19 5. Bibliografia 1. Arquitectura de computadores: dos sistemas digitais aos microprocessadores 2ª edição, Guilherme Arroz, José Monteiro e Arlindo Oliveira, Computer organization and design: the hardware/software interface 4 th edition, David Patterson & John Hennessy, Morgan Kaufmann, Logic and computer design fundamentals 4 th edition, Morris Mano & Charles Kime, Prentice-Hall, Computer architecture: a quantitative approach, 3 rd edition, John Hennessy, David Patterson, Morgan Kaufmann, Computer organization, 5 th edition, Carl Zamacher, Zvonko Vranesic, Safwat Zaky, McGraw Hill, Structured computer organization, 4 th edition, Andrew Tanenbaum, Prentice-Hall International, ISCTE-IUL - DCTI 19

20 6. Lista de revisões Versão Autor Data Comentários 0.01 Tomás Brandão Maio / 2010 Versão inicial; Publicação antecipada para as avaliações 2009/ Tomás Brandão Junho / 2010 Correcção de gralhas e reformulação de texto sobre desempenho agradecimento à aluna Vanda Grácio. ISCTE-IUL - DCTI 20