Métodos de estimativa de desempenho em software embarcado

Tamanho: px
Começar a partir da página:

Download "Métodos de estimativa de desempenho em software embarcado"

Transcrição

1 UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL INSTITUTO DE INFORMÁTICA PROGRAMA DE PÓS-GRADUAÇÃO EM COMPUTAÇÃO MARCIO SEIJI OYAMADA Métodos de estimativa de desempenho em software embarcado Trabalho Individual I TI Prof. Dr. Flávio Rech Wagner Orientador Porto Alegre, março de 2004

2 SUMÁRIO LISTA DE ABREVIATURAS E SIGLAS LISTA DE FIGURAS RESUMO ABSTRACT INTRODUÇÃO ANÁLISE DO FLUXO DE CONTROLE Análise dinâmica do fluxo de controle Análise estática do fluxo de controle TEMPO DE EXECUÇÃO Pipeline Predição de desvios Cache Portabilidade CONCLUSÃO REFERÊNCIAS

3 LISTA DE ABREVIATURAS E SIGLAS ASIC ASIP IP HW SOC SW SO WCET Application-specific Integrated Circuit Application-specific Instruction-Set Processor Intelectual property Hardware System-on-chip Software Sistema Operacional Worst-case execution time

4 LISTA DE FIGURAS Figura 1.1: Fases do processo de WCET Figura 2.1: Exemplos de blocos básicos Figura 2.2: Exemplo de análise dinâmica utilizando a ferramenta gcov Figura 2.3: Programa exemplo Figura 2.4: Programa exemplo dividido em blocos básicos Figura 2.5: Código com restrições funcionais Figura 2.6: (a) Código da aplicação e (b) grafo do fluxo de controle com escopos (ENGBLOM; ERMEDAHL; STAPPERT, 2001a) Figura 3.1: Figura 3.2: Figura 3.3: Figura 3.4: Figura 3.5: Figura 3.6: Figura 3.7: Tempo de execução das instruções (a), e os efeitos do pipeline (b) (ENGBLOM; JONSSON, 2002) Efeito positivo do pipeline no tempo de execução (ENGBLOM; JONS- SON, 2002) Grafo de fluxo de controle anotado com os fatos de execução (a), e após a análise do pipeline (b) (ENGBLOM; ERMEDAHL; STAP- PERT, 2001a) Modelo abstrato de pipeline proposto por Hergenhan (HERGENHAN; ROSENSTIEL, 2000) Grafo de instruções com as dependências de dados, funcionais e de ordem (b), juntamente com o grafo reduzido (c) (LIM et al., 1998). 23 Grafo de fluxo de controle e o mapeamento para cache proposto por Li (LI; MALIK; WOLFE, 1995) Grafo de fluxo de controle (a), com o grafo de controle de cache (b) e o grafo alterado considerando o miss cache (LI; MITRA; ROY- CHOUDHURY, 2003)

5 RESUMO Este trabalho apresenta uma análise sobre propostas para a determinação do tempo de execução no pior caso. O enfoque é dado principalmente para ferramentas que possibilitam a análise estática do código. São apresentadas as técnicas para detecção do fluxo de controle determinando assim os blocos básicos executados. Após esta primeira análise, são apresentadas as técnicas utilizadas para cálculo do tempo de execução de cada bloco básico em especial em processadores com pipelines, caches entre outros recursos avançados em processadores. Palavras-chave: Estimativa do tempo de execução no pior caso, Sistemas Embarcados, Sistemas de Tempo Real.

6 ABSTRACT This work presents the analysis of the Worst Case Execution Time(WCET) techniques. The WCET tools mainly based on static analysis are analyzed. The techniques to control flow extraction and basic blocks execution counts are presented. After this, we present the techniques for the execution time determination of each basic block on processors with pipelines, caches and another advanced features. Keywords: Worst case execution time, Embedded Systems, Real-Time Systems.

7 7 1 INTRODUÇÃO Atualmente sistemas eletrônicos embarcados são encontrados em diversos produtos nos setores de telecomunicações, automotivo, aviação, entretenimento entre outros. Tais produtos necessitam de um projeto rápido e de baixo custo para manter a competitividade junto ao mercado. Sistemas embarcados são responsáveis por tarefas simples como o controle de um forno microondas, que pode ser solucionado através da utilização de um microcontrolador, microprocessador ou processador digital de sinais e um software associado. Porém em alguns casos, sistemas embarcados são responsáveis por tarefas complexas e com restrições de tempo e consumo, onde um dispositivo de prateleira não é suficiente para cobrir estes requisitos, necessitando de um projeto dedicado. Sistemas eletrônicos embarcados complexos podem ser compostos de diversos componentes. Uma solução integrada em um SoC (System on chip) pode ser utilizada. O SoC pode ser composto por uma plataforma multiprocessada (inclusive com processadores de diferentes arquiteturas), juntamente com elementos de aplicação específica como ASICs e/ou ASIP. A solução proposta pode envolver ainda a utilização de um Sistema Operacional(SO) a fim de prover de uma forma mais adequada e eficiente a utilização do processador. Devido a heterogeneidade de um SoC ferramentas para projeto no nível de sistema devem ser desenvolvidas com o objetivo de obter uma forma mais adequada de especificação, simulação e síntese de tais sistemas. Além disso, o ambiente deve prover a possibilidade da utilização de componentes IP (intellectual property), facilitando o reuso de componentes diminuindo assim os erros e o tempo de projeto. A utilização de plataformas (KEUTZER et al., 2000) acelera o tempo de desenvolvimento através do seu compartilhamento em diversos produtos. Desta forma, o problema do projeto de um Sistema Embarcado concentra-se principalmente no desenvolvimento do software. Mesmo com a utilização de plataformas, devido ao grande número de combinações possíveis, é necessária a avaliação do maior número de soluções para encontrar a melhor dentro dos requisitos especificados pelo projeto. A etapa de exploração do projeto deve ser realizada de forma eficiente para que o tempo gasto na avaliação seja aceitável e a estimativa de desempenho seja efetivamente conseguida na implementação do produto. A estimativa do tempo de execução no pior caso(em inglês WCET 1 ) teve seu desenvolvimento juntamente com a área de sistemas de tempo real, mais especificamente com a teoria do escalonamento, desenvolvida inicialmente na década de 80 (PUSCHNER; BURNS, 2000). O teste de escalonabilidade determina se um dado conjunto de tarefas T, cada qual representada por uma tupla {D, P, E} representando o deadline, período e tempo de execução respectivamente, pode ser executado com as restrições temporais sendo obe- 1 Worst Case Execution Time

8 8 decidas em uma dada política de escalonamento. O WCET é utilizado para determinar o tempo de execução (E) de uma dada tarefa. Os requisitos temporais da aplicação são então validados em duas fases. Inicialmente o WCET de cada tarefa é calculado e, após, o teste de escalonabilidade é realizado. Muitos dos recursos microarquiteturais como caches são considerados através da inclusão do custo de recarga da cache ao tempo de preempção. Schneider (SCHNEIDER, 2002) afirma que obter o WCET em duas fases, considerando o Sistema Operacional (SO) como um componente separado da aplicação, é altamente impreciso devido aos seguintes fatores: Parâmetros de chamadas de função: qualquer serviço onde o fluxo de controle dependa dos parâmetros; Parâmetros de configuração dependentes da aplicação: qualquer serviço onde os laços dependam de parâmetros estáticos tais como o número de tarefas; Estado da cache: o efeito no estado da cache pela execução da aplicação e do SO; Histórico de chamadas ao SO: poderão ser consideradas situações como execução de chamadas que desabilitam preempções; Contexto de uma chamada: muitas chamadas do SO tem caminhos específicos se chamados a partir do manipulador de interrupções ou de um processo. Desta forma Schneider considera que é necessário um novo paradigma para construção de ferramentas onde framework possa integrar as atividades de WCET e escalonabilidade de forma que os aspectos relativos as duas camadas possam ser consideradas. Além do teste de escalonabilidade, o cálculo do WCET também pode ser utilizado para auxiliar na etapa de exploração de soluções, uma vez que é necessário avaliar rapidamente o desempenho de uma dada aplicação em diversas arquiteturas. Nicolescu (NICOLESCU et al., 2002), utiliza o WCET para determinar o tempo de execução de chamadas do Sistema Operacional. A estimativa é utilizada como forma de aumentar a velocidade de simulação, podendo o código ser executado na máquina hospedeira e os devidos atrasos anotados em cada função do Sistema Operacional. Alguns trabalhos recentes propõem a determinação do WCET em modelos descritos em linguagens com alto nível de abstração, tais como Matlab (KIRNER; LANG; PUSCHNER, 2001) e Redes de Petri (STAPPERT; RUST, 2003). Estes modelos são traduzidos para alguma linguagem de programação (por exemplo C), sendo então realizada a estimativa de desempenho. A determinação do WCET pode ser realizada através da execução da tarefa na plataforma alvo. A execução da aplicação diretamente na plataforma alvo implica ainda na sua disponibilidade e também em formas de obter o tempo de execução isolando-se outros fatores que possam influir na sua determinação (por exemplo o Sistema Operacional e outras tarefas em execução no sistema). Um forma tradicionalmente adotada é a utilização de simuladores ciclo-a-ciclo, sendo possível obter um ambiente mais controlado para determinação do tempo de execução. Para tarefas simples, tal técnica pode ser aplicada sem problemas, porém devido a complexidade crescente das aplicações a determinação das entradas que implicam no pior caso de execução pode ser uma tarefa difícil e custosa. O desafio da estimativa de desempenho é sempre tentar obter valores muito próximos ao tempo exato de execução. Subestimar o tempo de execução torna-se altamente perigoso, onde a solução pode ocasionalmente não atender aos requisitos temporais da

9 9 aplicação, visto que o escalonamento é todo baseado na estimativa. Superestimar não acarreta problemas temporais, porém faz com que recursos sejam desperdiçados. Uma outra solução é a utilização de análise estática para determinação dos possíveis fluxos de execução de uma tarefa. A partir dos fluxos caracterizados e dos custos associados a cada bloco básico é possível determinar o pior caso de execução como apresentado na equação 1.1 onde c i é o número de execuções e x i o tempo de execução de um bloco básico i (LI; MALIK, 1995). N T empo total = c i x i (1.1) n=0 Desta forma o cálculo do WCET pode ser realizado em duas fases: determinação dos possíveis caminhos de uma tarefa e o tempo de execução de cada bloco básico. Engblom (ENGBLOM; ERMEDAHL; STAPPERT, 2001b) divide o cálculo do tempo de execução de um bloco básico em dois níveis: fatores globais tais como caches e fatores locais tais como pipeline e tempo de acesso a memória. Figura 1.1: Fases do processo de WCET A Figura 1.1 apresenta a divisão do processo de cálculo do WCET em duas fases. Na primeira fase o fluxo de controle entre os blocos básicos é determinado. Após isso, o tempo de execução de cada bloco básico deve ser calculado através de algum método como o uso de dados estatísticos, simuladores ou do manual do processador(datasheet). Engblom (ENGBLOM, 1999) apresenta um estudo de 13 aplicações diferentes em Sistemas Embarcados nos domínios de telecomunicações, controle automotivo e eletrônica de consumo com ênfase nas propriedadades para análise estática. As aplicações reais foram obtidas de seis companhias, sendo os nomes da companhias não divulgadas pelo autor. As análises levaram em consideração os seguintes parâmetros: chamadas recursivas: o estudo mostrou que apenas 18 funções eram recursivas em relação às 5579 funções analisadas; grafos de controle desestruturados: normalmente estes grafos são originários de desvios dentro do corpo do laço. Apenas 18 grafos desestruturados foram encontrados sendo a maioria deles originárias de sistemas de geração automática de código (principalmente aqueles relacionados a protocolos);

