Nestes projetos o aluno pode conhecer um processador moderno "por dentro" e ganhar experiência prática e real, "mão na massa", usando recursos do processador Pentium para construir algumas rotinas básicos. Todos os softwares modernos (aplicativos, compiladores e especialmente sistemas operacionais) precisam recorrer a estes tipos de rotinas para funcionar bem.
Todas as informações necessárias para fazer estes projetos são dadas nas aulas de laboratório. Estas mesmas informações podem ser encontradas nas referências bibliográficas e nos arquivos dos computadores do laboratório. O tutorial do depurador está disponivel também aqui .
Os projetos devem ser feitos individualmente.
Os resultados que o aluno deve obter em cada trabalho são mínimos, ou seja, apenas o essencial para mostrar o funcionamento do mecanismo (interrupção, paginação, segmentação, proteção e multitarefas). Para obter a nota máxima o aluno deve mostrar a sua imaginação, iniciativa e originalidade fazendo algo um pouquinho a mais.
Os trabalhos devem ser entregues nas datas combinadas em sala de laboratório – entrega depois da referida data não vale. A desculpa "perdi os meus arquivos" ou "achei tinha enviado" não vale – cada um é responsável por fazer backup dos arquivos e verificar a entrega dentro do prazo. Os itens a serem entregues estão listadas no arquivo de ajuda ajuda.txt dos computadores no laboratório.
Entregar uma cópia de um trabalho de outro aluno não vale.
Um aluno pode usar subrotinas e pedaços de código de outro
aluno mas deve mencionar isso sob forma de um comentário no início
e no fim do código copiado, caso contrário a pontuação
correspondente a esse código não será dada. O código
copiado deve ainda obrigatoriamente sofrer alguma modificação
que demonstre que o aluno que usou o código do outro aluno realmente
entende o funcionamento do referido código.
O resultado deve ser um fractal sendo calculado e aparecendo na tela e alguma parte na tela piscando sempre quando chega uma determinada interrupção, por exemplo quando alguém mexe no mouse. A seqüência de gráficos deve durar alguns segundos e ao terminar o programa deve terminar.
| Nota de base | 6,5 |
|
| a) |
Menos do que 10 telas |
- ...2 |
| b) |
Não funciona (ou funciona parcialmente) |
- ...2 |
| c) |
Falta código para funcionar |
- ...2 |
| d) |
Falta tela mostrando o descritor (nas 2 janelas) |
-0,5 |
| e) | Falta tela mostrando execução da rotina de atendimento da interrupção | -1,0 |
| f) | Falta explicação da pilha | -0,5 |
| g) |
Explicações detalhadas/erradas |
+/-...2 |
| h) |
Mais comentários no código |
+ ...0,3 |
| i) |
Código bonito (subrotinas, etc.) |
+ ...0,3 |
| j) |
Visualização (fractais e pisca) mais
bonita |
+ ...0,8 |
| k) |
Capturando mais interrupções (por
exemplo timer) |
+ ...1,0 |
| l) |
Entrega atrasada |
-3,0/dia |
O programa principal deve fazer acesso de escrita a um endereço virtual (linear) que não tem um endereço físico associado a ele de maneira a provocar uma falha de página. A falha de página deve ser atendida mapeando um frame da memória RAM para a página onde ocorreu a falha e dar continuação ao programa principal.
O programa deve carregar um arquivo executável e executá-lo. O código deve ser carregado num segmento de código e os dados devem ser carregados num segmento de dados que permite somente leitura (não escrita). Para as variáveis, um segmento que permite leitura e escrita deve ser criado. Um segmento específico para a pilha deve ser criado. Os tamanhos para os respetivos segmentos devem ser obtidos do cabeçalho do arquivo executável. Todos os segmentos devem usar DPL=3. Deve-se usar um Task State Segment para colocar o parograma carregado para rodar. De dentro do programa carregado que deve rodar com CPL=3 deve ser feito uma chamada de uma subrotina que deve rodar com CPL=0.
Um salto para fora do segmento de código ou uma tentativa de acesso de memória fora do limite do segmento de dados devem provocar um #GP. Uma tentativa de dar um salto para um endereço qualquer num segmento de código com DPL=0 ou a tentativa de executar uma instrução privilegiada (como acessar o registro CR3 por exemplo) deve resultar num #GP.
| Mínimo perfeito | 7,5 | |
| a) |
Menos do que 10 telas | - ...2 |
| b) |
Não funciona (ou funciona parcialmente) |
- ...2 |
| c) |
Falta código para funcionar |
- ...2 |
| d) | Falta tela mostrando o descritor para falha de pagina | -0,2 |
| e) | Falta tela mostrando execução da rotina do atendimento da falha de pagina | -0,5 |
| f) | Falta explicação da pilha de atendimento a falha de pagina | -0,5 |
| g) | Falta tela mostrando paginação | -1 |
| h) | Falta tela mostrando os descritores de segmentos | -0,5 |
| i) | falta tela mostrando execução do aplicativo carregado | -0,5 |
| j) | Falta explicação da pilha da chamada ao "sistema operacional" | -0,5 |
| k) |
Explicações erradas / detalhadas |
-2 ...2 |
| l) | Realizando ataques (por ataque diferente) | +...0,5 |
| m) | preenchimento do descritor para limites de até 4GB | +...0,3 |
| n) | Na chamada ao sistema aumenta-se o tamanho do segmento de variáveis | +...1,0 |
| o) | Uso da LDT | +...0,5 |
| p) | Mais comentários no código | +...0,3 |
| q) | Código bonito (subrotinas, etc.) | +...0,3 |
| r) | Solução diferente | +...1 |