Projecto
Objectivos
| Regulamento
| Tema
| Fase1,
Fase2 |
Submissão
Ultima Modificação:
16 Jun 2008
| departamento
de informática |
 |
Notas
-
Resultados da Fase 2:
como se esperava, todos conseguiram ultrapassar esta 2ª fase, e ninguém ficou
excluído da avaliação da componente teórica (teste ou exame), apesar de
aparecerem algumas notas "negativas"; eis a pauta com os resultados. (16-Jun-08)
-
Submissão e defesa da Fase 2:
já está disponível o processo de submissão de
trabalhos para a Fase 2 na plataforma de e-learning da UM (em
http://elearning.uminho.pt/),
na UC de Sistemas de Computação;
avisos:
a data de
submissão foi adiada para a meia-noite de quarta 11-Junho,
e as defesas do trabalho entregue realizar-se-ão na sexta 13-Junho, 14h-17h, num
laboratório do DI. (03-Jun-08)
-
Resultados da Fase
1: o nível geral ficou aquém do esperado e possível pela maioria
dos estudantes: apenas 1 grupo teve "Bom" (ver graus no
Regulamento), a grande maioria ficou com "Razoável",
houve 2 grupos com "Fraco" (i.e., entre 8 e 10) e vários grupos ou elementos de
grupos com "NA" (um elemento com "0, vários muito fracos com "3" e os restantes
entre o "5" e o "7"); de notar que esta avaliação é apenas da Fase 1, e que esta
Fase em princípio tem um peso da ordem dos 50% do total; assim, nenhum destes
elementos está impedido de vir defender a 2ª fase. A excepção, pela negativa,
está nos 2 grupos que deliberadamente cometeram
FRAUDE, e como tal ficaram automaticamente com
a classificação final de "Não Admitido"
(decidi não avançar com maior penalização); eis a
pauta com os resultados. (26-Mai-08)
-
Problemas com a submissão de trabalhos: alguns colegas vossos relataram dificuldades no upload
dos ficheiros a partir de algumas distribuições do Linux; recomenda-se que
estejam preparados para na hora poderem submeter em sistema operativo
alternativo.
(06-Mai-08)
-
Sobre o texto desta página:
parte da informação ainda é provisória, e quando tal acontecer o texto aparecerá
a cinza claro.
(10-Abr-08)
-
Responsabilidade do Projecto: a elaboração do texto deste projecto é da
responsabilidade da equipa docente de SC, mas a apresentação do tema é da
responsabilidade conjunta dos docentes das UCs Sistemas de Computação e de
Programação Imperativa (a apresentação do tema em PI está em
http://www.di.uminho.pt/~jcr/AULAS/pi2008/tp2/tp2-pi2008.html); este tema é inspirado em trabalhos
pedagógicos desenvolvidos no DI nos
anos 80 e 90 do século passado.
(08-Abr-08)
Objectivos de formação e resultados
de aprendizagem
Este projecto tem como objectivos principais a
formação genérica e específica dos estudantes inscritos em sistemas de computação.
Alguma da informação pertinente ao funcionamento deste Projecto será partilhada
com o Projecto da UC a funcionar em paralelo, Programação Imperativa.
Os objectivos de formação genérica incluem:
(i) a pesquisa, análise e selecção de informação, (ii) o treino de
trabalho de grupo na resolução de problemas, (iii) o desenvolvimento da
capacidade de análise e compreensão de textos em língua inglesa, e (iv) o
desenvolvimento da capacidade de comunicação escrita e oral.
Os objectivos de formação específica incluem:
(i) a análise de problemas no desenvolvimento de uma ISA orientada à
stack e a especificação da solução, (ii) o
desenvolvimento de ferramentas de apoio à programação em baixo nível de uma
máquina virtual, (iii) a realização de testes de conformidade, e
(iv) a construção parcial de um interpretador de bytecodes da
máquina virtual MSP para uma dada arquitectura de computadores (IA-32).
A avaliação dos resultados esperados de
aprendizagem irão verificar se as/os estudantes conseguem demonstrar ter
adquirido o seguinte conjunto de competências genéricas e específicas:
- competências genéricas
- a capacidade de trabalho em
grupo e respectiva comunicação efectiva e eficiente entre os elementos do
grupo
- a capacidade de comunicação
escrita e oral na apresentação e discussão dos processos usados e resultados
obtidos
- a capacidade de utilização
de ferramentas genéricas de informática em ambiente Linux e de elaboração de
documentos anotados
- competências específicas
- a capacidade de analisar o
modelo básico de funcionamento de uma Instruction Set Architecture
(ISA) orientado à stack (MSP), com
o objectivo de permitir o manuseamento de bytecodes
- a aptidão para
desenvolver ferramentas de apoio à programação em baixo nível do MSP
- capacidades e aptidões para
desenvolver uma máquina virtual para a interpretação de código MSP, usando
directamente código da arquitectura ISA do IA-32
Regulamento
Caracterização do Projecto
- O projecto consiste na realização de um
ou mais trabalhos práticos em grupo, com
entrega faseada de resultados.
- A
não aprovação no projecto conduz à classificação de "Não Admitido" na pauta
final de exame.
- O projecto deverá ser submetido através da
plataforma de e-learning da UM, na parte de
Assignment da UC. Para
mais detalhes sobre a formatação a apresentar consultar a descrição da fase.
- Material de apoio à produção de documentos em LaTeX,
elaborado por Alberto Simões:
Mini-curso de LaTeX e
Manual de LaTeX.
- Os resultados do projecto serão avaliados em 2
fases distintas ao longo do semestre: nas semanas 10 / 11 e na semana 15 (datas indicadas
adiante).
O Projecto como trabalho de grupo
- O projecto deverá ser realizado por grupos de
3 elementos. Em casos excepcionais, devidamente justificados
e aceites pelo docente responsável, será possível
a realização do projecto com menos elementos.
- A organização, planeamento e coordenação das
actividades do trabalho de grupo é da inteira responsabilidade dos seus
elementos. Os slides apresentados na sessão de apresentação de SC
estão aqui disponíveis.
Metodologia de avaliação do Projecto
- A avaliação do projecto consiste na
verificação da aquisição individual dos conhecimentos, capacidades e aptidões
especificadas no enunciado do trabalho, e decorrerá num laboratório do DI.
- Os elementos que serão utilizados na avaliação
incluem:
- O relatório: (i) a versão
electrónica deverá ser submetida no prazo especificado, e (ii) a versão
impressa deverá acompanhar o grupo durante a defesa do trabalho (quando
houver).
- Eventual apresentação formal oral (tarefa a
definir explicitamente no enunciado).
- O programa desenvolvido de acordo com as
especificações, em condições de ser apresentado (não são admitidos erros de
compilação), e respectiva bateria de testes.
- A defesa do trabalho junto a
um computador, durante um tempo
estimado de 20 min, que poderá ser individual ou em grupo.
- Calendário para a entrega dos relatórios em formato electrónico:
- Fase 1, quarta, 07-Mai-08, 12h00.
- Fase 2, segunda, 09-Jun-08,
12h00
- Calendário para a realização das defesas dos
trabalhos:
- Fase 1: sexta 09-Mai-08 (14h00-17h00) e
durante a semana seguinte (em dia e hora a combinar)
- Fase 2:
no horário das sessões
laboratoriais, na semana de 09-Jun-08 (as sessões de terça, feriado, são
transferidas para quarta 11-Jun-08, 14h00 - 17h00)
- A ordem de defesa dos trabalhos é coincidente
com a ordem de inscrição dos grupos, e será atempadamente divulgada.
- A classificação final do projecto será, em
princípio, por patamares, sendo os definidos para SC os seguintes:
- Não Aprovado - não
apresentação de projecto ou resultados com um nível elevado de insatisfação
de requisitos.
- Fraco (<10) - com
diversas falhas, mas que não inviabiliza a admissão a exame (lacunas
sérias em conhecimentos ou na utilização de ferramentas, deficiências graves
no programa apresentado, ... )
- Aprovado (10) - cumpre, no
limite, os requisitos mínimos especificados nos resultados de aprendizagem
(embora com questões relevantes que não estejam correctas)
- Razoável (entre 11 e 14) -
cumpre razoavelmente os requisitos especificados nos resultados de
aprendizagem
- Bom (entre 15 e 18) -
cumpre bem os requisitos especificados nos resultados de aprendizagem
- Excelente (19 ou 20) -
excede os requisitos especificados nos resultados de aprendizagem
- Os pesos relativos da avaliação de cada uma das fases em SC são os
seguintes:
- Fase 1: 45% .
- Fase 2: 55% .
- Para cada uma das fases de avaliação do
projecto os grupos serão atempadamente informados do seu desempenho, com feedback
adequado para melhorarem os seus resultados, de acordo com um modelo de
classificação similar.
- A classificação individual final será um valor
de compromisso entre a classificação obtida pelo grupo no projecto e a
impressão individual que cada elemento produziu nas equipas de examinadores
e a opinião manifestada por todos os elementos do grupo de trabalho.
- Caso sejam detectadas situações fraudulentas
(desde plágio de outro grupo ou de um outro qualquer local, a comportamento
fraudulento de um dos elementos do grupo), as partes envolvidas ficarão
sujeitas a acções ou procedimentos disciplinares seguindo a hierarquia
institucional e de acordo com a gravidade demonstrada. Recomenda-se a
leitura do documento de
reflexão
produzido na sequência das irregularidades ocorridas em 2004/05, em que
vários estudantes comprometeram a sua carreira de estudante com a
reprovação às 2 disciplinas que na altura integravam o projecto (para além dos procedimentos
disciplinares).
- Dúvidas que surjam na sequência de
ambiguidades ou lacunas no enunciado do projecto e/ou deste regulamento,
deverão ser colocadas ao docente responsável,
preferencialmente por email. Quando necessário, o esclarecimento dessas
situações far-se-á por inclusão de um aviso na página Web da
disciplina.
Topo...
Tema: "Mais Simples Possível (MSP)"
Introdução
O tema escolhido para este projecto foi o da criação de uma
Virtual Stack Machine (VSM), mais concretamente:
- o ambiente de manuseamento do instruction set
(em binário); e
- a execução de programas codificados em bytecodes
numa plataforma IA-32 (i.e., uma implementação da VSM).
A VSM poderá ser programada em assembly usando uma
notação muito simples definida para este contexto, o MSP.
O MSP é uma linguagem simples, com um número de instruções reduzido e com
uma sintaxe e uma semântica bastante acessíveis. Como se verá mais à frente,
a VSM não tem registos visíveis ao programador e recorre a uma stack
para a realização das operações lógicas e aritméticas.
A existência de um assembler que monte em binário (o bytecode)
um programa "executável" (para posterior execução numa VSM em plataforma
IA-32, por ex.), poderá ser um dos resultados do projecto paralelo em Programação
Imperativa.
Este trabalho será dividido em duas fases:
- a primeira fase
será para desenvolver um "comando" semelhante ao
objdump -d <nome_ficheiro>
do Linux (pode ser vsmobjdump -d <nome_ficheiro>);
- a segunda fase será para criar uma VSM, i.e., uma
máquina virtual (uma aplicação de software) que leia um ficheiro com
código "executável" da VSM e que o interprete, i.e., para cada linha de
código (com 1 ou mais bytes) gera uma ou mais linhas de
código IA-32 e executa-las de imediato.
Arquitectura da VSM
Numa VSM podem-se identificar os seguintes blocos
(representados na figura em baixo):
- Memória
Área lógica para armazenamento de instruções e
valores; divide-se em 3 blocos independentes com funcionalidades
distintas:
- Memória de Programa (ou
abreviadamente MProg);
- Memória de Dados (ou
MDados);
- Memória de Trabalho (Stack ou
Pilha).
- Descodificador
Unidade encarregue de interpretar e mandar executar
cada instrução.
- Unidade Lógica e Aritmética
Unidade que tem a responsabilidade de efectuar as
operações lógicas e aritméticas.
- Input e Output
São dois pares de posições de memória especiais, com endereços
fixos e bem conhecidos: um para para
input
e outro par para output; Têm a característica especial de estarem ligadas ao
exterior, permitindo a entrada de valores para a VSM (input) e a saída de valores da
VSM (output); em concreto, estas células de memória estão
logicamente ligadas ao
teclado (input) e ao monitor (output).
- Bus Interno
É o "corredor" lógico que liga as várias unidades,
permitindo a circulação e comunicação de instruções e valores.
- Instruction Pointer
(IP) e Stack
Pointer (SP)
São os únicos registos da VSM. O IP contém,
em cada instante, o endereço da próxima instrução a ser
executada (um endereço de MProg). O SP contém o endereço da última posição
ocupada na stack (ou seja, o endereço inicial do valor no topo da
stack).
Cada célula de memória (na
MProg,
MDados ou na
Stack) tem
capacidade para armazenar um byte e está associada a um endereço que a identifica
univocamente.
Um endereço é um número inteiro sem sinal, representado
com 16 bits.
A gama de
endereços possíveis na VSM está no
intervalo [0, 64k[ (i.e., em [0,
65535] ).
O byte que é armazenado em determinada célula de memória pode
representar uma instrução,
parte de um argumento de uma instrução,
parte de um valor
inteiro (representado
por 16 bits, em complemento para 2), parte de um carácter,
parte de um valor Booleano (Verdadeiro
ou Falso) ou
um componente de um endereço.
A interpretação do significado de cada byte
depende da memória que está a ser acedida:
-
Memória de Programa (MProg)
A
MProg armazena as instruções que vão ser executadas pela
máquina. Um programa é uma sequência de instruções armazenadas na
MProg.
Uma célula da
MProg pode conter o
código de operação de uma instrução (opcode) ou o argumento de
uma instrução. O argumento, quando
existir, localiza-se na posição seguinte à do opcode da instrução.
A organização da
MProg é little endian, i.e., o endereço com menor valor contém o
byte menos significativo (LSB) de um valor de 2 bytes.
- Memória de Dados (MDados)
A
MDados armazena dados
do problema (inclui resultados de cálculos) ou endereços de memória.
Cada valor
armazenado ocupa 2 bytes, podendo representar
(i) inteiros em complemento para 2, no intervalo
[-32k, +32k[, ou (ii) caracteres (pelo seu código ASCII,
colocado na célula com endereço menor), ou (iii)
valores Booleanos (Verdadeiro
ou Falso, sendo Falso representado pelo valor
0
e Verdadeiro por qualquer outra combinação de bits), ou ainda
(iv) endereços de células da MDados.
A organização da MDados
é little endian,
i.e., o endereço com menor valor contém o byte menos
significativo (LSB) de um valor de 2 bytes.>
- Stack ou Pilha
A memória de trabalho
Stack tem conteúdo semelhante à
MDados,
e também é little endian.
Contudo, é acedida e usada segundo uma filosofia LIFO (Last In First
Out): os valores que vão introduzindo na
Stack ficam empilhados uns por cima dos outros, de tal forma
que apenas se pode aceder de modo implícito (ler, consultar) o valor que está no cimo
(topo) da
Stack, e que corresponde ao último valor que lá foi
armazenado. Assim, apenas é necessário conhecer um único endereço: o que
aponta para a célula no topo da
Stack, i.e., o stack pointer
(SP).
O próximo byte a
guardar na
Stack será armazenado no endereço acima do topo, e o
primeiro byte a sair será sempre o do topo. A VSM foi desenhada de tal forma que as operações
aritméticas e lógicas esperam
ter os seus operandos armazenados em posições consecutivas a partir do
topo. Durante a execução de uma operação destas, os operandos são
retirados da
Stack (actualizando-se o stack pointer) e o resultado
da operação é guardado de volta no topo da
Stack (actualizando-se
também o seu apontador). Na VSM o topo "cresce do fim para o princípio", ou seja, do
último endereço disponível (64k-1) em direcção ao primeiro (0).
Para um programa ser executado, o
IP é carregado com o
endereço de
MProg onde está a primeira instrução a ser executada e
entra-se no seguinte ciclo de funcionamento da VSM:
buscar a próxima instrução (apenas 1 byte), actualizar o
IP para
ficar a apontar para a célula seguinte, descodificar a instrução (se
forem precisos mais bytes, vai-se buscar um de cada vez,
actualizando-se logo o
IP), e executar a operação especificada no
opcode com o(s) operando(s) especificados na resto da instrução (se
os houver).
Este processo continua até que seja executada a instrução
que manda parar a execução do programa.
Linguagem MSP
A sintaxe e semântica da linguagem MSP contém referências às componentes
de código e de dados. A informação no sítio de PI (
http://www.di.uminho.pt/~jcr/AULAS/pi2008/tp2/tp2-pi2008.html)
contém informações sobre a componente de dados, que poderão não ser
relevantes para SC (se forem, serão posteriormente inseridas aqui).
Assim, apenas iremos incluir aqui a lista das instruções disponíveis no
MSP.
O conjunto das instruções do MSP pode ser dividido em três grupos
de acordo com as respectivas funcionalidades: (i) instruções para
movimentação de valores e endereços, (ii) operações aritméticas e
lógicas, e (iii) instruções de controlo da sequência de execução
do programa.
**********Movimentação de valores e endereços**********
- LOAD
- Retira da
Stack um endereço da
MDados
e vai buscar o
conteúdo dessa posição de memória e da seguinte, para colocar no
topo da
Stack
- STORE
- Retira da
Stack um valor, depois um endereço, e coloca na
posição da
MDados
referente ao endereço, o valor retirado
inicialmente da
Stack
- PUSH [valor]
- Coloca o valor de 16 bits no topo da
Stack; tem como
objectivo introduzir uma constante (valor imediato) no VSM
- IN
- Coloca no topo da
Stack o conteúdo da posição especial
input,
resultante da leitura de um valor inteiro via teclado
- OUT
- Retira do topo da Stack um valor e coloca-o na posição
especial
output,
para escrever no monitor esse valor como inteiro
- INC
- Coloca no topo da Stack o conteúdo da posição especial
input,
resultante da leitura de um um carácter via teclado,
em que o byte com o código ASCII foi colocado na célula com
endereço menor
- OUTC
- Retira do topo da Stack um valor e coloca-o na posição
especial output,
para escrever no monitor o carácter cujo código ASCII
se encontra na célula com o endereço menor
**********Operações aritméticas e lógicas**********
ADD
Retira dois inteiros da Stack , soma-os e coloca na
Stack o resultado
SUB
Retira dois inteiros da Stack , subtrai o valor do segundo
operando (no topo da
Stack) ao do primeiro e coloca na
Stack o resultado
MUL
Retira dois inteiros da Stack , multiplica-os (resultado
em 16 bits) e coloca na Stack o resultado
DIV
Retira dois inteiros da Stack , divide o primeiro pelo
segundo e coloca na Stack o quociente (truncado)
ADDA
Retira da Stack um inteiro (em complemento para 2) e um
endereço (um valor sem sinal); soma o inteiro ao endereço,
calculando um novo endereço (um valor sem sinal), que é por fim
colocado na Stack
AND
Retira dois inteiros da Stack , calcula a sua conjunção
lógica e coloca na Stack o resultado (equivalente ao operador
&&
em C)
OR
Retira dois inteiros da Stack , calcula a sua disjunção
lógica e coloca na Stack o resultado (equivalente ao operador
||
em C)
NOT
Retira um inteiro da Stack , calcula a sua negação lógica
e coloca na Stack o resultado (equivalente ao operador
! em C)
EQ
Retira dois inteiros da Stack , verifica se são iguais e
coloca na Stack o resultado da comparação (Verdadeiro
ou Falso)
NE
Retira dois inteiros da Stack , verifica se são diferentes
e coloca na Stack o resultado da comparação (Verdadeiro
ou Falso)
LT
Retira dois inteiros da Stack , verifica se o primeiro é
menor que o segundo e coloca na
Stack o resultado dessa
comparação
LE
Retira dois inteiros da Stack , verifica se o primeiro é
menor ou igual que o segundo e coloca na
Stack o resultado
dessa comparação
GT
Retira dois inteiros da Stack , verifica se o primeiro é
maior que o segundo e coloca na
Stack o resultado dessa
comparação
GE
Retira dois inteiros da Stack , verifica se o primeiro é
maior ou igual que o segundo e coloca na
Stack o resultado
dessa comparação
ANDB
Retira dois inteiros da Stack , calcula a sua conjunção
bit a bit e coloca na Stack o resultado (equivalente ao
operador & em C)
ORB
Retira dois inteiros da Stack , calcula a sua disjunção
bit a bit e coloca na Stack o resultado (equivalente ao
operador | em C)
NOTB
Retira um inteiro da Stack , calcula a sua negação bit a
bit e coloca na Stack o resultado (equivalente ao operador
~
em C)
Observação: nas operações binárias (com 2 operandos),
sempre que se refere ao 1º e ao 2º operando, o 1º é o que foi
primeiro colocado na Stack , e o 2º é que foi colocado por
último.
**********Controlo do fluxo de execução**********
- JMP [id-label ou endereço ou
endereço-relativo]
- Salta incondicionalmente para o endereço calculado a partir do
argumento (i.e., coloca em
IP
esse endereço); a execução do programa
continua com o código armazenado no endereço da
MProg
especificado
por id-label, ou no
endereço (em valor absoluto
relativo ao início da MProg) ou somando ao
IP
o
endereço-relativo passado
como argumento; neste último caso, o valor do argumento deverá
obrigatoriamente conter o sinal
+
ou -
antes do valor numérico
- JMPT [id-label ou endereço ou
endereço-relativo]
- Retira o valor no topo da stack e testa-o (assumindo que
lá está um valor Booleano): se for
Verdadeiro (
True) salta para o endereço calculado a partir do argumento; se for
Falso
a execução continua na instrução apontada pelo valor do
IP
- CALL [id-label ou endereço ou
endereço-relativo]
- Guarda na stack o endereço da instrução que se lhe segue
(i.e., o valor de
IP) e prossegue com um salto incondicional para o
endereço calculado a partir do argumento (i.e., invoca
incondicionalmente uma subrotina)
- RET
- Regressa da subrotina: a execução do programa continua na
instrução que está no endereço que é retirado do topo da
Stack
- HALT
- Pára a execução do programa
- NOOP
- Não faz nada, serve apenas para gastar tempo...
Observação: a instrução HALT
deve ser usada para terminar os programas.
Formato binário das instruções MSP
O código executável da VSM é constituído por sequências de
bytes
(o
bytecode), cujo formato binário do
opcode é o seguinte:
- 3 primeiros bits,
000 se
fôr uma instrução de apenas 1 byte,
100 se
necessitar de um argumento (2 bytes adicionais);
- 5 bits menos significativos, (XXX
YY):
| XXX
\ YY |
00 |
01 |
10 |
11 |
| 000 |
ADD |
SUB |
MUL |
DIV |
| 001 |
AND |
OR |
NOT |
EQ |
| 010 |
ANDB |
ORB |
NOTB |
NE |
| 011 |
LE |
LT |
GE |
GT |
| 100 |
ADDA |
LOAD |
STORE |
RET |
| 101 |
IN |
INC |
OUT |
OUTC |
| 110 |
PUSH |
JMPR |
JMP |
CALL |
| 111 |
NOOP |
JMPRT |
JMPT |
HALT |
Observação: as
instruções de salto com a letra "R"
no fim indicam que são um salto para um endereço relativo, distinção
que não é feita na linguagem MSP.
Topo...
Objectivo funcional da Fase1:
Analisar uma linguagem assembly (MSP) e
desenvolver um programa que desmonte o bytecode de programas da VSM
(i.e., um disassembler).
Descrição mais detalhada das tarefas da Fase1 (lista
das Oobrigatórias e das Vopcionais/valorativas):
- OCompletar a especificação da
linguagem MSP, construindo uma tabela contendo o mesmo tipo de informação
que a tabela disponibilizada no fim do Anexo C da documentação entregue no
início do semestre (em
ISC).
Esta tabela deverá ser entregue em formato electrónico, na versão original
em que for feita (LaTeX, Word, ...) e em PDF.
- OConstruir
um disassembler do bytecode da VSM: elaborar em C um "comando"
Linux com funcionalidade semelhante a "objdump -d <nome_ficheiro>
> <nome_ficheiro_resultado>",
o qual deverá ser invocado com a seguinte sintaxe:
vsmobjdump -d <nome_ficheiro>
[-o <nome_ficheiro_resultado>]. Deverão ser
entregues os ficheiros contendo o código fonte, a makefile,
o
ficheiro_resultado
e o código executável. Para se ter uma ideia do pretendido, eis o
exemplo de um programa em MSP (não é o código
fonte pretendido!), o executável correspondente,
e o que se espera ter como ficheiro_resultado.
- OValidar o código do
disassembler com os ficheiros de teste disponibilizados (com vários
graus de validação): grau1,
grau2 e grau3.
Apresentar uma listagem dos códigos desmontados para cada um dos testes.
- VAnalisar o código dos testes e tentar com reverse
engineering, obter o possível código fonte em C que teria originado
esses ficheiros de teste. Apresentar o resultado num ficheiro de texto.
- VPropor um novo programa de teste do disassembler
e apresentar: (i) um texto curto explicitando que funcionalidades são
testadas, (ii) a versão em C do programa de teste, (iii) a
versão em MSP do mesmo programa e (iv) uma listagem do executável do
mesmo programa, em binário.
- OElaborar um relatório de grupo,
máx. 2 páginas, contendo as seguintes informações: (i) curso/UC/ano
lectivo, (ii) identificação da Fase do projecto, (iii)
identificação dos membros da equipa, (iv) estratégia de divisão de
trabalho pelos membros do grupo e grau de responsabilização de cada
elemento, e (v) análise crítica do tema do projecto e da sua
realização nesta fase.
Informação adicional:
- a realização das tarefas obrigatórias é indispensável para admissão a
exame;
- o conjunto de documentos solicitados obrigatórios (relatório
de grupo, tabela nos 2 formatos,
ficheiros do disassembler, e
listagem do código desmontado) deverá ser
entregue em formato compactado ZIP, num único ficheiro, com a
seguinte designação:
<SC08_leader>,
em que leader
é o nº do coordenador do grupo;
- a tarefa 5 (e apenas esta) pode ser
entregue para avaliação individual, num outro ficheiro compactado com a seguinte
designação:
<SC08V_nºaluno>.
Topo...
Objectivo funcional da Fase2:
O desenvolvimento de uma máquina
virtual, o SVM, que interprete o bytecode de um programa, e que gere e
execute, de modo controlado, o correspondente código IA-32.
Descrição mais detalhada das tarefas da Fase2 (lista
das Oobrigatórias e das Vopcionais/valorativas):
- OConstruir
uma máquina virtual com depurador, para execução do bytecode da VSM:
elaborar em C um "comando" Linux inspirado no
gdb, o
qual deverá ser invocado com a sintaxe
vsmdb <nome_ficheiro>
e suportar os seguintes comandos:
- disas: desmontar o
bytecode, i.e., aproveitar o código desenvolvido na
Fase1 e integrá-lo aqui.
- init [size_Stack]:
inicializar a execução de qualquer bytecode, terminando também
alguma execução prévia do bytecode; se o
size_Stack não fôr
explicitado, assume que a Stack
irá ter reservado 4k bytes de células; prepara as estruturas de
dados internas do MSP, inicializando a
MProg com o bytecode
do ficheiro indicado, a MDados
com as variáveis globais do programa, o
IP com o valor
0, o
SP com o valor adequado, e
INPUT e
OUTPUT inicializado a
0.
- stepi:
equivalente ao
stepi do
gdb;
executa apenas uma instrução do bytecode, e no fim mostra no
monitor a instrução MSP que acabou de executar.
- print <arg>:
mostra no monitor
o valor em decimal do conteúdo de 16-bits especificado em
<arg>;
este pode ser um dos seguintes valores:
IP
/ SP
/ INPUT
/ OUTPUT
/ MProg_address
/ MData_address
/ Stack_address;
a notação para estes endereços é a mesma que no
gdb.
- printx <arg>:
semelhante ao
anterior, mas mostra no monitor o valor em hexadecimal.
- xb <arg1>,
<arg2>:
examina o conteúdo de
MProg,
MDados
ou Stack
, mostrando no monitor, em hexadecimal, o conteúdo
de <arg1>
bytes a partir do endereço especificado em
<arg2>.
- xv <arg1>,
<arg2>:
semelhante ao anterior, mas
examina conjuntos de <arg1>
valores de 16-bits, considerando que este se encontra armazenado em
little-endian.
- VEnriquecer o
vsmdb <nome_ficheiro>
com os seguintes comandos:
- run:
semelhante ao
gdb;
executa o bytecode depois de inicializado, até encontrar um
breakpoint ou até encontrar a instrução
halt.
- break
<MProg_address>:
semelhante ao
gdb.
- delete <arg>:
semelhante ao
gdb;
- OTestar o funcionamento da máquina virtual com os ficheiros de teste disponibilizados (com vários
graus de validação): grau1,
grau2 e grau3.
Analisar:
- O conteúdo dos registos
IP
e SP
bem como das células da MDados
e da Stack
que foram afectadas com a instrução, após a execução de cada instrução do
bytecode; esta tarefa deverá ser feita usando os comandos de
vsmdb e será avaliada na defesa
oral da Fase2.
- O código assembler gerado pelo
gcc para a interpretação de
cada uma das instruções do MSP presentes no bytecode; esta tarefa
será avaliada na defesa oral da Fase2.
OEntregar os
ficheiros contendo o código fonte e a makefile.
VAnalisar o código assembly IA-32 gerado pelo
compilador para o controlo de execução do bytecode passo a passo, e
apresentar uma listagem com a parte desse código, devidamente anotado, que
implementa a execução de pelo menos 3 instruções presentes nos códigos
fornecidos (uma de transferência de informação, outra aritmética e outra de
controlo de fluxo de execução) .
OElaborar um relatório de grupo,
máx. 2 páginas, contendo as seguintes informações: (i) curso/UC/ano
lectivo, (ii) identificação da Fase do projecto, (iii)
identificação dos membros da equipa, (iv) estratégia de divisão de
trabalho pelos membros do grupo e grau de responsabilização de cada
elemento, e (v) análise crítica do tema do projecto e da sua
realização nesta fase.
Informação adicional:
- a realização das tarefas obrigatórias é indispensável para admissão a
exame;
- o conjunto de documentos solicitados obrigatórios (relatório
de grupo e
listagem do código desenvolvido) deverá ser
entregue em formato compactado ZIP, num único ficheiro, com a
seguinte designação:
<SC08_leader>,
em que leader
é o nº do coordenador do grupo.
Topo...
Na plataforma de e-learning da UM, na UC de Sistemas de Computação
(pode ser acedido por aqui).
Topo...
Conteúdo da responsabilidade de Alberto Proença,
José Carlos Ramalho e João Barbosa.
Página mantida por
aproenca@di.uminho.pt
Ultima Modificação:
16 Jun 2008
