Buscar

Trabalho Pratico 3 - 2014-1

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes
Você viu 3, do total de 5 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Prévia do material em texto

Universidade Federal de Minas Gerais
Instituto de Ciências Exatas
Departamento de Ciência da Computação
Disciplina Software Básico (DCC008) - 2014/1
Trabalho Prático 3 - Ligador
1 Descrição Geral
Este trabalho envolve a implementação de um editor de ligação, ou ligador, que seja capaz de receber
módulos objeto produzidos pelo montador construído no Trabalho Prático 2 (devidamente adaptado
para tal) e gerar, a partir desses módulos, um programa binário executável para a máquina básica
SimpleAcc (SA) construída no Trabalho Prático 1.
2 Informações Importantes
• O trabalho deve ser feito em duplas ou trios, podendo ser discutido entre cada grupo de alunos,
mas código fonte não pode ser compartilhado.
• A data de entrega será especificada através de uma tarefa no Moodle.
• Política de atrasos: os trabalhos poderão ser entregues até a meia-noite do dia especificado
para a entrega. O horário de entrega deve respeitar o relógio do sistema Moodle, ou seja, a
partir de 00:01 do dia seguinte à entrega no relógio do Moodle, os trabalhos já estarão sujeitos
a penalidades. O valor do trabalho irá decrementar 5% a cada hora de atraso. Para um aluno
que entregou o trabalho à 1:38, ou seja, com 1:38 de atraso, iremos descontar 10%, empregando
a fórmula a seguir:
Nota = valor_correção× (1− 0.05× horas_atraso)
• O trabalho deve ser implementado obrigatoriamente na linguagem C.
• Deverá ser entregue o código fonte com os arquivos de dados necessários para a execução e um
arquivo Makefile que permita a compilação do programa nas máquinas Linux do DCC.
• Além disso, deverá ser entregue uma pequena documentação contendo todas as decisões de projeto
que foram tomadas durante a implementação, sobre aspectos não contemplados na especificação,
assim como uma justificativa para essas decisões. Esse documento não precisa ser extenso (entre
3 e 5 páginas).
• A ênfase do trabalho está no funcionamento do sistema e não em aspectos de programação ou
interface com o usuário. Assim, não deverá haver tratamento de erros no programa de entrada.
• Todas as dúvidas referentes ao trabalho serão esclarecidas por meio do fórum disponível no
ambiente Moodle da disciplina.
• A entrega do trabalho deverá ser realizada pelo Moodle, na tarefa criada especificamente para
tal. As instruções de submissão, um arquivo de teste e o esqueleto da organização dos arquivos
estão presentes no arquivo “tp3_login1_login2[_login3].tar.gz”, disponível para download
no Moodle.
1
• Atenção: trabalhos que descumprirem esse padrão serão penalizados.
3 Especificação do Ligador
Os principais objetivos do editor de ligação a ser implementado neste trabalho são:
• Permitir relocação de programas: o endereço de carga do programa deve ser definido somente
após a tradução.
• Permitir tradução separada: os módulos de um programa são montados separadamente (gerando
módulos objeto) e depois combinados para formar um executável único.
Detalhes sobre a implementação:
• O montador implementado no Trabalho Prático 2 deverá ser modificado a fim de gerar informa-
ções que serão utilizadas pelo editor de ligação na relocação e ligação dos programas.
• O editor de ligação propriamente dito, capaz de combinar os diversos módulos (isto é, os proce-
dimentos ou sub-programas) de um programa da SA que foram montados independentemente,
deve ser implementado. Deve-se tomar cuidado para que, no momento da ligação, o trecho de
código correspondente à função principal, ou seja, o ponto de início do programa, esteja no início
do binário executável final produzido pelo ligador, de forma que o programa gerado possa ser
executado com o valor inicial do PC igual a zero. Não é necessário considerar situações em que
o PC seja iniciado com valor diferente de zero.
• Para a implementação do editor de ligação, o montador construído no Trabalho Prático 2 precisa
produzir informações adicionais. Além de não reportar erros no segundo passo da montagem
devido a símbolos desconhecidos, o montador deve produzir ao final, para cada programa es-
pecificado como entrada, um arquivo (módulo objeto) contendo tanto o código traduzido do
programa quanto sua tabela de símbolos. O arquivo gerado pelo montador, portanto, não é mais
um executável, mas um formato que servirá de entrada para o editor de ligação, o qual deve
realizar as 3 tarefas descritas no capítulo 7 do livro: alocação, ligação e relocação. Assim, o
ligador deve então produzir, a partir de 1 ou mais arquivos gerados pelo montador, 1 programa
executável único, em formato tal que possa ser carregado e executado pelo emulador do Trabalho
Prático 1.
• Deve-se considerar que todos os labels têm escopo global e, portanto, são visíveis para todos
os módulos objeto do mesmo programa. Isso implica também em considerar que nenhum label
poderá ser utilizado mais de uma vez no mesmo programa, devendo cada label aparecer somente
uma vez num único módulo do programa.
4 Descrição da Tarefa
A tarefa principal deste trabalho consiste em modificar o montador construído no Trabalho Prático 2
e implementar um editor de ligação para a SA, conforme especificado na Seção 3. Além dessa tarefa,
o seguinte programa de teste deverá ser também criado, contendo obrigatoriamente mais de um
módulo:
• Calculadora: programa que lê três números (A, B, C ) e realiza uma operação de adição,
subtração, multiplicação, divisão inteira (imprimindo o quociente e o resto) ou exponenciação
(somente com expoente ≥ 0), sendo que:
– B é a operação a ser realizada: B=1 → adição; B=2 → subtração; B=3 → multiplicação;
B=4 → divisão inteira (imprimindo o quociente e o resto); B=5 → exponenciação.
2
– A e C são os valores sobre os quais a operação será realizada. Nesse caso, temos então:
∗ A 1 C = A+ C
∗ A 2 C = A− C
∗ A 3 C = A× C
∗ A 4 C = A/C
∗ A 5 C = AC
– Depois de ler os números, o programa imprime apenas o resultado da operação.
– Cada operação deve ser implementada em um módulo diferente.
A implementação desse programa de teste será avaliada, portanto o código dele não deve ser comparti-
lhado entre os grupos. Por outro lado, outros programas de teste adicionais podem ser compartilhados.
Lembre-se de colocar todos os testes (inclusive o obrigatório) no diretório “tst/” e de explicá-los em
sua documentação.
Atenção: note que na submissão deste trabalho deverão constar os códigos das três ferramentas – o
emulador (TP1), o montador modificado (TP2 e TP3) e o ligador (TP3) – implementadas ao longo do
semestre, de maneira a ser possível estabelecer um fluxo de tradução, ligação e execução.
5 Formato da Entrada de Dados
O formato do arquivo de entrada do montador modificado é exatamente igual ao formato utilizado no
montador original, implementado no Trabalho Prático 2. A entrada do editor de ligação deve seguir
algum formato intermediário, especificado pelos alunos do grupo, que combine o código de máquina
do programa traduzido com as informações geradas pelo montador modificado a respeito dos símbolos
encontrados no programa. A especificação desse formato deve constar na documentação do trabalho.
Para um teste inicial do seu editor de ligação, utilize o programa abaixo, cujos arquivos estão disponíveis
no diretório “tst/” no pacote do trabalho. O programa pede dois inteiros, imprimes os dois na ordem
em que foram informados e depois imprime o maior deles.
Atenção: tal programa não testa todas as instruções e não deve ser utilizado como único teste do
editor de ligação.
Programa principal contido no arquivo tp3teste1main.msa:
READ
STORE A
READ
STORE B
LOAD ZERO
CALL CALC
HALT
A: WORD 0
B: WORD 0
ZERO: WORD 0
END
Módulo de cálculo contido no arquivo tp3teste1calc.msa:
CALC: LOAD B
COPY R4
LOAD A
3
SUB R4
JN MB
MA: LOAD A
COPY R3
JMP OK
MB: XCH R4
COPY R3
LOAD A
OK: WRITE
LOAD B
WRITE
XCH R3
WRITE
RET
END
6 Formato da Saída de Dados
A saída doeditor de ligação é um programa binário executável em formato tal que possa ser carregado
e executado pelo emulador do Trabalho Prático 1.
Já o formato de saída do montador modificado deverá ser especificado por cada grupo como decisão
de projeto. Basicamente, deverá ser levado em conta o fato de que o montador modificado precisa
disponibilizar para o ligador tanto o código traduzido quanto informações necessárias para o processo
de ligação.
7 Formato de Chamada do Ligador
O editor de ligação receberá no mínimo N + 1 argumentos quando de sua chamada:
• N nomes de arquivos de entrada contendo os módulos objeto a serem ligados. Parâmetros
obrigatórios, informados como os N primeiros argumentos na chamada do ligador.
• Nome do arquivo que contém o programa principal. Parâmetro obrigatório informado por meio
da opção -m na linha de comando.
• Nome do arquivo de saída do editor de ligação. Parâmetro opcional informado por meio da opção
-o na linha de comando. Caso não seja informado, o ligador deve produzir um arquivo com o
nome exec.sa no mesmo diretório do executável do ligador.
Exemplo:
./ligador modulo1.osa modulo2.osa modulo3.osa -m main.osa -o programa.sa
A chamada acima tem a seguinte semântica: executar o editor de ligação para relocar e ligar os
módulos objeto contidos nos arquivos (modulo1.osa, modulo2.osa, modulo3.osa e main.osa), sendo
que o arquivo main.osa contém o programa principal. A saída deve ser escrita no arquivo programa.sa.
Note que a única saída de dados do ligador é o programa binário executável gerado. Não é necessário
imprimir informações na tela.
A saída do editor de ligação deve ser executada no emulador da SA para garantir que o programa foi
traduzido corretamente.
4
8 Sobre a Documentação
• Deve conter todas as decisões de projeto, em especial a especificação do formato definido para
os módulos objeto produzidos pelo montador modificado.
• Deve conter informações sobre como executar o ligador. Obs: é necessário cumprir os forma-
tos definidos acima para a execução, mas tais informações devem estar presentes também na
documentação.
• Deve conter elementos que comprovem que o ligador foi testado (ex: imagens das telas de execu-
ção). Os arquivos relativos a testes devem ser enviados no pacote do trabalho. A documentação
deve conter referências a esses arquivos, explicação do que eles fazem e dos resultados obtidos.
• O código fonte não deve ser incluído no arquivo de documentação.
9 Considerações Finais
As decisões de projeto devem fazer parte apenas da estrutura interna do montador modificado e
do ligador, não podendo afetar a interface de entrada e saída, com exceção da saída do montador
modificado, que será baseada em uma decisão particular de projeto.
Após a implementação deste trabalho, tem-se um conjunto de ferramentas com as quais é possível
escrever um programa em uma linguagem de montagem e traduzí-lo para a linguagem de máquina
reconhecida pela SimpleAcc, seguindo os passos abaixo:
1. Executar o Montador em cada um dos módulos do programa.
2. Executar o Ligador para os módulos objeto obtidos no passo anterior, produzindo, assim, o
programa binário executável único.
3. Executar o Emulador, tendo como entrada o programa binário executável gerado pelo ligador.
A Figura 1 mostra o fluxo esquemático dessas operações.
Figura 1: Fluxo de operação das ferramentas implementadas nos trabalhos práticos da disciplina.
As extensões dos arquivos são apenas convenções para facilitar a identificação dos tipos de arquivos.
No caso do exemplo da figura, as extensões são:
• .msa: arquivo com programa em linguagem de montagem da SimpleAcc.
• .osa: arquivo intermediário (módulo objeto) gerado pelo montador modificado e que deve ser lido
pelo editor de ligação. Esse formato deve ser especificado pelos alunos do grupo e devidamente
documentado.
• .sa: arquivo binário da SA que deve ser executado pelo emulador.
5

Continue navegando