Trabalho de Microprogramação Utilizando Simulador Escape...

Arquitetura de Computadores I

Professor: Felipe Maia Galvão França

Alunos:

Daniel Mendes

Fabrício Jorge Lopes Ribeiro

Trabalho de Microprogramação

Utilizando Simulador Escape DLX

Trabalho de Microprogramação Utilizando Escape DLX

PESC - Arquitetura de Computadores I

Prof.: Felipe França Alunos: Daniel Mendes e Fabrício Jorge Lopes Ribeiro

2

1. Introdução 3

2. Conceitos de Microprogramação 3

3. Simulador ESCAPE DLX 4

3.1. Características 4

3.1.1. Janela de Visualização da Arquitetura 5

3.1.2. Janela de Visualização do Microcódigo 6

3.1.3. Janela de Visualização das Instruções na Memória 7

3.1.4. Janela de Visualização da Memória 8

4. Apresentação do algoritmo 9

4.1. – Descrição da Implementação 14

5. Desempenho 15

6. Conclusão 16

7. Anexo 1 – Fonte do programa original em assembly x86 17

8. Anexo 2 – Fonte do programa para escapeDLX sem instruções de uso específico 19

9. Anexo 3 – Fonte do programa para escapeDLX com instrução FILT 21

10. Anexo 4 – Tabela de Microcódigo com instrução FILT 23

11. Anexo 5 – Jump Table com instrução FILT 24




3

1. Introdução

O objetivo deste trabalho é comparar o desempenho de um programa quando

implementado em um processador através do uso de instruções típicas versus com o uso de uma

instrução especial criada a partir da alteração do microcódigo que realize uma parcela

considerável do programa. Para isto escolhemos um algoritmo de processamento de imagens com

grande localidade de execução, isto é, na maior parte do tempo apenas um pequeno conjunto de

instruções do algoritmo está sendo executado. Após medir o número de ciclos de máquina

necessários para executar o algoritmo com um certo conjunto de dados de entrada, criamos uma

instrução (através da inserção de um opcode novo na jumptable e da escrita do seu

correspondente microcódigo) capaz de realizar a tarefa previamente desempenhada pelas

instruções de uso repetitivo. Realizamos novamente a medida do número de ciclos necessários

para a execução do programa e apresentamos nossas conclusões.

2. Conceitos de Microprogramação

Em todo processador existe um conjunto primitivo de operações que pode ser executado

diretamente por circuitos lógicos. Tais operações incluem a leitura e a gravação de registradores,

operações aritméticas e lógicas da ALU, etc. Para selecionar quais destas operações serão

executadas em um ciclo existem sinais de controle, cujos níveis lógicos podem ser definidos

através de lógica digital direta a partir das palavras de instruções (lógica hard wired) ou através

de palavras oriundas de uma memória interna ao processador, onde um programa nela

armazenado configura tais sinais de controle em função das palavras de instrução apresentadas ao

processador. A este programa convencionou-se chamar “microcódigo”.

As microinstruções possuem formatos ligados diretamente à disposição dos sinais de

controle do processador, logo costumam possuir grande largura de bits com vários campos.

Habitualmente as microinstruções ficam armazenadas em uma ROM cujos endereços são

seguidos em seqüência, a não ser que o microprograma execute uma operação de desvio. Neste

caso, tabelas com endereços de saltos (jump tables) são utilizadas para determinar a próxima

instrução.




4

3. Simulador ESCAPE DLX

O Escape é um ambiente de simulação de arquitetura de computadores com propósito

educacional, que permite a utilização de um processador microprogramado (arquitetura von

Neumann) e um processador pipeline (arquitetura Harvard). Estas duas arquiteturas foram

implementadas em 32 bits baseadas no DLX de Hennessy e Patterson.

3.1. Características

As arquiteturas de microprogramação e pipeline são parcialmente configuráveis,

permitindo que o usuário tenha acesso a algumas configurações básicas, como o número de

registradores, opcodes e tamanho do campo imediato.

Nesta arquitetura o tamanho dos campos de bits são variáveis, dependendo do número de

instruções e registradores, tendo todas as instruções 32 bits. Dependendo do tipo de simulação

podemos utilizar 4 a 256 registradores, além de ter a possibilidade de configurar o número de

ciclos para acesso à memória (wait states), e até 4 jump tables.

Como a arquitetura foi baseadas no DLX de Hennessy e Patterson, foram definidos três tipos de