10 10 laços aninhados: 90% dos laços continham somente 1 nível de profundidade. No estudo não foram considerados os laços existentes dentro de funções que são chamadas a partir de laços; complexidade do corpo do laço: a complexidade foi considerada como a quantidade de blocos básicos no laço mais interno. O estudo mostra que 90% dos laços contém no máximo 10 blocos básicos; funções sem finalização: tais funções são muito comuns em sistemas embarcados pois normalmente a tarefa executa enquanto o sistema estiver em uso. O estudo apresenta que 44 funções não eram finalizadas; chamadas de função: tais funções foram classificadas em funções externas (funções em outros arquivos fonte), chamadas a ponteiros de função (o ponteiro é resolvido durante a execução do programa), chamadas a função no mesmo arquivo, chamadas de funções intrínsecas (funções que são substituídas normalmente por código assembler inline) e chamadas a funções de bibliotecas (tais como printf). O estudo mostrou que em algumas aplicações até 30% das chamadas são através de ponteiros de função. O estudo mostra também que, em média 50% das chamadas são realizadas para funções externas que estão descritas em arquivos fonte separados; complexidade das funções: o estudo classificou as instruções nos níveis triviais (sem laços ou estruturas de controle), sem laços (com estruturas de controle) e com laços. Em média 30% das funções eram triviais sendo que apenas 20% das funções eram complexas, ou seja compostas por laços e estruturas de decisão; profundidade das estruturas de decisão: a profundidade das estruturas de decisão (comandos do tipo if), em 90% dos casos são compostas por no máximo 4 níveis; tipos das variáveis: nos programas analisados 55,97% das variáveis eram do tipo inteiro, 22,08% ponteiros para variáveis, 11,8% arrays, 9,88% estruturas e o restante divididos em ponteiros para função e variáveis de ponto flutuante. O estudo mostra que existem nas aplicações embarcadas algumas características que devem ser necessariamente consideradas em ferramentas de cálculo do WCET. É possível notar que uma grande quantidade de aplicações são compostas por chamadas de funções externas, que deverão ser suportadas através da análise de múltiplos arquivos de código fonte. Além disso, ponteiros tanto de dados quanto de funções são muito comuns em aplicações embarcadas devendo ser tratados adequadamente. Em relação ao grafo de controle é importante notar que existe várias aplicações com laços e estruturas de decisão aninhados, sendo necessário o suporte para que vários níveis possam ser considerados. Quanto as aplicações, a ferramenta deve ter suporte para análise de funções sem finalização muito comum em sistemas embarcados, sendo que a mesma deve detectar e estimar o tempo de cada ativação da tarefa que é o dado de interesse para o teste de escalonabilidade. Este trabalho apresenta as técnicas utilizadas em cada fase do cálculo do WCET. No Capítulo 2 as técnicas para análise do fluxo de controle são apresentadas, no Capítulo 3 são analisadas as técnicas para calcular o tempo de execução em processadores com recursos avançados tais como pipeline, caches e predição de desvios. Uma análise sobre a portabilidade das técnicas apresentadas é realizada. No Capítulo 4 é apresentada a conclusão.

11 11 2 ANÁLISE DO FLUXO DE CONTROLE Este capítulo analisará as diversas técnicas para determinação do fluxo de controle de uma tarefa. O objetivo desta fase é determinar quais blocos básicos da tarefa são executadas no pior caso. Para uma aplicação com um filtro FIR, o código tem somente um único fluxo de execução o que torna a tarefa de extração do grafo de controle de fluxo simplificada. Porém, em outros casos as entradas tem influência direta nos diferentes caminhos que um determinado programa pode executar, necessitando de uma análise para verificar quais os caminhos serão executados. Normalmente esta análise é baseada na divisão da tarefa em blocos básicos. Um bloco básico é conjunto de instruções contendo somente um fluxo de entrada e um fluxo de saída (AHO; SETHI; ULLMAN, 2000). Figura 2.1: Exemplos de blocos básicos A figura 2.1 apresenta alguns exemplos de blocos básicos em um programa descrito em C. Um laço do comando for representa um bloco básico onde todo o seu conteúdo é executado a cada vez que o fluxo de execução entra no laço. Como conseqüência direta o bloco básico pode ser composto de vários blocos básicos. 2.1 Análise dinâmica do fluxo de controle Uma forma de determinação do fluxo de controle é através da execução da tarefa e anotando, em algum formato específico, os blocos básicos executados. A execução não necessita ser realizada na plataforma alvo visto que o objetivo é apenas determinar quais blocos básicos são executados. Ferramentas de profiling podem ser utilizadas para

12 12 Figura 2.2: Exemplo de análise dinâmica utilizando a ferramenta gcov realizar a contagem das execuções dos blocos básicos. Um exemplo de tal ferramenta é o gcov (GNU, 2003a), sendo a contagem do número de execuções de cada instrução apresentada do lado esquerdo da Figura 2.2. Brandolese e Giusto (BRANDOLESE et al., 2001; GIUSTO; MARTIN; HARCOURT, 2001) utilizam esta técnica para determinar os blocos básicos executados. O problema principal desta técnica é determinar quais entradas implicam no pior caso de execução. Devido a complexidade crescente das tarefas a serem analisadas tal atividade passa a ser proibitiva e insegura. Lundqvist (LUNDQVIST; STENSTRÖM, 1999) apresenta um método para determinação do fluxo de controle através da simulação simbólica da aplicação. A simulação simbólica é realizada utilizando-se um simulador ciclo-a-ciclo do processador alvo, e a adoção de um novo tipo de dado denominado "desconhecido". As operações com esse valor são tratadas de forma especial pelo simulador. Por exemplo, considere uma instrução de desvio if seja dependente de uma variável contendo valor "desconhecido". Neste caso, ambos os caminhos são executados com o objetivo de se obter qual fluxo resulta no

13 13 pior caso. Na simulação simbólica, as condições que dependem de valores conhecidos estaticamente poderão ser computados durante a simulação, bem como aqueles inalcançáveis poderão ser excluídos da análise. Como a simulação simbólica executa todos os caminhos possíveis, o método torna-se proibitivo em grandes códigos e em laços com vários caminhos disponíveis. Os autores propõem um método para diminuir os custos em laços com vários caminhos possíveis da seguinte forma: após a análise da primeira execução do laço, o método detecta qual o caminho mais longo e utiliza este como sendo o pior caso nas iterações subseqüentes. O método integra a análise do fluxo de controle juntamente com o cálculo do tempo de execução da aplicação através da utilização de um simulador ciclo-a-ciclo, que pode considerar todos os recursos avançados de um processador tais como pipeline, caches, superscalaridade entre outros. 2.2 Análise estática do fluxo de controle A análise do fluxo de execução pode ser realizada estaticamente, analisando-se o código fonte dividindo-o em blocos básicos e determinado os possíveis caminhos que um dado programa pode executar. Uma das primeiras propostas para determinar o fluxo de controle de um programa foi utilizando anotações no código (PUSCHNER; KOZA, 1989; PARK; SHAW, 1991; BERNAT; BURNS; WELLINGS, 2000). Tais anotações descrevem, por exemplo, limites de laços e auxiliam a ferramenta a descobrir o fluxo de controle que fornece o pior caso. Li (LI; MALIK, 1995) realiza a análise estática através de uma técnica denominada enumeração implícita de caminhos, determinando o número de execuções de cada bloco básico para o melhor e o pior caso. Estes limites são calculados através de equações lineares derivadas da análise das restrições estruturais e funcionais. As restrições estruturais são geradas a partir da análise do grafo de controle. As restrições funcionais, por sua vez, são fornecidas pelo usuário e descrevem informações que não podem ser obtidas através da análise do grafo de controle, como limites de laços e falsos caminhos. Com os custos associados de cada bloco básico, a equação 1.1 pode ser aplicada e o tempo de execução calculado. A Figura 2.3 apresenta o código em linguagem C de um algoritmo exemplo e seu respectivo grafo de controle na Figura 2.4. As equações 2.1 a 2.5 apresentam algumas restrições estruturais e funcionais. A equação 2.1 representa uma restrição funcional, onde o usuário descreve o valor máximo de n (no exemplo o valor é 100). Baseado nestas equações e com os custos associados de cada bloco básico uma técnica como a programação linear inteira pode ser utilizada para encontrar o WCET. d1 <= 100 (2.1) d3 <= d1 (2.2) d4 <= d1 (2.3) d3 + d4 <= d1 (2.4) x1 = x2 + x3 (2.5) É importante notar que o cálculo do WCET pode ser extremamente pessimista caso as restrições funcionais forem definidas de forma imprecisa. Um conhecimento extra do programador pode ser necessário para que o WCET seja o mais preciso possível. A

14 14 Figura 2.3: Programa exemplo Figura 2.4: Programa exemplo dividido em blocos básicos

15 15 Figura 2.5 apresenta um código onde um conhecimento do programador pode indicar que o código if é executado uma única vez. Caso o código if tivesse um custo muito maior que o código descrito no bloco básico else, uma estimativa altamente pessimista seria retornada pela ferramenta. Figura 2.5: Código com restrições funcionais Engblom (ENGBLOM; ERMEDAHL; STAPPERT, 2001a) apresenta uma extensão para o método de equações lineares através da utilização de fatos. Fatos são anotações incluídas pelo usuário que auxiliam na detecção do caminho no pior caso. Figura 2.6: (a) Código da aplicação e (b) grafo do fluxo de controle com escopos (ENG- BLOM; ERMEDAHL; STAPPERT, 2001a) A figura 2.6 apresenta um grafo do fluxo de controle com alguns fatos anotados. Inicialmente, o programa é dividido em escopos. Na figura são apresentados dois escopos chamados de outer e inner. Em cada escopo, um conjunto de fatos pode descrever explicitamente as restrições funcionais, sendo que estas podem ser totais (denotadas por []),

