![]() |
Sistemas de Computação |
Projecto Integrado
Programação Imperativa &
Sistemas de Computação
Objectivos | Regulamento | Enunciado: Fase1, Fase2, Fase3 | Submissão
Ultima Modificação: 06 Jun 2007
departamento de informática |
|
Este projecto tem como objectivos principais a formação genérica e específica de estudantes num ou mais temas em fundamentos de computação, em áreas de informática afins e interligadas: a programação imperativa e a arquitectura dos sistemas de computação.
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.
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:
Caracterização do Projecto
O Projecto como trabalho de grupo
Metodologia de avaliação do Projecto
Esta primeira fase do projecto é independente para as componentes de avaliação das duas disciplinas envolvidas. O resto deste enunciado aplica-se apenas à componente a ser avaliada em Sistemas de Computação.
Objectivo funcional do trabalho na Fase1:
Contribuir para o desenvolvimento de um simulador de um computador básico, inspirado no funcionamento do IA32, de modo a ilustrar a execução de instruções passo a passo em moldes semelhantes ao utilizado no guião teatral.
Informação adicional:
- modo de contribuição: análise e especificação detalhada dos componentes do
problema (para ser codificado por terceiros), incluindo a definição do conjunto
de testes para validar os módulos do programa que forem posteriormente construídos;
a codificação não está incluída nesta fase nem o será neste ano lectivo;
- componentes do problema: o interface com o utilizador, o comportamento
funcional de várias módulos dum computador (vários blocos funcionais do CPU e a memória
primária), e a visualização da informação;
- sugestões de implementação dos componentes do problema: funções;
- as tarefas de especificação de componentes serão distribuídas pelos diversos
grupos de trabalho; consultar o fim do enunciado desta fase;
- elementos a especificar: a sequência de passos a seguir e/ou o algoritmo de
tratamento da informação e as estruturas de dados necessárias para o correcto
funcionamento de cada um dos componentes e da sua interligação; um exemplo será
apresentado adiante;
- objectivos dos testes: validar que o código desenvolvido se comporta conforme
especificado e que é robusto quando são introduzidos dados inesperados ou não
válidos;
- as restrições na configuração inicial do computador serão
apresentadas
adiante;
- o subconjunto de instruções do IA32 que este simulador deverá executar será
apresentado adiante;
- esta fase será avaliada apenas pelo relatório de
grupo, de acordo com as regras definidas no
Regulamento; o modelo de
avaliação do relatório está aqui disponível.
Sugestão de trabalho dentro de cada grupo:
- distribuição das tarefas de análise/especificação de "componentes"
diferentes para cada um dos elementos do grupo;
- com base na descrição das tarefas feita por cada elemento, passar essa
informação a um colega do grupo para que ele verifique se compreendeu a
descrição e se consegue desenvolver código para concretizar essa tarefa; não
precisa de gerar código, mas tão somente imaginar como ele seria escrito;
- para cada par de "especificação + código" pedir ao 3º elemento do grupo que
(i) invente valores de dados de entrada para testar se a "codificação" feita de
acordo com a "especificação" funciona correctamente, e (ii) tente fazer com que
a "codificação" produza resultados incorrectos.
Descrição detalhada das tarefas de especificação da Fase1:
1. Interface com o utilizador
A análise e especificação deverá contemplar pelo menos as seguintes
operações:
- compilação de um programa/função em C (sem variáveis globais) para um ficheiro
objecto, e deste para um outro com apenas o código (binário) do programa/função
(especificar o formato); sugestão: com objdump
e
desmontagem, mostrar primeiro ao utilizador se o código assembly satisfaz
ou não as restrições desta aplicação; se sim, gerar então um ficheiro contendo
apenas o código binário (em linguagem máquina) do programa/função
- configuração do computador antes do início do programa a executar, incluindo a
definição interactiva dos conteúdos dos registos (dentro de alguns valores
pré-definidos) e o carregamento do ficheiro com o código do programa/função (ver
restrições na configuração inicial)
- activação da execução do programa em modo contínuo ou com interrupções
predefinidas
- invocação de um visualizador de informação (em decimal, binário ou
hexadecimal, consoante o contexto)
2. Comportamento do CPU
As tarefas relativas ao CPU serão divididas pelas suas principais 4 unidades:
UC (Unidade de Controlo), UDI (Unidade de Descodificação de Instruções), ALU (Arithmetic
and Logic Unit), e BR (Banco de Registos).
Cada tarefa requisitada pela UC a uma unidade que lhe é externa, deverá ser simulada por uma invocação de uma função, onde os argumentos
a passar correspondem à informação que circula ou dentro do CPU ou nos
barramentos externos.
2.1 A análise e especificação da UC deverá conter:
- o ciclo de execuções de instruções dum CPU, abaixo descrito;
- a operação de busca de uma instrução (ou parte) da memória, após confirmação
pela UDI que não existe lá nenhum byte por descodificar, ou por
solicitação expressa da UDI de que necessita de mais bytes para
descodificar; sugestão: aproveitar a função LS, adiante descrita;
- a actualização do valor no registo EIP, usando uma função de soma (SUM), mais
simples que a ALU;
- a activação da UDI;
- a activação da unidade de controlo de execução (EXE) com os sinais de controlo
adequados à execução da instrução descodificada;
- a verificação da existência ou não de um pedido de execução contínua, ou passo
a passo e neste caso devolve o controlo ao interface com o utilizador.
2.1.1 A análise e especificação da função EXE deverá estar organizada
em grandes categorias, e deverá conter:
- uma identificação das operações elementares a executar por cada instrução, de
acordo com as grandes categorias especificadas em baixo;
- para cada instrução e operação elementar associada, a identificação da
sequência dos sinais de controlo a activar
- activação da unidade responsável pelos acessos à memória para ler operandos e
escrever resultados (função LS),
- activação da unidade responsável pelas operações de transferência de operandos
em registos (função MR),
- activação da unidade responsável pelas operações aritméticas/lógicas com
operandos em registos (função ALU, descrita mais abaixo),
- activação da unidade responsável pelas instruções de salto condicional e
incondicional (função JC).
2.1.2 A análise e especificação da função LS deverá conter:
- a activação dos sinais de controlo adequados à leitura dum operando da
memória, quando tal for solicitado
- a activação dos sinais de controlo adequados à escrita dum resultado da
memória, quando tal for solicitado
2.1.3 A análise e especificação da função MR deverá conter:
- a activação dos sinais de controlo adequados à leitura do operando fonte no BR
e à escrita num outro registo do BR
2.1.4 A análise e especificação da função JC deverá conter:
(tarefa não incluída)
2.2 A análise e especificação da UDI deverá conter:
- um estrutura de armazenamento de bytes de instruções (até 4) e
respectivas localizações em memória (bastam os últimos bits do endereço);
- validação da existência ou não de um byte por descodificar no CPU com
base no valor do IP; se não existir, dar essa indicação à UC;
- descodificação do 1º byte para identificação da(s) operação(ões) a
realizar, e passar essa informação à UC se a descodificação ficar completa;
- senão, analisar o 2º byte (se já estiver na UDI, senão...) para obter a
localização dos operandos, e passar essa informação (e a anterior) à UC se a
descodificação ficar completa;
- senão, analisar o 3º byte (se já estiver na UDI, senão...) para obter o
resto da informação necessária, e passar ...
- senão ...
2.3 A análise e especificação da ALU deverá conter:
- a realização da operação solicitada
- a activação das flags de sinal, zero, carry e de
overflow.
2.4 A análise e especificação do BR deverá conter:
- operação de leitura do conteúdo de um registo (de 8 ou de 32 bits; e o de 8 é
uma parte de um de 32 bits);
- operação de escrita (alteração do conteúdo) num registo (de 8 ou de 32 bits; e
o de 8 é uma parte de um de 32 bits).
(tarefa já resolvida, incluída no exemplo de relatório, apresentado no
Regulamento)
3. Comportamento da memória primária
A análise e especificação deverá conter:
- operação de leitura do conteúdo de um conjunto de células;
- operação de escrita (alteração do conteúdo) de um conjunto de células.
4. Visualização de informação
A análise e especificação deverá contemplar pelo menos as seguintes
operações:
- selecção da opção de visualização (banco de registos ou memória);
- se banco de registos, apresentar o conteúdos dos registos apontadores (IP, BP
e SP) em binário e hexadecimal, e os restantes em decimal (com e sem sinal),
binário e hexadecimal;
- se memória, conforme o solicitado, mostrar em ASCII, decimal (com e sem
sinal), binário ou hexadecimal.
Informação complementar:
Restrições na configuração inicial do computador
Dimensão da memória primária: 256 bytes para o programa (conteúdo da
secção .text) e 256 bytes para a stack.
Dimensão dos barramentos de dados e de endereços: 32 bits.
O CPU apenas irá trabalhar com operandos de 8 ou 32 bits (fica excluída a
hipótese de 16-bits, mesmo na utilização de registos).
O conteúdo do registo EIP deverá ser um endereço na gama inicial de endereços da
memória disponível para o programa.
O conteúdo do registo ESP deverá ser um endereço na gama final de endereços da
memória disponível para a stack.
Subconjunto de instruções do IA-32 a considerar
Opcode |
Mnemónica |
Comentários |
0000 00xx |
add |
xx:
ver figura no TPC3; |
0101 0yyy |
push |
yyy:
identificação de registo, |
0101 1yyy |
pop |
yyy:
identificação de registo, |
1000 10xx |
mov |
xx:
ver figura
no TPC3;
|
1000 110x |
lea |
xx:
ver figura
no TPC3;
|
1100 0011 |
ret |
|
Distribuição de tarefas/componentes pelos grupos
Esta fase está dividida em 8 tarefas distintas, onde cada grupo escolhe apenas uma para realizar.
As tarefas estão agrupadas por ordem de dificuldade:
- 3 tarefas para estudantes do tipo R, com expectativa de classificação
Razoável, e com pontuação máx. de 14 valores: 2.1.2,
o par (2.1.3 e 3) e
4.
- 4 tarefas para estudantes do tipo B, com expectativa de classificação Boa, e
com pontuação máx. de 18 valores: 1,
2. 1, 2.1.1 e
2.3.
- 1 tarefa para estudantes do tipo E, com expectativa de classificação
Excelente, e com pontuação máx. de 20 valores: 2.
2.
A 2ª fase do projecto continua independente
para as componentes de avaliação das duas disciplinas envolvidas, tal como
acontecerá com o resto do projecto. Infelizmente, o esforço docente requerido
para a elaboração de um projecto integrado e coordenado é superior ao
humanamente possível em 2006/07.
Assim, o resto deste
enunciado aplica-se apenas à componente a ser avaliada em Sistemas de
Computação, embora tenha referências ao projecto a decorrer em paralelo em PI (LCC)
ou LI2 (LEI), o projecto da Arca de Jogos.
Contexto
No âmbito do projecto da Arca de Jogos é essencial dispor de um gerador de números pseudo-aleatórios. Não sendo indispensável ter um gerador de muita qualidade, pode-se optar por um algoritmo relativamente simples. Contudo, para se saber exactamente como deve ser utilizado o algoritmo, é necessário compreender o seu funcionamento.
Lamentavelmente, o programador não disponibilizou o código fonte da função que realiza o algoritmo, pelo que, apenas estão disponíveis os ficheiros com o código objecto e o protótipo da função (extensões ‘o’ e ‘h’, respectivamente).
Objectivo funcional do trabalho na Fase2
Recuperar o ficheiro com o código fonte de uma função em C que gera números pseudo-aleatórios, a partir do do seu protótipo e do código objecto dessa função.
Informação adicional
Deverão ser
utilizadas ferramentas para compilar (gcc),
desmontar (objdump) e depurar (gdb) os códigos produzidos por um
compilador, de forma a permitir:
- executar programas no modo passo a
passo;
-
instalar/desinstalar pontos de paragem;
-
desmontar e analisar o código gerado;
-
consultar/alterar o valor de registos e de posições de memória;
-
consultar o estado da pilha associada à invocação de funções.
Material disponível
Todos os ficheiros necessários para este trabalho estão disponíveis no arquivo
scFase2, com excepção do
ficheiro que contém o código fonte da função que gera os números
pseudo-aleatórios.
Nomeadamente, o arquivo contém:
Makefile: com a informação que o programa make usa para produzir o executável correspondente ao programa final;
gerador.h: com o protótipo da função;
gerador.o: com o código objecto da função de que desconhecemos o código fonte;
main.c: com o código fonte da função principal do programa final.
Descrição detalhada das tarefas da Fase2
1. Desmonte o
código no ficheiro gerador.o e comente-o de forma apropriada;
2.
Use o comando
make para gerar o ficheiro executável;
3.
Use o depurador para prosseguir as seguintes tarefas:
a) Introduzir um ponto de paragem no início da função;
b) Executar o programa, passando-lhe como parâmetros os números de cada um dos elementos do grupo;
c) Executar a função passo a passo, mostrando o conteúdo dos registos e das posições de memória que vão sendo modificados durante a execução de cada instrução.
d) Explique, por palavras suas, o que acontece de cada vez que se executa a função; referindo as alterações ao estado de execução do programa após a execução da função e os valores devolvidos pela função de cada vez que é executada;
e) A partir do código desmontado da função, deduza uma versão em código C que no seu entender poderá representar o algoritmo original usado para gerar os números pseudo-aleatórios;
f) Sabendo que o compilador gcc quando instruído para optimizar (opção –On) tenta aumentar a eficiência do código, através de alguns artifícios, explique, por palavras suas, eventuais discrepâncias entre o código assembly produzido pela compilação da função escrita na alínea e) e o código desmontado original (gerador.o).
Nota: a alínea c) deverá ser repetida para cada uma das chamadas à função, efectuadas a partir da função main, mostrando, de cada vez, os argumentos passados à função.
Relatório e submissão da Fase2
O relatório a elaborar e sua submissão segue as regras definidas para a Fase1, com excepção dos prazos que são os específicos da Fase2 e que foram reformulados no Regulamento.
Não serão aceites relatórios que não
satisfaçam os seguintes critérios:
- não tenham a estrutura definida nas regras do Regulamento;
- tenham menos que 4 ou mais que 8 páginas (sem contar com os anexo);
- não sigam as recomendações feitas na correcção do relatório da Fase1;
- não contenham os seguintes campos obrigatórios: Resumo, Conteúdo,
Introdução e Conclusões .
O relatório a produzir deverá
conter, para além do especificado no parágrafo anterior:
- uma secção com o título "Análise do gerador de números aleatórios", contendo
(i) uma subsecção a descrever esta função tal como ela foi
compilada, e o comportamento dos registos e posições
de memória alterados (respostas as questões 3.c e 3.d), e (ii)
uma subsecção com o algoritmo usado para a geração de números
aleatórios (descrito usando C) e uma explicação para a eventual discrepância
entre o código gerado pela compilação do código com este algoritmo e o ficheiro
original (respostas às questões 3.e e 3.f).
- um anexo com o código desmontado a partir do conteúdo do ficheiro
gerador.o,
devidamente comentado conforme solicitado acima.
Objectivo funcional do trabalho na Fase3
O estudo de código produzido pelo compilador gcc, considerando o nível de optimização “-O2” a partir de programas em linguagem C que incluem: chamadas encadeadas de funções, controlo de fluxo e estruturas de dados. A ênfase vai para a análise do código produzido e das estruturas e contextos que suportam a invocação de procedimentos.
Material
disponível
O material necessário para este trabalho, incluindo o modelo a utilizar para a
resposta e submissão desta fase, está disponível no arquivo
scFase3, que contém os seguintes ficheiros:
Informação
geral
Impõe-se a
utilização de ferramentas de acesso livre para as
tarefas de: compilar (gcc),
desmontar (objdump)
e depurar (gdb),
seguindo o modelo adoptado para o desenvolvimento da fase 2.
Descrição detalhada das tarefas da Fase3
1. Use o comando make para gerar o ficheiro executável;
2.
Use o
depurador
para prosseguir as seguintes tarefas :
a) Na função gera estabeleça um ponto de paragem imediatamente antes da instrução ret para permitir suspender a execução antes do regresso da função.
b) Executar o programa passando como argumento o seu número mecanográfico de aluno (e.g. prog 49442).
c) Acrescente toda a informação (comentários) necessária para estabelecer a relação entre o código C original da função gera e o código IA32 desmontado. Em particular, apresente todos os elementos respeitantes: (i) à estrutura de controlo de fluxo (for) e (ii) ao acesso à estrutura de dados (sequencia) declarada.
d) Construa a tabela de alocação de registos, da função gera, incluindo os valores iniciais das variáveis C que representam.
e) Apresente toda a informação relevante, tanto no que diz respeito à estrutura como ao conteúdo (incluindo os valores das variáveis globais e locais), das áreas de activação da pilha (activation records, também conhecidas como quadros das funções ou stack frames), correspondentes à função gera e das demais funções que a precederam no processo de execução.
f) Conclua a execução do programa e apresente o resultado obtido na saída de dados.
Relatório e submissão da Fase3
O relatório a elaborar deverá obedecer ao formato definido no ficheiro relatorio.txt, fornecido no material disponível, e ser submetido, impreterivelmente, até às 24h do dia 10 de Junho.
Atenção:
1. A Fase 3 terá uma avaliação individual, pelo que a sua
submissão deverá também ser feita de modo individual .
2. O
processo de submissão segue o modelo adoptado para as fases anteriores, mas como
algumas alterações, para permitir distinguir os trabalhos de LCC dos de LEI, e
para identificar individualmente os trabalhos; o nome do ficheiro a submeter
deverá obedecer ao seguinte novo formato:
Fase3-(lei|lcc)-núm_aluno.txt
de que são
exemplos: Fase3-lei-48342.txt ou
Fase3-lcc-42856.txt.
3.
O sítio na Web para submissão da Fase 3 está ainda em construção, e deverá ficar
operacional antes de Junho. Logo que esteja, esta nota será retirada deste
local. E se houver alteração ao formato, será aqui apresentada.
O sistema de submissão já está a funcionar: cada
elemento deve entrar com o login do seu grupo e introduzir o nº de aluno
com que se inscreveu nesse grupo.