intruções, a tipo I, R e J.

Figura 1 - Campos das Instruções




5

O caminho de dados é composto por dois registradores de leitura (A e B), um de escrita

(C), uma interface de memória com endereço (MAR), dados (MDR), registradores de instruções

(IR), contador de programa (PC), registradores extras e uma unidade aritmética ALU. As

diferentes partes são conectadas por dois barramentos de entrada (S1 e S2) e um barramento de

resultado. A ALU pode realizar várias operações básicas em um único ciclo.

A unidade de controle é microprogramada, sendo o endereço do microcódigo guardado

em um registrador especial (uAR). Durante cada ciclo este registrador é incrementado com um

novo valor.

Tabela 1 – Instruções do Escape

Existem várias janelas que permitem que o usuário tenha acesso as informações da

arquitetura, instruções, memória e microcódigo.

3.1.1. Janela de Visualização da Arquitetura

A simulação pode ser executada ciclo a ciclo ou por vários ciclos definidos de acordo com

o usuário. Durante a execução do programa os ciclos podem ser revertidos para retornar a

execução do programa em uma determinada instrução, sendo que este recurso tem o limite de

1024 ciclos.




6

A arquitetura é composta de uma unidade de controle e um caminho de dados de acordo

com a figura 2.

Figura 2 - da Arquitetura Escape

3.1.2. Janela de Visualização do Microcódigo

Nesta janela podemos definir o trecho de microcódigo correspondente a cada instrução do

programa. Nesta janela podemos definir todos os parâmetros das instruções. A figura 3 mostra a

janela de visualização de microcódigo.




7

Figura 3 – Janela de visualização das Instruções

3.1.3. Janela de Visualização das Instruções na Memória

Nesta janela podemos ver o conteúdo da memória sob a forma de instruções. Vale lembrar

que a mesma memória serva para armazenar código e dados, logo qualquer modificação nesta

janela criará uma modificação na janela de visualização de memória e vice-versa (arquitetura

Von Neumann). A janela de visualização das instruções na memória pode ser vista na figura 4.




8

Figura 4 – Seqüência das Instruções na Memória

3.1.4. Janela de Visualização da Memória

A memória pode ser editada através de uma janela de visualização específica, permitindo

a alteração do tamanho da memória e o tempo de acesso, que pode ser configurado de 1 a 9

ciclos.

Os dados da memória podem ser acessados ou gravados em words de 32 bits, meias-

palavras de 16 bits ou em bytes de 8 bits.

Na figura 5 vemos a janela de visualização de memória.




9

Figura 5 – Dados da Memória

4. Apresentação do algoritmo

O algoritmo escolhido foi a aplicação de um kernel sobre uma imagem. Trata-se de uma

operação comum para processamento de imagens, usualmente objetivando algum tipo de

filtragem espacial do sinal. Nesta operação, temos uma matriz de coeficientes (habitualmente

quadrada) de dimensões ímpares (chamada kernel). O elemento central é sobreposto a um

elemento da imagem a ser filtrada. Em seguida, calcula-se o produto entre os elementos do

kernel e os elementos da matriz origem, somam-se os resultados e substitui-se o pixel

equivalente ao elemento central por este resultado. A operação deve ser repetida para todos os

pixels da imagem a ser filtrada. A figura 6 mostra esta operação.




10

Figura 6 – Aplicação de um kernel sobre uma imagem

Habitualmente os coeficientes de um kernel somam 1, de forma a preservar a quantidade

de “energia” presente na imagem. Os kernels simétricos não favorecem o deslocamento da

energia na imagem. Já os assimétricos podem criar efeitos do tipo “motion blur”.

Especificamente no nosso trabalho escolhemos um kernel que cria um efeito de chamas

(associado à uma pallete de cores apropriada). Tal tipo de kernel foi desenvolvido para a

criação de efeitos gráficos em programas intitulados “demos” onde preza-se a qualidade

gráfica obtida com programas compactos. A figura 7 mostra o screenshot de um programa

deste tipo escrito por um dos autores executando este efeito:




11

Figura 7 – Exemplo do kernel do fogo sendo usado por uma demo

Para gerar tal efeito escolhemos uma matriz de valores compreendidos entre 0 e 255, onde

0 representa a parte mais “fria” (em preto, neste exemplo) e 255 a mais “quente” (em amarelo

claro). As outras tonalidades seguem um degradé entre estes extremos.