16 16 nos quais o fato é considerado como a soma de todas as iterações, ou locais (denotadas por <>), no qual o fato é inicializado a cada iteração do escopo. Por exemplo o fato outer :< 1..5 >: x I = 1 indica que o bloco básico I é necessariamente executado uma vez nas iterações de 1 a 5. Por outro lado, o fato outer : [] : x B 55 indica que o bloco básico B executará no máximo que 55 vezes em todas as execuções do escopo outer. O uso de fatos com escopo aumenta em muito o poder de especificação de restrições no fluxo de controle. Porém, tal paradigma é altamente dependente do conhecimento do programador. Wolf (WOLF; ERNST, 2000) apresenta uma forma de detectar se um determinado programa tem um único fluxo de execução. Programas como filtros e FFT contém grandes trechos com somente um único caminho, facilitando a análise. Desta forma, o WCET pode ser calculado sem a influência de falsos caminhos que podem aumentar a imprecisão da estimativa. O método é baseado na identificação de grandes seqüências de blocos básicos que são independentes de dados de entrada, denominados segmentos com único fluxo de execução. Para trechos de código com múltiplos caminhos, uma simulação local é realizada e os limites de laços determinados através do método de equações lineares. Os autores consideram a análise baseada em segmentos mais adequada, uma vez que fatores como cache e pipeline tem uma precisão maior quando analisados em grandes trechos do que no nível de blocos básicos. Os autores apresentam os resultados das estimativas utilizando blocos básicos e segmentos, sendo esta última opção a que apresenta precisão muito próxima do tempo exato de execução (erros em média de 20%). Healy (HEALY et al., 2000) apresenta um método para determinar automaticamente os valores mínimos e máximos de iterações de laços em um programa. O método consiste em derivar, para cada instrução de desvio, as seguintes informações: variable: a variável de controle no qual o desvio depende; limit: o valor inicialmente comparado com a variável de controle do laço; relop: o operador relacional utilizado para comparar a variável e o limite; initial: o valor da variável quando o laço é iniciado; before: a quantidade que a variável é alterada até retornar novamente a instrução de desvio; after: a quantidade que a variável é alterada após a instrução de desvio; adjust: o valor de ajuste que compensa a diferença entre os operadores relacionais (< ou ); Um laço é classificado como "conhecido"caso todos os parâmetros apresentados acima são definidos. Desta forma a equação 2.6 pode ser utilizada para calcular o número de iterações até que o desvio mude de direção. limiti (initial i + before i ) + adjust i N i = + 2 (2.6) before i + after i Os autores apresentam outras formas para determinar o número de iterações quando alguns dos parâmetros são desconhecidos (através da interação com o usuário por exemplo), detecção de laços sem limites, ou limites desconhecidos. Além disso, um método

17 para determinar laços aninhados é apresentado. Os autores apresentam resultados em um conjunto de benchmarks apresentando que o método pode determinar de forma precisa a quantidade de iterações em um laço mesmo estes sendo aninhados( erros entre 0% a 17%). 17

18 18 3 TEMPO DE EXECUÇÃO Dado um conjunto de blocos básicos e suas instruções é necessário estimar o tempo de execução. Tal estimativa pode ser realizada através de três técnicas principais: simulação, datasheet ou dados estatísticos. Simuladores ciclo-a-ciclo tem sido utilizados de forma intensiva por vários trabalhos da área. A principal vantagem está na precisão, pois o simulador pode considerar características da arquitetura tais como pipeline, caches, entre outros. A principal desvantagem deste método é a necessidade da existência de simulador ciclo-a-ciclo e também seu baixo desempenho na análise de grandes aplicações. O manual do processor (datasheet), contendo o número de ciclos necessários para executar uma dada instrução, pode ser utilizado para o cálculo do tempo de execução. Após a contagem das instruções, o cálculo do tempo de execução pode ser realizado consultando o datasheet do processador. Este é o método mais simples possível e pode ser aplicado para processadores sem qualquer otimização que altere o número de ciclos gastos por uma instrução ou conjunto de instruções tais como pipeline e caches. Para processadores com tais recursos o método torna-se altamente impreciso. Giusto (GIUSTO; MARTIN; HARCOURT, 2001) realiza a estimativa através da tradução do código da aplicação em um conjunto de instruções virtual. Este conjunto de instruções é composto por 25 instruções (um conjunto RISC simplificado), sendo que a estimativa é realizada determinando-se o custo da execução das instruções virtuais na arquitetura alvo. Após isso, a equação 3.1 pode ser utilizada para calcular o tempo de execução, onde P i é o número de ciclos de consumidos pela instrução do tipo i, e N i o número de instruções que aparecem ao longo do código e K uma constante. Cycles = K + i P i N i (3.1) Cycles = LD LI 30.4 ST 3.1 OP i IF 5.1 GOT O 51.5 SUB (3.2) Giusto utiliza um conjunto de tarefas e um simulador ciclo-a-ciclo para determinar o custo de execução de cada instrução virtual. Após isso, uma análise estatística (utilizandose os métodos dos mínimos quadrados e regressão linear) é realizada sobre os dados para determinar os índices P i da equação 3.1. A equação 3.2 é um exemplo de equação obtida através da análise de 35 benchmarks do softwares relacionados ao domínio automotivo, onde LD representam as operações de LOAD, LI= load immediate, ST= operações store, GOTO= desvio incondicional, IF= desvios condicionais, OP= operações aritméticas, SUB= chamadas de função.

19 19 Para determinar as instruções executadas uma análise dinâmica é realizada na aplicação. Giusto em seus resultados, mostra que o conjunto de tarefas utilizado para determinar os custos é importante para a precisão da estimativa. Enquanto que para tarefas com mesmas características a estimativa acarreta erros entre -12% e 5%, o mesmo pode subir acima de 180% com o conjunto de tarefas sem relação com a aplicação analisada. Bontempi (BONTEMPI; KRUIJTZER, 2002) utiliza um método para estimar o número de ciclos baseado na análise de dados de entrada da aplicação. Inicialmente um conjunto de benchmarks é escolhido e executado com diferentes entradas utilizando um simulador ciclo-a-ciclo, extraindo-se um vetor s contendo quais instruções aparecem no código e o número de vezes. Desta forma, um conjunto de observação é construido mapeando o vetor s com o número de ciclos consumidos. O método consiste em determinar uma função c = f(s) onde s é o vetor de instruções da aplicação a ser analisada e c o número de ciclos estimados. A função f é determinada através do método não linear denominado lazy learning, que consiste basicamente em escolher pontos (vetores s) próximos a aplicação em análise, extraindo-se uma função local(podendo esta ser linear). Bontempi apresenta ainda que o método pode ser adaptado para diferentes arquiteturas onde a função é baseada em parâmetros funcionais e arquiteturais c = f(s f, s a ). O estudo realizado considerou apenas dois parâmetros arquiteturais: o número de ciclos de espera no acesso da memória e a taxa entre a frequência do relógio e do barramento. Os autores reportam um erro entre 0.15% a 17% considerando como arquitetura o MIPS R3000 com 5 estágios de pipeline. Apresentamos, de uma forma geral, os três métodos mais utilizados para estimar o tempo de execução, nas próximas seções apresentaremos questões como pipelines, caches são tratados em tais métodos. 3.1 Pipeline A medida que processadores avançados e com mais recursos podem ser adotados em sistemas embarcados é necessário que os métodos de WCET considerem tais otimizações. O pipeline possibilita que todas as partes do processador estejam o maior tempo em uso. A execução de uma instrução é dividida em estágios, sendo que em um dado momento várias instruções podem estar em execução cada uma em um estágio (HENNESSY; PAT- TERSON, 1995). O fluxo de instruções no pipeline pode ser interrompido devido a conflitos estruturais e de dados que resultam em bolhas no pipeline. Tais conflitos dificultam o cálculo do WCET a medida que as instruções não serão completadas a cada ciclo. Processadores com pipeline podem ainda despachar mais de uma instrução por ciclo e são denominados superescalares. Novamente os fatores que influenciam no despacho são os conflitos estruturais e de dados. Em ambos os casos tais conflitos são detectados dinamicamente, ocasionando uma parada no despacho de instruções. Algumas soluções podem ser adotadas para evitar tal cenário, como renomeação de registradores, execução fora de ordem, entre outros. Mesmo com tais recursos muitas vezes o pipeline não recebe instruções devido aos conflitos. Engblom (ENGBLOM; JONSSON, 2002) apresenta um estudo sobre as propriedades de processadores pipelines e sua implicação em ferramentas de cálculo do WCET. Baseado no tempo de execução de uma instrução I denotado por T (I) e os efeitos do pipeline denotado por δ I1, estas funções quando combinadas conseguem capturar o efeito do pipeline no tempo de execução de uma seqüência de instruções. Desta forma o tempo de execução de uma seqüência de instruções pode ser calculada através da equação 3.3.

20 20 m T (I 1...I m ) = t Ij + δ Ii..I k (3.3) j=1 i i<k m Figura 3.1: Tempo de execução das instruções (a), e os efeitos do pipeline (b) (ENG- BLOM; JONSSON, 2002) Figura 3.2: Efeito positivo do pipeline no tempo de execução (ENGBLOM; JONSSON, 2002) Os efeitos do pipeline podem ser negativos (Figura 3.1), significando speedup do tempo de execução, sendo que no WCET não ocasiona um erro, apenas uma superestimativa do WCET. Os efeitos positivos (execução das instruções A,B e C na Figura 3.2) por sua vez é uma anomalia de processadores pipeline superescalares (LUNDQVIST; STENSTROM, 1999) e aumentam o tempo de execução de um programa e devem ser considerados, pois poderão acarretar uma subestimativa no WCET. É importante notar que os efeitos positivos do pipeline ocorrem em longas seqüências de instruções, implicando que a estimativa estática deve sempre buscar o maior número de instruções para o cálculo do tempo de execução.

21 21 Figura 3.3: Grafo de fluxo de controle anotado com os fatos de execução (a), e após a análise do pipeline (b) (ENGBLOM; ERMEDAHL; STAPPERT, 2001a) Engblom (ENGBLOM; ERMEDAHL; STAPPERT, 2001a) integra o cálculo do tempo de execução com a descrição dos possíveis caminhos de execução através de fatos. Baseado no grafo de controle a ferramenta realiza o cálculo em dois níveis: global considerando o efeito de caches de instruções e dados, predição de desvios, e local onde os efeitos do pipeline e velocidade de acesso a memória são considerados. Após a análise global, o grafo de tempo é anotado com informações denominadas fatos da execução, como mostrado na Figura 3.3 (a). Estes fatos contém informações sobre o acesso a memória, comportamento da cache, que poderão ser utilizados durante a análise local. Na análise local, cada bloco básico é marcado com o tempo de execução considerando os "fatos da execução". Cada transição do bloco recebe um valor similar ao efeitos do pipeline descrito anteriormente, porém no nível de blocos. Basicamente ele apresenta qual o efeito do pipeline caso os blocos básicos fossem executados em seqüência. O autor somente comenta que os escopos poderão ser utilizados para gerar os fatos de execução de blocos básicos com mais de uma entrada (como exemplo o bloco E), porém sem indicar mais detalhes. Os resultados obtidos com a ferramenta para o processador NEC 850V mostram que em casos onde o pipeline não é considerado, erros de estimativa entre 9% a 104% poderão ser encontrados. Quanto o pipeline é considerado os erros de estimativa variam de 0% a 67%. Schneider (SCHNEIDER; FERDINAND, 1999) e Langenbach (LANGENBACH; THESING; HECKMANN, 2002) utilizam interpretação abstrata para simular o comportamento do pipeline. O comportamento do pipeline é descrito por funções de transferência, que indicam quais estados são alterados por uma dada instrução. Assim, é possível contar quantos ciclos são consumidos por uma instrução em um determinado estágio do pipeline. Na interpretação abstrata, as instruções da aplicação são transformadas em instruções abstratas que representam um conjunto de instruções com as mesmas características. É importante notar que os operandos reais da instrução não são considerados na interpretação abstrata. Por exemplo, uma instrução abstrata pode representar todos as instruções aritméticas em inteiros. Assim uma única função descreve a influência de tal instrução na execução do pipeline. A cache também pode ser considerada na função de transferência. O processador analisado por Schneider é um SuperSparcI com pipeline de 5 estágios. Os autores não apresentam resultados muito claros comparando-se apenas o ganho de predição em relação ao paradigma sem considerar o pipeline, porém não apresentam os

22 22 valores do WCET real. Langenbach utilizou o processador Motorola ColdFire 5307 com sete estágios. Os autores apenas descrevem que a ferramenta foi avaliada em benchmark de software aviônicos, sendo os resultados avaliados por especialistas da Airbus, sendo o resultado "positivo". A principal vantagem descrita pelos autores é que a mudança de uma arquitetura requer apenas a mudança das funções de transferência da análise abstrata. Além disso, com a interpretação abstrata os dados reais não são considerados, adicionando imprecisão por exemplo em processadores onde a unidade de ponto flutuante consome uma quantidade de ciclos variável conforme os operandos. Hergenhan (HERGENHAN; ROSENSTIEL, 2000) modela o pipeline utilizando três fases: atribuição, ligação e alocação. Este modelo possui aplicação direta em processadores superescalares, onde mais de uma instrução pode ser alocada por ciclo. Um algoritmo é responsável por receber uma seqüência de instruções e repassar para as unidades funcionais disponíveis simulando a execução da aplicação como mostrada na figura 3.4. Na fase de atribuição, cada instrução é colocada na fila de uma unidade operativa. A fase de ligação e alocação refere-se a execução da instrução. Os autores utilizaram como processador o MPC750, um processador superescalar com despacho de 2 instruções por ciclo. A execução e finalização de instruções é realizada em ordem. Figura 3.4: Modelo abstrato de pipeline proposto por Hergenhan (HERGENHAN; RO- SENSTIEL, 2000) Stappert (STAPPERT; ALTENBERND, 2000) utiliza descrições de arquiteturas para simular o comportamento do pipeline. Um pipeline abstrato composto dos estágios são preenchidos com as instruções conforme o fluxo do programa. Uma tabela realiza o mapeamento, relacionando para uma dada instrução de um determinado tipo o número de ciclos que a mesma consome em um determinado estágio. Lim (LIM et al., 1998) propõe a construcão de um grafo de dependências de instruções para modelar o comportamento de processadores pipeline com múltiplos despachos. Para modelar o comportamento dos processadores, as informações necessárias são os registradores, a quantidade de unidades funcionais e suas respectivas latências, e o número máximo de instruções despachadas por ciclo. O método considera o despacho de instruções em ordem e o acerto em todos os acessos a cache. Após a análise da aplicação, um grafo é construído com as dependências estruturais, de dados e de ordem(considerando que o despacho é sempre em ordem) como apresentado

23 Figura 3.5: Grafo de instruções com as dependências de dados, funcionais e de ordem (b), juntamente com o grafo reduzido (c) (LIM et al., 1998) 23

24 24 na figura 3.5. Todas as arestas têm um peso que é a distância entre duas instruções, que representam, basicamente, o número de ciclos em que a dependência é válida. As arestas redundantes pode ser retiradas utilizando dois critérios: se existe um conjunto de arestas entre dois nós i e j, apenas a maior aresta precisa ser considerada se existe um aresta entre dois nós não consecutivos i e j e a soma dos pesos das arestas no caminho seqüêncial entre estes dois nós é maior ou igual ao peso desta aresta, esta é redundante e pode ser eliminada do grafo (por exemplo as arestas entre os nós 4 e 6). Baseado neste grafo todas as instruções que contém arestas com peso 0 podem ser despachadas ao mesmo tempo. Os autores reportam resultados muito próximos da simulação (erro menor do que 80%), utilizando processadores hipotéticos com 1, 2 e 4 despachos de instrução por ciclo. A complexidade do método é grande e os autores não reportam o tempo de execução gasto pela ferramenta, porém tal método tem a vantagem de não necessitar de um simulador ciclo-a-ciclo, apenas os dados que caracterizam o processadores tais como a quantidade de registradores, unidades funcionais e suas latências entre outros são necessários. Alguns trabalhos (LI; MALIK, 1995; LUNDQVIST; STENSTRÖM, 1999; WOLF; ERNST, 2000) utilizam simuladores ciclo-a-ciclo a fim de calcular o tempo de execução das instruções. Assim o efeito do pipeline pode ser considerado no tempo de execução. 3.2 Predição de desvios Em um processador com pipeline, a cada instrução de mudança de fluxo, o despacho de instruções é interrompido até a resolução do endereço destino. Para que isso não ocorra, as instruções são despachadas em um determinado caminho, e caso a predição esteja correta a execução continua normalmente, caso contrário as instruções no pipeline são retiradas e o novo caminho é executado. A escolha do caminho a ser tomado pode ser realizado tanto estaticamente quanto dinamicamente. Na execução dinâmica normalmente um histórico é armazenado a fim de decidir se um dado caminho é tomado ou não. A execução especulativa adiciona complexidade ao cálculo do WCET pois normalmente a predição errada consome um número de ciclos adicional até que o caminho correto seja tomado. Mesmo assim este recurso é utilizado devido aos altos índices de acerto dos métodos de predição (HENNESSY; PATTERSON, 1995). Colin (COLIN; PUAUT, 2000) apresenta um método para considerar os efeitos da predição de desvios baseado na modelagem do buffer dos alvos de desvios. O método propõe dividir o programa em blocos básicos e após obter o caminho que fornecerá o maior tempo de execução, classificar as instruções de desvios como: H-predicted(History-predicted): são classificadas as instruções que estão no buffer, e durante o cálculo do WCET é considerado o valor presente no histórico; D-predicred(Default-predicted): instruções não estão no buffer durante a predição. Desta forma um valor padrão deve ser escolhido tais como: Always D-predicted considerando que o desvio é sempre tomado, First D-predicted considerando que o desvio é tomado pela primeira vez, First Unknown quanto na primeira predição é desconhecido, Always Unknown quando a predição é sempre desconhecida.

25 25 O método deve considerar o conflito no buffer de endereços alvos, sendo isto realizado através da classificação das instruções em níveis (por exemplo, encadeamento de laços). Assim, uma determinada instrução é classificada como D-predicted ou first unknown se ela está competindo com uma entrada no buffer ocupado por um instrução de um nível mais alto (por exemplo um laço externo). Através da classificação das instruções é possível computar um subconjunto de predições que tem a garantia de serem corretas. Assim, é possivel obter um limite máximo de predições incorretas. Inicialmente, é realizado a escolha de qual alternativa (desvio tomado ou não) fornecerá um erro de predição e após, é determinado quais instruções fornecem uma predição errada. Em laços é considerado que a predição é sempre correta exceto quando da saída do laço. Em instruções if-then-else considera-se que somente um dos caminhos será executado (then ou else o que tiver maior WCET) assim pode-se considerar qual o número de erros de predição. Chen (CHEN; MALIK; AUGUST, 2001) apresenta um método baseado em equações lineares para modelar o efeito da predição de desvios. O mesmo é uma continuação dos trabalhos descritos anteriormente em (LI; MALIK, 1995; LI; MALIK; WOLFE, 1995). Considerando que a predição de desvios é realizada estaticamente pelo compilador, o método adiciona à equação do cálculo do tempo de execução de um bloco básico o custo da predição errada. Isto é possível ligando a análise do fluxo de controle com a predição de desvios realizada pelo compilador. 3.3 Cache Devido a grande diferença entre a freqüência de operação dos processadores e o tempo de acesso a memória muitas vezes caches são utilizadas como forma de amenizar tal diferença. Normalmente uma cache tem como parâmetros o tamanho da linha e o tipo de mapeamento. O mapeamento direto é o de menor complexidade para a ferramenta de WCET, sendo do tipo associativo mais complexo devido a necessidade de considerar o grau e também a política de substituição. As caches podem ser ainda divididas exclusivamente para armazenar dados ou instruções. Muitas vezes as soluções propostas não consideram a cache da dados, devido a dificuldade de determinar estaticamente quais são os endereços acessados em vetores e ponteiros. Li (LI; MALIK; WOLFE, 1995) apresenta uma solução para considerar durante o cálculo do WCET a influência da cache de instruções em processadores i960 da Intel. O método é descrito para aplicação de caches de mapeamento direto.o processo consiste basicamente no mapeamento dos blocos básicos nas linhas da cache. Após o mapeamento é determinado quais linhas contem blocos em conflito. Dois blocos b 1,1 e b 2,1 estão em conflito quando eles estão mapeados para a mesma linha da cache e a execução de b 1,1 implica na execução de b 2,1 ocasionando certamente um miss cache. Baseado na equação 1.1 o cálculo do WCET deve agora considerar o miss cache onde o tempo de execução de um bloco básico i, e dado por: x i = x hit i,j + x miss i,j, 1 j n i (3.4) Tais equações podem ser adicionadas ao método de programação linear inteira anteriormente utilizado apenas para determinar o número máximo n i de execuções de um bloco básico. Cada linha da cache contém um grafo de conflito de cache baseado no fluxo de controle, que indica quando um miss cache poderá ocorrer. Por exemplo, através do