Inicialmente, escolhemos aleatoriamente valores iniciais para a linha inferior da matriz,

sendo estes valores 0 ou 255. Esta linha não é mostrada na tela pois não tem uma aparência

muito boa (fica com pixels amarelos e pretos alternados). O kernel aplicado é o seguinte:

Figura 8 – Kernel de geração do efeito do fogo

Como o kernel não é simétrico, ele favorece que a energia “suba”, pois cada linha torna-se

uma média ponderada da linha inferior e do pixel central. Na verdade, para que a chama




12

venha a se extinguir antes de atingir o topo da matriz o kernel deveria ter uma média menor

do que 1, mas isso implicaria no uso de aritmética de ponto flutuante. A solução encontrada

foi subtrair 1 do resultado do kernel caso este fosse maior do que 0, ou deixar 0 caso

contrário. Esta modificação introduz uma pequena não-linearidade no cálculo mas diminui

enormemente a complexidade computacional, já que podemos somar o valor dos 4 pixels com

peso ¼ e deslocar o resultado 2 casas binárias para a direita, efetuando assim a divisão por 4

com uma operação barata em termos de tempo computacional (o programa original foi

otimizado para execução em um PC386).

O algoritmo final fica então assim (em C):

S=(Matrix[K] + Matrix[K+L-1] + Matrix[K+L] + Matrix[K+L+1])>>4;

IF (S > 0) S--;

Matrix[K] = S;

Onde K é o índice do vetor e L é a largura da matriz “Matrix”.

Neste ponto cabe ressaltar outras três otimizações usadas tanto na implementação original

quanto na implementação no simulador EscapeDLX:

1) Em vez de considerar uma “matriz”, ou seja, um plano bi-dimensional, consideramos o

campo de aplicação do kernel como um “array”. Esta simplificação permite manter

apenas um índice para indexá-lo, a troco de gerar problemas na primeira e na última

coluna (pois as mesmas não possuem vizinhos, e com esta otimização os vizinhos se

tornarão a coluna oposta). Visualmente, esta simplificação causaria a impressão de que o

fogo estava sendo gerado em um cilindro que foi aberto e esticado na tela. Para contornar

este efeito obrigamos os pixels da última linha próximos tanto da primeira quanto da

última coluna a serem negros, de forma que não sejam geradas chamas nos cantos da tela.

Figura 9 – Tratando a matriz como um buffer unidimensional introduzimos uma dependência

entre a coluna esquerda e a direita

2) Normalmente seriam necessários 2 buffers para a aplicação de um kernel: um para

guardar o estado anterior, e outro para guardar o novo estado após o cálculo de todos os

pixels. Uma observação cuidadosa do nosso kernel mostra que, para valores positivos de

L, este é causal, ou seja, ele só depende de valores “futuros” (se interpretarmos o índice K

como tempo). Desta maneira, é possível aplicá-lo diretamente sobre o buffer origem,




13

sobre-escrevendo os valores sem causar erros de cálculo, desde que comecemos a

aplicação pela posição zero e sigamos em direção ao maior valor de K.

Figura 10 – Ao calcular o valor de K, podemos substituí-lo diretamente no vetor pois K+1

(nem outra posição posterior a K) não depende de K.

3) O cálculo de K compartilha dois valores em comum com K+1, logo são necessários

apenas 2 acessos de leitura à memória para o cálculo de uma posição da matriz (já que

podemos reaproveitar 2 leituras).

Figura 11 – O cálculo de K+1 compartilha 2 elementos com o cálculo de K

No anexo 1 podemos ver o código original escrito em assembly x86. Ele pode ser dividido

em 3 partes:

a) A parte inicial que gera aleatoriamente valores 0 ou 255 na base do fogo (na verdade 0 ou

o valor passado pela pilha em [bp+4], mas que habitualmente é 255).

b) A parte que efetivamente calcula o kernel (que está duplicada pois o loop foi desenrolado)

c) A parte que copia os dados para a memória de vídeo

No nosso trabalho implementamos a parte 1 e a 2 (sem desenrolar o loop). Não foi

necessário implementar a parte 3 pois visualizamos o resultado do programa diretamente na

memória do processador. O anexo 2 contém o código fonte do programa implementado no

escapeDLX sem o uso de instruções específicas. O anexo 3 contém o código fonte do programa

com uma instrução de uso específica que faz o cálculo da aplicação do kernel.