26 26 Figura 3.6: Grafo de fluxo de controle e o mapeamento para cache proposto por Li (LI; MALIK; WOLFE, 1995) grafo é possível extrair que o número máximo de miss cache do bloco b 2,1 é o número de transições de b 1,1 para b 2,1. Hergenhan (HERGENHAN; ROSENSTIEL, 2000) apresenta um método também baseado no grafo de conflito de cache para processadores com cache de instruções do tipo associativa (PPC403). Da mesma forma que apresentado anteriormente o grafo necessita ser adaptado para que a associatividade seja considerada. O problema de considerar a associatividade é o tamanho do grafo gerado. O autor apresenta três alternativas: reduzir o número de blocos a serem analisados, modelar um mecanismo menos complexo de substituição de cache ou modelar uma cache com menor grau de associatividade. Todas esta soluções tornam a estimativa mais imprecisa, podendo aumentar em até 100% o erro de predição. Os autores apresentam que o aumento da associatividade da cache influencia de forma decisiva no tempo gasto pela ferramenta para determinação do WCET, aumentando em até vezes o tempo de execucão da ferramenta com o aumento da associatividade da cache. Stappert (STAPPERT; ALTENBERND, 2000) utiliza um método baseado em conjuntos de entrada e saída de cada bloco básico. Cada bloco básico do programa contém um conjunto denominado IN bb com os dados existentes na cache no início da execução do bloco básico, juntamente com um conjunto OUT bb com os dados existentes após a execução do bloco básico. A inclusão e exclusão de elementos destes conjuntos seguem a política da cache podendo ser determinada pelo usuário. O método é adequado pois repassa o estado da cache para as análises dos blocos básicos subsequentes. Em conjunto com o simulador do pipeline, estes conjuntos são utilizados para simular o estado da cache através da execução dos blocos básicos. Wolf (WOLF; STASCHULAT; ERNST, 2002) apresenta um método para considerar a caches de dados e instruções na análise estática de código. O método é conjugado com o análise do fluxo de controle baseado na detecção de segmentos de programas e não somente em blocos básicos. Tal consideração é importante quando estamos analisando a cache onde seus efeitos ultrapassam os limites de um bloco básico. O trabalho é baseado na utilização de um simulador de cache (Dinero III) ligado ao simulador ciclo-a-ciclo do processador. Conforme os segmentos são detectados estes são simulados e o conteúdo da cache ao final da execução propagado ao próximo segmento a ser executado. O trabalho utiliza o processador StrongArm com caches de associatividade de ordem 32, sendo 16 Kbytes de cache de instrução e 16 Kbytes de cache de dados, sendo a políti-

27 27 Figura 3.7: Grafo de fluxo de controle (a), com o grafo de controle de cache (b) e o grafo alterado considerando o miss cache (LI; MITRA; ROYCHOUDHURY, 2003) cia Round-Robin utilizada na substituição de linhas da cache. Os resultados apresentados pelos autores mostram que a estimativa utilizando segmentos fornecem valores muito mais precisos que em relação ao blocos básicos principalmente devido ao estado da cache extrapolar os limites do bloco básico, evitando a consideração equivocada de miss caches em linhas já carregadas por blocos básicos anteriormente executados. A utilização de um simulador de cache fornece maior possibilidade de considerar caches com alto grau de associatividade, sendo que no paradigma de utilização de grafos de conflito de caches o número de estados pode deixar o método proibitivo. Li (LI; MITRA; ROYCHOUDHURY, 2003) apresenta um método para considerar o efeito da execução especulativa no número de miss cache. A execução especulativa pode influir no cálculo do WCET principalmente se considerado o efeito de uma predição errada, podendo esta ser construtiva, ou seja, carregando linhas na cache que serão utilizadas pelo caminho certo ou destrutiva onde a tomada de um caminho errado pode substituir linhas na cache causando um número maior de miss caches. Tal anomalia denominada de efeitos da pré-busca de um caminho errado, pode acarretar a alteração no número de miss caches entre -10% (efeito construtivo) até 15%(efeito destrutivo) em benchmarks apresentados pelo autor. Os efeitos destrutivos ocasionam um problema para o cálculo do WCET pois adicionam o tempo de execução que só podem ser avaliados quando considerados a execução além de um bloco básico. Para modelar os efeitos da pré-busca no número de miss caches, Li propõe a alteração do grafo de conflito da cache proposto por Li e Malik (LI; MALIK; WOLFE, 1995) para considerar os efeitos da execução especulativa. A figura 3.7 apresenta um grafo de controle (a) e o grafo de conflito (b) de uma determinada linha de cache onde os blocos básicos 0, 1 e 3 tem instruções mapeadas. O grafo de conflito da cache é alterado (c) onde dois novos nós são criados com o objetivo de representar o miss cache resultante de uma predição errada. O nó B 3,1 (2,1) por exemplo representa o miss cache com a predição errada do desvio do bloco básico 2. A partir deste grafo alterado as equações lineares podem ser derivadas para o cálculo do WCET. Os autores apresentam os resultados obtidos com um conjunto de benchmarks consi-

Arquiteturas RISC. (Reduced Instructions Set Computers)

Arquiteturas RISC. (Reduced Instructions Set Computers) Arquiteturas RISC (Reduced Instructions Set Computers) 1 INOVAÇÕES DESDE O SURGIMENTO DO COMPU- TADOR DE PROGRAMA ARMAZENADO (1950)! O conceito de família: desacoplamento da arquitetura de uma máquina

Leia mais

Arquitetura de Computadores - Arquitetura RISC. por Helcio Wagner da Silva

Arquitetura de Computadores - Arquitetura RISC. por Helcio Wagner da Silva Arquitetura de Computadores - Arquitetura RISC por Helcio Wagner da Silva Introdução RISC = Reduced Instruction Set Computer Elementos básicos: Grande número de registradores de propósito geral ou uso

Leia mais

Universidade Federal do Rio de Janeiro Pós-Graduação em Informática IM-NCE/UFRJ. Pipeline. Gabriel P. Silva. Microarquitetura de Alto Desempenho

Universidade Federal do Rio de Janeiro Pós-Graduação em Informática IM-NCE/UFRJ. Pipeline. Gabriel P. Silva. Microarquitetura de Alto Desempenho Universidade Federal do Rio de Janeiro Pós-Graduação em Informática IM-NCE/UFRJ Microarquiteturas de Alto Desempenho Pipeline Gabriel P. Silva Introdução Pipeline é uma técnica de implementação de processadores

Leia mais

3/9/2010. Ligação da UCP com o barramento do. sistema. As funções básicas dos registradores nos permitem classificá-los em duas categorias:

3/9/2010. Ligação da UCP com o barramento do. sistema. As funções básicas dos registradores nos permitem classificá-los em duas categorias: Arquitetura de Computadores Estrutura e Funcionamento da CPU Prof. Marcos Quinet Universidade Federal Fluminense P.U.R.O. Revisão dos conceitos básicos O processador é o componente vital do sistema de

Leia mais

Notas da Aula 15 - Fundamentos de Sistemas Operacionais

Notas da Aula 15 - Fundamentos de Sistemas Operacionais Notas da Aula 15 - Fundamentos de Sistemas Operacionais 1. Software de Entrada e Saída: Visão Geral Uma das tarefas do Sistema Operacional é simplificar o acesso aos dispositivos de hardware pelos processos

Leia mais

Exemplo: CC1 CC2 CC3 CC4 CC5 CC6 CC7 CC8 CC9 ADD $s0, $t0, $t1 IF ID EX MEM WB SUB $t2, $s0, $t3 IF Stall Stall ID EX MEM WB

Exemplo: CC1 CC2 CC3 CC4 CC5 CC6 CC7 CC8 CC9 ADD $s0, $t0, $t1 IF ID EX MEM WB SUB $t2, $s0, $t3 IF Stall Stall ID EX MEM WB 2.3 Dependências de dados (Data Hazards) Ocorre quando uma instrução depende do resultado de outra instrução que ainda está no pipeline. Este tipo de dependência é originado na natureza seqüencial do código

Leia mais

Projeto de Sistemas de Tempo Real

Projeto de Sistemas de Tempo Real Projeto de Sistemas de Tempo Real Centro de Informática - Universidade Federal de Pernambuco Engenharia da Computação Kiev Gama kiev@cin.ufpe.br Slides elaborados pelo professor Marcio Cornélio O autor

Leia mais

28/9/2010. Paralelismo no nível de instruções Processadores superescalares

28/9/2010. Paralelismo no nível de instruções Processadores superescalares Arquitetura de Computadores Paralelismo no nível de instruções Processadores superescalares Prof. Marcos Quinet Universidade Federal Fluminense P.U.R.O. Processadores superescalares A partir dos resultados

Leia mais

Arquitetura de Computadores - Processadores Superescalares. por Helcio Wagner da Silva

Arquitetura de Computadores - Processadores Superescalares. por Helcio Wagner da Silva Arquitetura de Computadores - Processadores Superescalares por Helcio Wagner da Silva Introdução O Pipeline é uma técnica desenvolvida para a melhoria do desempenho frente à execução seqüencial de instruções

Leia mais

Visão Geral de Pipelining

Visão Geral de Pipelining Pipeline Visão Geral de Pipelining Instruções MIPS têm mesmo tamanho Mais fácil buscar instruções no primeiro estágio e decodificar no segundo estágio IA-32 Instruções variam de 1 byte a 17 bytes Instruções

Leia mais

Arquiteturas de Software

Arquiteturas de Software Universidade Federal do Amazonas Faculdade de Tecnologia Departamento de Eletrônica e Computação Arquiteturas de Software Lucas Cordeiro lucascordeiro@ufam.edu.br Notas de Aula Estes slides são baseados

Leia mais

Capítulo 8 Arquitetura de Computadores Paralelos

Capítulo 8 Arquitetura de Computadores Paralelos Capítulo 8 Arquitetura de Computadores Paralelos Necessidade de máquinas com alta capacidade de computação Aumento do clock => alta dissipação de calor Velocidade limitada dos circuitos => velocidade da

Leia mais

ARQUITETURA DE COMPUTADORES

ARQUITETURA DE COMPUTADORES 01001111 01110010 01100111 01100001 01101110 01101001 01111010 01100001 11100111 11100011 01101111 00100000 01100100 01100101 00100000 01000011 01101111 01101101 01110000 01110101 01110100 01100001 01100100

Leia mais

Nível 3 Sistema Operacional

Nível 3 Sistema Operacional Nível 3 Sistema Operacional Universidade Tuiuti do Paraná UTP Faculdade de Ciências Exatas - FACET Tecnologia de Análise e Desenvolvimento de Sistemas Organização de Computadores Prof. André Luiz 1 Nível

Leia mais

Caminho dos Dados e Atrasos

Caminho dos Dados e Atrasos Caminho dos Dados e Atrasos Arquiteturas para Alto Desmpenho Prof. pauloac@ita.br Sala 110 Prédio da Computação www.comp.ita.br/~pauloac Pipeline MIPS O MIPS utiliza um pipeline com profundidade 5, porém

Leia mais

ÁREA: CV ( ) CHSA ( ) ECET ( )

ÁREA: CV ( ) CHSA ( ) ECET ( ) ADAPTAÇÃO E INTEGRAÇÃO DO PROCESSADOR RISCO A UMA ARQUITETURA MULTI-CORE PARA SISTEMAS EMBARCADOS DE PROPOSITO GERAL Laysson Oliveira Luz (Bolsista PIBIC/CNPq), Ivan Saraiva Silva (Orientador, Departamento

Leia mais

Geração de código. Ivan Ricarte INTRODUÇÃO À COMPILAÇÃO

Geração de código. Ivan Ricarte INTRODUÇÃO À COMPILAÇÃO Geração de código Ivan Ricarte 2008 Sumário Geração de código intermediário Código de três endereços Notação pós-fixa Otimização de código Heurísticas de otimização Geração de código em linguagem simbólica

Leia mais

ANHANGUERA EDUCACIONAL. Capítulo 2. Conceitos de Hardware e Software

ANHANGUERA EDUCACIONAL. Capítulo 2. Conceitos de Hardware e Software ANHANGUERA EDUCACIONAL Capítulo 2 Conceitos de Hardware e Software Hardware Um sistema computacional é um conjunto de de circuitos eletronicos. Unidade funcionais: processador, memória principal, dispositivo

Leia mais

Infraestrutura de Hardware. Memória Virtual

Infraestrutura de Hardware. Memória Virtual Infraestrutura de Hardware Memória Virtual Perguntas que Devem ser Respondidas ao Final do Curso Como um programa escrito em uma linguagem de alto nível é entendido e executado pelo HW? Qual é a interface

Leia mais

Máquina Multinível. Um programa pode ser definido como uma seqüência de instruções que descrevem como executar uma determinada tarefa.

Máquina Multinível. Um programa pode ser definido como uma seqüência de instruções que descrevem como executar uma determinada tarefa. Máquina Multinível Um programa pode ser definido como uma seqüência de instruções que descrevem como executar uma determinada tarefa. Uma instrução pode ser definida como um comando para o processador.

Leia mais

PROJETO LÓGICO DE COMPUTADORES Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

PROJETO LÓGICO DE COMPUTADORES Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - Aula 6 - ARQUITETURAS AVANÇADAS DE COMPUTADORES 1. INTRODUÇÃO As arquiteturas dos processadores têm evoluído ao longo dos anos, e junto com ela o conceito de arquitetura avançada tem se modificado. Nos

Leia mais

Arquitetura de Computadores. Arquitetura de Computadores 1

Arquitetura de Computadores. Arquitetura de Computadores 1 Computadores Computadores 1 Introdução Componentes: Processador; UC; Registradores; ALU s, FPU s, etc. Memória (Sistema de armazenamento de informações; Dispositivo de entrada e saída. Computadores 2 Introdução

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Sistemas de Entrada/Saída Princípios de Hardware Sistema de Entrada/Saída Visão Geral Princípios de Hardware Dispositivos de E/S Estrutura Típica do Barramento de um PC Interrupções

Leia mais

5. EXPERIÊNCIAS E ANÁLISE DOS RESULTADOS. 5.1 - Os Programas de Avaliação

5. EXPERIÊNCIAS E ANÁLISE DOS RESULTADOS. 5.1 - Os Programas de Avaliação 36 5. EXPERIÊNCIAS E ANÁLISE DOS RESULTADOS 5.1 - Os Programas de Avaliação Programas de avaliação convencionais foram utilizados para análise de diversas configurações da arquitetura. Estes programas

Leia mais

Notas da Aula 4 - Fundamentos de Sistemas Operacionais

Notas da Aula 4 - Fundamentos de Sistemas Operacionais Notas da Aula 4 - Fundamentos de Sistemas Operacionais 1. Threads Threads são linhas de execução dentro de um processo. Quando um processo é criado, ele tem uma única linha de execução, ou thread. Esta

Leia mais

Aula 26: Arquiteturas RISC vs. CISC

Aula 26: Arquiteturas RISC vs. CISC Aula 26: Arquiteturas RISC vs CISC Diego Passos Universidade Federal Fluminense Fundamentos de Arquiteturas de Computadores Diego Passos (UFF) Arquiteturas RISC vs CISC FAC 1 / 33 Revisão Diego Passos

Leia mais

Arquitetura de Computadores I

Arquitetura de Computadores I Arquitetura de Computadores I Pipeline -- Conflito de dados paradas e adiantamentos -- Conflito de controle detecção de desvios e descarte de instruções -- Edson Moreno edson.moreno@pucrs.br http://www.inf.pucrs.br/~emoreno

Leia mais

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP)

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP) Hardware (Nível 0) Organização O AS/400 isola os usuários das características do hardware através de uma arquitetura de camadas. Vários modelos da família AS/400 de computadores de médio porte estão disponíveis,

Leia mais

Arquitetura e Organização de Computadores 2. Apresentação da Disciplina

Arquitetura e Organização de Computadores 2. Apresentação da Disciplina Arquitetura e Organização de Computadores 2 Apresentação da Disciplina 1 Objetivos Gerais da Disciplina Aprofundar o conhecimento sobre o funcionamento interno dos computadores em detalhes Estudar técnicas

Leia mais

Professores: Aula 10. Lúcia M. A. Drummond Simone de Lima Martins. Conteúdo: Arquiteturas Avançadas. - Arquiteturas RISC - Processamento Paralelo

Professores: Aula 10. Lúcia M. A. Drummond Simone de Lima Martins. Conteúdo: Arquiteturas Avançadas. - Arquiteturas RISC - Processamento Paralelo 1 Professores: Aula 10 Lúcia M. A. Drummond Simone de Lima Martins Conteúdo: Arquiteturas Avançadas - Arquiteturas RISC - Processamento Paralelo 2 Arquiteturas RISC Reduced Instruction Set Computer se

Leia mais

Os textos nestas caixas foram adicionados pelo Prof. Joubert

Os textos nestas caixas foram adicionados pelo Prof. Joubert William Stallings Arquitetura e Organização de Computadores 8 a Edição Capítulo 4 Memória cache Os textos nestas caixas foram adicionados pelo Prof. Joubert slide 1 Características Localização. Capacidade.

Leia mais

7-1. Parte 6 Otimizações da Arquitetura

7-1. Parte 6 Otimizações da Arquitetura 7-1 Parte 6 Otimizações da Arquitetura 7-2 Bibliografia [1] Miles J. Murdocca e Vincent P. Heuring, Introdução à Arquitetura de Computadores [2] Andrew S. Tanenbaum, Modern Operating Systems [3] William

Leia mais

Conceitos de Linguagens de Programação

Conceitos de Linguagens de Programação Conceitos de Linguagens de Programação Aula 07 Nomes, Vinculações, Escopos e Tipos de Dados Edirlei Soares de Lima Introdução Linguagens de programação imperativas são abstrações

Leia mais

- Aula 1 - ARQUITETURA DE COMPUTADORES

- Aula 1 - ARQUITETURA DE COMPUTADORES - Aula 1 - ARQUITETURA DE COMPUTADORES Em arquitetura de computadores serão estudados aspectos da estrutura e do funcionamento dos computadores. O objetivo é apresentar de forma clara e abrangente a natureza

Leia mais

Algumas características especiais

Algumas características especiais Algumas características especiais Tópicos o Medidas de desempenho o CISC versus RISC o Arquiteturas Superescalares o Arquiteturas VLIW Medidas de desempenho Desempenho é muito dependente da aplicação MIPS:

Leia mais

Arquitetura de Computadores Paralelismo, CISC X RISC, Interpretação X Tradução, Caminho de dados