14

4.1. – Descrição da Implementação

O escapeDLX implementa uma arquitetura Von Neumann, logo o programa e os dados

ficam no mesmo espaço de memória. Na figura 12 podemos ver este espaço de memória.

Efetuamos a seguinte divisão: do endereço 0x400 até o endereço 0x7ff foi organizada uma matriz

de words (32 bits cada) de 16x16 elementos. Estes foram os “pixels” da nossa implementação. A

linha de 0x7c0 até 0x7ff é a geradora, ou seja, onde os valores aleatórios (0 ou 32) são

introduzidos. Foi necessário diminuir o valor aleatório de 255 para 26, pois a matriz é pequena na

dimensão vertical, logo os dados não chegavam a zero antes de atingir o topo. O programa em si

começa na posição zero e termina por volta do endereço 0x0C0. A Word que começa em 0x3fc

guarda o “seed” do gerador de números aleatórios. A Word que começa em 0x3f8 é inicializada

em 0 e incrementada cada vez que o programa retorna ao seu início, logo pode ser usada para

determinar o número de ciclos necessários para gerar um frame.

Figura 12 – Memória do processador

A instrução que foi criada para acelerar o programa chama-se FILT e possui 2

argumentos: um registrador, que contém um ponteiro para a posição do buffer a ser calculada

(equivalente a K nos exemplos anteriores) e uma constante que representa o valor de L+1 (na

verdade 4L+4 já que os ponteiros do EscapeDLX são para bytes e nós escolhemos pixels da

largura de words de 32 bits). Esta instrução espera que os valores dos pixels já lidos na interação

anterior (K+L-1 e K+L) estejam em R2 e R3 respectivamente, enquanto o valor do pixel K é

carregado para R1 e o do pixel K+L+1 é carregado em R4. O valor final da computação é

entregue em R1.




15

5. Desempenho

O desempenho do programa foi medido em suas duas versões (com e sem a instrução

FILT) com diferentes penalidades de acesso a memória: 1 a 9 ciclos. Os resultados podem ser

vistos nas figuras 13 e 14.

Figura 13 – Comparação entre o número de ciclos dos 2 programas




16

Figura 14 – Percentual de aceleração entre os 2 programas

Podemos perceber que quanto mais lento é o acesso à memória, maior o ganho em

transportar a execução do algoritmo da memória principal para a memória de microprograma.

Todavia, os ganhos são cada vez menores.

6. Conclusão

Concluímos que a criação de instruções para a substituição de trechos de programas por

microcódigo pode acelerar enormemente uma aplicação, sobretudo quando a diferença de

performance entre a memória de programa e a memória de microprograma é grande. Neste

trabalho também foi possível aumentar nosso grau de familiarização com o conceito de

microprogramação através do estudo do simulador escapeDLX.




17

7. Anexo 1 – Fonte do programa original em assembly x86

_FIRE PROC NEAR

push bp

mov bp,sp

mov bx,300

chuta:

mov ax,[randseed]

mov dx,8405h

mul dx

inc ax

and dl,4

mov [randseed],ax

jz zero

mov cl,[bp+4]

mov matrix[bx+25285],cl ;0ffh

jmp cont

zero:

mov matrix[bx+25285],0

cont:

dec bx

cmp bx,0

jnz chuta

xor ax,ax

xor bx,bx

xor cx,cx

xor dx,dx

mov cl,matrix[319]

mov dl,matrix[320]

loop1:

mov al,matrix[bx]

add ax,cx

mov cl,matrix[bx+321]

add ax,dx

add ax,cx

shr ax,2

jz vazio

dec ax

vazio:

mov matrix[bx],al

inc bx




18

mov al,matrix[bx]

add ax,dx

mov dl,matrix[bx+321]

add ax,cx

add ax,dx

shr ax,2

jz vazio2

dec ax

vazio2:

mov matrix[bx],al

inc bx

cmp bx,25282

jne loop1

mov ax,0a000h

mov es,ax

mov si, offset matrix

mov di,39040

mov cx,12800

rep movsw

pop bp

ret

_FIRE ENDP




23

10. Anexo 4 – Tabela de Microcódigo com instrução FILT




24

11. Anexo 5 – Jump Table com instrução FILT

Trabalho de Microprogramação Utilizando Simulador Escape...

Documents

Transcript of Trabalho de Microprogramação Utilizando Simulador Escape...