Arquitetura de Computadores Paralelismo, CISC X RISC, Interpretação X Tradução, Caminho de dados Arquitetura de Computadores Paralelismo, CISC X RISC, Interpretação X Tradução, Caminho de dados Organização de um Computador Típico Memória: Armazena dados e programas. Processador (CPU - Central Processing

Leia mais

Arquitetura de Computadores I

Arquitetura de Computadores I Arquitetura de Computadores I Pipeline Edson Moreno edson.moreno@pucrs.br http://www.inf.pucrs.br/~emoreno Organização do MIPS: pipeline Visão geral do pipeline Analogia com uma Lavanderia doméstica 1

Leia mais

Diminui o gargalo existente entre processador e memória principal; 5 a 10 vezes mais rápidas que a memória principal; Ligada diretamente à MP;

Diminui o gargalo existente entre processador e memória principal; 5 a 10 vezes mais rápidas que a memória principal; Ligada diretamente à MP; Diminui o gargalo existente entre processador e memória principal; Diferença de velocidade 5 a 10 vezes mais rápidas que a memória principal; Ligada diretamente à MP; Tecnologia semelhante à da CPU e,

Leia mais

CAPÍTULO 7 NÍVEL DE LINGUAGEM DE MONTAGEM

CAPÍTULO 7 NÍVEL DE LINGUAGEM DE MONTAGEM CAPÍTULO 7 NÍVEL DE LINGUAGEM DE MONTAGEM 71 Introdução Difere dos níveis inferiores por ser implementado por tradução A tradução é usada quando um processador está disponível para uma mensagem fonte mas

Leia mais

AULA 13 - Gerência de Memória

AULA 13 - Gerência de Memória AULA 13 - Gerência de Memória omo sabemos, os computadores utilizam uma hierarquia de memória em sua organização, combinando memórias voláteis e não-voláteis, tais como: memória cache, memória principal

Leia mais

Geração de código intermediário. Novembro 2006

Geração de código intermediário. Novembro 2006 Geração de código intermediário Novembro 2006 Introdução Vamos agora explorar as questões envolvidas na transformação do código fonte em uma possível representação intermediária Como vimos, nas ações semânticas

Leia mais

Sistemas Processadores e Periféricos Aula 9 - Revisão

Sistemas Processadores e Periféricos Aula 9 - Revisão Sistemas Processadores e Periféricos Aula 9 - Revisão Prof. Frank Sill Torres DELT Escola de Engenharia UFMG Adaptado a partir dos Slides de Organização de Computadores 2006/02 do professor Leandro Galvão

Leia mais

ARQUITETURA DE COMPUTADORES - 1866

ARQUITETURA DE COMPUTADORES - 1866 7 Unidade Central de Processamento (UCP): O processador é o componente vital do sistema de computação, responsável pela realização das operações de processamento e de controle, durante a execução de um

Leia mais

PROJETO LÓGICO DE COMPUTADORES Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

PROJETO LÓGICO DE COMPUTADORES Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - Aula 2 - O NÍVEL DA MICROARQUITETURA 1. INTRODUÇÃO Este é o nível cuja função é implementar a camada ISA (Instruction Set Architeture). O seu projeto depende da arquitetura do conjunto das instruções

Leia mais

Capítulo 1. Introdução. 1.1 Linguagens. OBJETIVOS DO CAPÍTULO Ao final deste capítulo você deverá ser capaz de:

Capítulo 1. Introdução. 1.1 Linguagens. OBJETIVOS DO CAPÍTULO Ao final deste capítulo você deverá ser capaz de: i Sumário 1 Introdução 1 1.1 Linguagens....................................... 1 1.2 O que é um Compilador?................................ 2 1.3 Processadores de Programas: Compiladores, Interpretadores

Leia mais

Organização e Arquitetura de Computadores

Organização e Arquitetura de Computadores Organização e Arquitetura de Computadores Entrada e saída Alexandre Amory Edson Moreno Nas Aulas Anteriores Foco na Arquitetura e Organização internas da Cleo Modelo Von Neuman Circuito combinacional Circuito

Leia mais

Um sistema é constituído de um conjunto de processos que executam seus respectivos códigos do sistema operacional e processos e códigos de usuários.

Um sistema é constituído de um conjunto de processos que executam seus respectivos códigos do sistema operacional e processos e códigos de usuários. Os sistemas computacionais atuais permitem que diversos programas sejam carregados na memória e executados simultaneamente. Essa evolução tornou necessário um controle maior na divisão de tarefas entre

Leia mais

4 Conversor EDTV Raw. 4.1 Arquitetura

4 Conversor EDTV Raw. 4.1 Arquitetura 4 Conversor EDTV Raw O conversor EDTV Raw é o programa que lê um documento escrito no perfil NCL EDTV e gera um documento Raw equivalente, i.e. que define a mesma apresentação. Este capítulo, apresenta

Leia mais

Capítulo 3. Avaliação de Desempenho. 3.1 Definição de Desempenho

Capítulo 3. Avaliação de Desempenho. 3.1 Definição de Desempenho 20 Capítulo 3 Avaliação de Desempenho Este capítulo aborda como medir, informar e documentar aspectos relativos ao desempenho de um computador. Além disso, descreve os principais fatores que influenciam

Leia mais

Guilherme Quentel Melo Modelagem do processador Nios2 para uma plataforma de SoCs

Guilherme Quentel Melo Modelagem do processador Nios2 para uma plataforma de SoCs Guilherme Quentel Melo Modelagem do processador Nios2 para uma plataforma de SoCs Florianópolis SC 2006/2 Guilherme Quentel Melo Modelagem do processador Nios2 para uma plataforma de SoCs Trabalho de conclusão

Leia mais

UNIVERSIDADE FEDERAL DE SANTA CATARINA MODELAGEM DE UMA PLATAFORMA VIRTUAL PARA SISTEMAS EMBUTIDOS BASEADA EM POWERPC

UNIVERSIDADE FEDERAL DE SANTA CATARINA MODELAGEM DE UMA PLATAFORMA VIRTUAL PARA SISTEMAS EMBUTIDOS BASEADA EM POWERPC UNIVERSIDADE FEDERAL DE SANTA CATARINA DANIEL CARLOS CASAROTTO JOSE OTÁVIO CARLOMAGNO FILHO MODELAGEM DE UMA PLATAFORMA VIRTUAL PARA SISTEMAS EMBUTIDOS BASEADA EM POWERPC Florianópolis, 2004 DANIEL CARLOS

Leia mais

As características comuns, encontradas na maioria dos processadores RISC são as seguintes:

As características comuns, encontradas na maioria dos processadores RISC são as seguintes: 4 2. COMPARAÇÃO DAS ARQUITETURAS RISC 2.1 - Introdução Os microprocessadores RISC se distinguem por uma série de características comuns, que resultam em uma solução de baixo custo e alto desempenho. Contudo,

Leia mais

Tais operações podem utilizar um (operações unárias) ou dois (operações binárias) valores.

Tais operações podem utilizar um (operações unárias) ou dois (operações binárias) valores. Tais operações podem utilizar um (operações unárias) ou dois (operações binárias) valores. 7.3.1.2 Registradores: São pequenas unidades de memória, implementadas na CPU, com as seguintes características:

Leia mais

Organização e Arquitetura de Computadores I. de Computadores

Organização e Arquitetura de Computadores I. de Computadores Universidade Federal de Campina Grande Unidade Acadêmica de Sistemas e Computação Curso de Bacharelado em Ciência da Computação Organização e Arquitetura de Computadores I Organização Básica B de Computadores

Leia mais

Tabela de Símbolos. Análise Semântica A Tabela de Símbolos. Principais Operações. Estrutura da Tabela de Símbolos. Declarações 11/6/2008

Tabela de Símbolos. Análise Semântica A Tabela de Símbolos. Principais Operações. Estrutura da Tabela de Símbolos. Declarações 11/6/2008 Tabela de Símbolos Análise Semântica A Tabela de Símbolos Fabiano Baldo Após a árvore de derivação, a tabela de símbolos é o principal atributo herdado em um compilador. É possível, mas não necessário,

Leia mais

Organização de Computadores 1

Organização de Computadores 1 Organização de Computadores 1 4 SUPORTE AO SISTEMA OPERACIONAL Prof. Luiz Gustavo A. Martins Sistema Operacional (S.O.) Programa responsável por: Gerenciar os recursos do computador. Controlar a execução

Leia mais

Abordagens de Escalonamento na Perspectiva da Engenharia

Abordagens de Escalonamento na Perspectiva da Engenharia Mercado para tempo real é amplo Necessidade de Diferentes Abordagens Sistemas de Tempo Real: Abordagens de Escalonamento na Perspectiva da Engenharia Rômulo Silva de Oliveira Departamento de Automação

Leia mais

O que é um programa? Programa é uma lista de instruções que descrevem uma tarefa a ser realizada pelo computador.

O que é um programa? Programa é uma lista de instruções que descrevem uma tarefa a ser realizada pelo computador. O que é um programa? Programa é uma lista de instruções que descrevem uma tarefa a ser realizada pelo computador. Linguagem de Programação Uma linguagem de programação é um método padronizado para expressar

Leia mais

Pipeline. Todos os estágios devem estar prontos ao mesmo tempo para prosseguir.

Pipeline. Todos os estágios devem estar prontos ao mesmo tempo para prosseguir. O throughput de um pipeline é determinado pela freqüência com que uma instrução sai do pipeline Todos os estágios devem estar prontos ao mesmo tempo para prosseguir O tempo requerido para mover uma instrução

Leia mais

7 Processamento Paralelo

7 Processamento Paralelo 7 Processamento Paralelo Yes, of course, who has time? Who has time? But then if we do not ever take time, how can we ever have time? (The Matrix) 7.1 Introdução Classificação de Sistemas Paralelos Diversas

Leia mais

Informática I. Aula 5. http://www.ic.uff.br/~bianca/informatica1/ Aula 5-13/05/2006 1

Informática I. Aula 5. http://www.ic.uff.br/~bianca/informatica1/ Aula 5-13/05/2006 1 Informática I Aula 5 http://www.ic.uff.br/~bianca/informatica1/ Aula 5-13/05/2006 1 Ementa Histórico dos Computadores Noções de Hardware e Software Microprocessadores Sistemas Numéricos e Representação

Leia mais

Arquiteturas que Exploram Paralismos: VLIW e Superscalar. Ch9 1

Arquiteturas que Exploram Paralismos: VLIW e Superscalar. Ch9 1 Arquiteturas que Exploram Paralismos: VLIW e Superscalar Ch9 1 Introdução VLIW (Very Long Instruction Word): Compilador empacota um número fixo de operações em uma instrução VLIW As operações dentro de

Leia mais

Introdução à Arquitetura de Computadores

Introdução à Arquitetura de Computadores 1 Introdução à Arquitetura de Computadores Hardware e software Organização de um computador: Processador: registradores, ALU, unidade de controle Memórias Dispositivos de E/S Barramentos Linguagens de

Leia mais

Capítulo 3 Gerenciamento de memória

Capítulo 3 Gerenciamento de memória Sistemas operacionais modernos Terceira edição ANDREW S. TANENBAUM Capítulo 3 Gerenciamento de memória Introdução Programas tendem a se expandir a fim de ocupar toda a memória disponível Programador deseja

Leia mais

S.O.: Conceitos Básicos

S.O.: Conceitos Básicos S.O.: Conceitos Básicos Camada de software localizada entre o hardware e os programas que executam tarefas para o usuário; Acessa os periféricos Entrada e Saída Esconde os detalhes do hardware para o programador

Leia mais

Arquitetura e Organização de Computadores 2

Arquitetura e Organização de Computadores 2 Arquitetura e Organização de Computadores 2 Escalonamento Estático e Arquiteturas VLIW Dynamic Scheduling, Multiple Issue, and Speculation Modern microarchitectures: Dynamic scheduling + multiple issue

Leia mais

Tempo Real 7/4/2010. Aula 10. Engenharia de Sistemas Embarcados

Tempo Real 7/4/2010. Aula 10. Engenharia de Sistemas Embarcados Agenda Aula 10 Engenharia de Sistemas Embarcados Prof. Abel Guilhermino Tópico: Sistemas de Tempo Real Conceitos Gerais Processos de Tempo Real Periódico, Aperiódicos e Esporádicos Escalonamento de Tempo

Leia mais

Construção de Compiladores. Construção de Compiladores. Motivação. Motivação. Contexto Histórico. Classificações: Gerações 09/03/2010

Construção de Compiladores. Construção de Compiladores. Motivação. Motivação. Contexto Histórico. Classificações: Gerações 09/03/2010 Construção de Compiladores Prof. Raimundo Santos Moura (http://www.ufpi.br/rsm) Construção de Compiladores Livro-Texto: AHO, Alfred V.; ULLMAN, Jeffrey D.; SETHI, R. Compiladores: princípios, técnicas

Leia mais

Desenvolvimento para Sistemas Embarcados (CEA 513) Conceitos Gerais

Desenvolvimento para Sistemas Embarcados (CEA 513) Conceitos Gerais Universidade Federal de Ouro Preto Departamento de Computação e Sistemas - DECSI Desenvolvimento para Sistemas Embarcados (CEA 513) Conceitos Gerais Vicente Amorim vicente.amorim.ufop@gmail.com Sumário

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Aula 5 Estrutura de Sistemas de Computação Prof.: Edilberto M. Silva http://www.edilms.eti.br Baseado no material disponibilizado por: SO - Prof. Edilberto Silva Prof. José Juan Espantoso

Leia mais

GUILHERME STUTZ TÖWS ANIMAÇÃO DE ALGORITMOS

GUILHERME STUTZ TÖWS ANIMAÇÃO DE ALGORITMOS GUILHERME STUTZ TÖWS ANIMAÇÃO DE ALGORITMOS Trabalho de graduação do Curso de Ciência da Computação do Setor de Ciências Exatas da Universidade Federal do Paraná. Professor: André Luiz Pires Guedes CURITIBA

Leia mais

Arquitetura e Organização de Computadores. Capítulo 0 - Introdução

Arquitetura e Organização de Computadores. Capítulo 0 - Introdução Arquitetura e Organização de Computadores Capítulo 0 - Introdução POR QUE ESTUDAR ARQUITETURA DE COMPUTADORES? 2 https://www.cis.upenn.edu/~milom/cis501-fall12/ Entender para onde os computadores estão

Leia mais

PROGRAMA DE DISCIPLINA

PROGRAMA DE DISCIPLINA PROGRAMA DE DISCIPLINA Disciplina: Introdução à Programação Carga horária total: 60 Carga horária teórica: 0 Carga horária prática: 60 Código da Disciplina: CCMP0041 Período de oferta: 2010.2 Turma: CA

Leia mais

Máquinas Multiníveis

Máquinas Multiníveis Infra-Estrutura de Hardware Máquinas Multiníveis Prof. Edilberto Silva www.edilms.eti.br edilms@yahoo.com Sumário Conceitos básicos Classificação de arquiteturas Tendências da tecnologia Família Pentium

Leia mais

PLANEJAMENTO - ESCOPO - TEMPO - CUSTO

PLANEJAMENTO - ESCOPO - TEMPO - CUSTO PLANEJAMENTO - ESCOPO - TEMPO - CUSTO PAULO SÉRGIO LORENA Julho/2011 1 Planejamento escopo, tempo e custo PROGRAMA DA DISCIPLINA Apresentação professor Programa da disciplina Avaliação Introdução Processos

Leia mais

Software. Professora Milene Selbach Silveira Prof. Celso Maciel da Costa Faculdade de Informática - PUCRS

Software. Professora Milene Selbach Silveira Prof. Celso Maciel da Costa Faculdade de Informática - PUCRS Software Professora Milene Selbach Silveira Prof. Celso Maciel da Costa Faculdade de Informática - PUCRS ESQUEMA DE UM SISTEMA DE COMPUTADOR Unidades de Entrada - Teclado - Scanner - Caneta Ótica - Leitora

Leia mais

Técnicas de Teste de Software

Técnicas de Teste de Software Técnicas de Teste de Software Fabrício Sousa fabricio@uesb.br Projeto de Caso de Teste Conjunto de técnicas para criação de casos de testes Série de casos de testes que tem grande probabilidade de encontrar

Leia mais

ESTRUTURAS DE DADOS I. Notas de Aula. Prof. Dr. Gilberto Nakamiti

ESTRUTURAS DE DADOS I. Notas de Aula. Prof. Dr. Gilberto Nakamiti ESTRUTURAS DE DADOS I Notas de Aula 1 SUMÁRIO 1. INTRODUÇÃO... 2 1.1 Array (vetores)... 2 2. BUSCA DE ELEMENTOS... 3 2.1 Busca Seqüencial... 3 2.2 Busca Binária... 3 2.3 Busca Indexada... 3 2.4 Busca Hash...

Leia mais

1. NÍVEL CONVENCIONAL DE MÁQUINA (Cont.) 1.3. INSTRUÇÕES Conceitos Básicos

1. NÍVEL CONVENCIONAL DE MÁQUINA (Cont.) 1.3. INSTRUÇÕES Conceitos Básicos 1. NÍVEL CONVENCIONAL DE MÁQUINA (Cont.) 1.3. INSTRUÇÕES Conceitos Básicos Já estudamos anteriormente que os processadores funcionam (ou melhor, o seu hardware funciona) através de ordens simples e básicas,

Leia mais

Sistemas Distribuídos: Conceitos e Projeto Threads e Migração de Processos

Sistemas Distribuídos: Conceitos e Projeto Threads e Migração de Processos Sistemas Distribuídos: Conceitos e Projeto Threads e Migração de Processos Francisco José da Silva e Silva Laboratório de Sistemas Distribuídos (LSD) Departamento de Informática / UFMA http://www.lsd.deinf.ufma.br

Leia mais

1.6. Tratamento de Exceções

1.6. Tratamento de Exceções Paradigmas de Linguagens I 1 1.6. Tratamento de Exceções Uma exceção denota um comportamento anormal, indesejado, que ocorre raramente e requer alguma ação imediata em uma parte do programa [GHE 97, DER

Leia mais

ORGANIZAÇÃO CURRICULAR

ORGANIZAÇÃO CURRICULAR ORGANIZAÇÃO CURRICULAR O curso Técnico em Informática, em Nível Médio Subseqüente, será organizado de forma semestral, com aulas presenciais, compostos por disciplinas, com conteúdos estabelecidos, tendo

Leia mais

Arquitetura de Computadores. Ivan Saraiva Silva

Arquitetura de Computadores. Ivan Saraiva Silva Arquitetura de Computadores Métricas de Desempenho Ivan Saraiva Silva Sumário Como arquiteturas são geralmente avaliadas Como arquiteturas obedecem a restrições de projeto Métricas de desempenho Combinando

Leia mais

Sistemas Paralelos e Distribuídos. Prof. Jorge Dantas de Melo Depto. Eng. Comp. e Automação CT - UFRN

Sistemas Paralelos e Distribuídos. Prof. Jorge Dantas de Melo Depto. Eng. Comp. e Automação CT - UFRN Sistemas Paralelos e Distribuídos Prof. Jorge Dantas de Melo Depto. Eng. Comp. e Automação CT - UFRN Conceitos preliminares Paralelismo refere-se a ocorrência simultânea de eventos em um computador Processamento

Leia mais

Capítulo 8: Gerenciamento de Memória

Capítulo 8: Gerenciamento de Memória Capítulo 8: Gerenciamento de Memória Sobre a apresentação (About( the slides) Os slides e figuras dessa apresentação foram criados por Silberschatz, Galvin e Gagne em 2005. Esse apresentação foi modificada

Leia mais

Introdução. Introdução. Introdução. Organização Estruturada de Computadores. Introdução. Máquinas Multiníveis

Introdução. Introdução. Introdução. Organização Estruturada de Computadores. Introdução. Máquinas Multiníveis Ciência da Computação Arq. e Org. de Computadores Máquinas Multiníveis Prof. Sergio Ribeiro Computador digital máquina que resolve problemas executando uma série de instruções. Programa conjunto de instruções

Leia mais

1 MÁQUINAS VIRTUAIS, MÁQUINAS MULTINÍVEL E LINGUAGENS

1 MÁQUINAS VIRTUAIS, MÁQUINAS MULTINÍVEL E LINGUAGENS 1 MÁQUINAS VIRTUAIS, MÁQUINAS MULTINÍVEL E LINGUAGENS 1.1 - INTRODUÇÃO Um computador digital é uma máquina capaz de nos solucionar problemas através da execução de instruções que lhe são fornecidas. Denomina-se

Leia mais

UNIVERSIDADE DO OESTE DE SANTA CATARINA CAMPUS DE SÃO MIGUEL DO OESTE

UNIVERSIDADE DO OESTE DE SANTA CATARINA CAMPUS DE SÃO MIGUEL DO OESTE UNIVERSIDADE DO OESTE DE SANTA CATARINA CAMPUS DE SÃO MIGUEL DO OESTE CURSO: CIÊNCIAS DA COMPUTAÇÃO DISCIPLINA: COMPILADORES PROFESSOR: JOHNI DOUGLAS MARANGON Back-End Compilação 1. Compilação etapa Back-end

Leia mais

Capítulo 2 Processos e Threads Prof. Fernando Freitas

Capítulo 2 Processos e Threads Prof. Fernando Freitas slide 1 Capítulo 2 Processos e Threads Prof. Fernando Freitas Material adaptado de: TANENBAUM, Andrew S. Sistemas Operacionais Modernos. 3ª edição. Disponível em: http://www.prenhall.com/tanenbaum_br slide

Leia mais

Engenharia de Software-2003

Engenharia de Software-2003 Engenharia de Software-2003 Mestrado em Ciência da Computação Departamento de Informática - UEM Profa. Dra. Elisa H. M. Huzita eng. de software-2003 Elisa Huzita Produto de Software Conceitos Software

Leia mais

1 - Processamento de dados

1 - Processamento de dados Conceitos básicos sobre organização de computadores 2 1 - Processamento de dados O que é processamento? O que é dado? Dado é informação? Processamento é a manipulação das informações coletadas (dados).

Leia mais

Projeto de Arquitetura

Projeto de Arquitetura Projeto de Arquitetura Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 11 Slide 1 Objetivos Apresentar projeto de arquitetura e discutir sua importância Explicar as decisões de projeto

Leia mais

Pontifícia Universidade Católica do Rio Grande do Sul Faculdade de Informática Organização e Arquitetura de Computadores

Pontifícia Universidade Católica do Rio Grande do Sul Faculdade de Informática Organização e Arquitetura de Computadores Pontifícia Universidade Católica do Rio Grande do Sul Faculdade de Informática Organização e Arquitetura de Computadores Questão 1) Considere o projeto de um circuito digital que implementa a função f

Leia mais

Implementação de um soft-core em VHDL baseado no conjunto de instruções MIPS-I

Implementação de um soft-core em VHDL baseado no conjunto de instruções MIPS-I UNIVERSIDADE FEDERAL DE SANTA CATARINA DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA CURSO DE CIÊNCIAS DA COMPUTAÇÃO Rafael Vargas Implementação de um soft-core em VHDL baseado no conjunto de instruções MIPS-I

Leia mais

Suporte à Engenharia Reversa para o ambiente SEA

Suporte à Engenharia Reversa para o ambiente SEA Otavio Pereira Suporte à Engenharia Reversa para o ambiente SEA Orientador: Ricardo Pereira e Silva Universidade Federal de Santa Catarina - UFSC Departamento de Informática e Estatística - INE Florianópolis

Leia mais

Sistemas Operacionais Carlos Eduardo Portela Serra de Castro

Sistemas Operacionais Carlos Eduardo Portela Serra de Castro Introdução Sistemas Operacionais 1 Sistema Operacional: Um conjunto de programas, executado pelo computador como os outros programas. Função: Controlar o funcionamento do computador, disponibilizando seus

Leia mais

O Processador: Caminho de Dados e Controle

O Processador: Caminho de Dados e Controle 22 Capítulo 3 O Processador: Caminho de Dados e Controle O desempenho de um computador é determinado por três fatores principais: o número de instruções executadas, o período do clock e o número de ciclos

Leia mais

A Linguagem Algorítmica Estrutura de Repetição. Ex. 2

A Linguagem Algorítmica Estrutura de Repetição. Ex. 2 Estrutura de Repetição. Ex. 2 A ESTRUTURA Enquanto faça{} É MELHOR UTILIZADA PARA SITUAÇÕES ONDE O TESTE DE CONDIÇÃO (V OU F) PRECISA SER VERIFICADO NO INÍCIO DA ESTRUTURA DE REPETIÇÃO.

Leia mais

Arquitetura de Computadores. Ivan Saraiva Silva

Arquitetura de Computadores. Ivan Saraiva Silva Arquitetura de Computadores MIPS Pipeline Ivan Saraiva Silva Pipeline 4 pessoas (A, B, C, D) possuem sacolas de roupa para lavar, secar e dobrar A B C D Lavar leva 30 minutos Secar leva 40 minutos Dobrar

Leia mais