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 para construir algumas rotinas básicos. Todos os softwares modernos (aplicativos, compiladores e especialmente sistemas operacionais) precisam recorrer a este tipo 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 em grupos de no máximo duas pessoas. Cada grupo usa sempre o "seu" PC. Uma modificação na composição de um grupo necessita da autorização do professor. Esta autorização será dada somente em casos excepcionais.
Os resultados que o aluno deve obter em cada trabalho são mínimas, 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 por email nas datas combinadas em sala de laboratório – entrega depois da referida data não vale. A desculpa "perdi os meus arquivos" ou "achei que o meu parceiro de grupo tinha enviado" não vale – cada um é responsável de fazer backup dos arquivos e verificar o envio do email dentro do prazo. Os itens a serem entregues estão listadas no arquivo de ajuda dos computadores no laboratório.
Entregar uma cópia de um trabalho de outro grupo não vale
(é considerado cópia o email que foi enviado depois do original).
Um grupo pode usar subrotinas e pedaços de código de outro
grupo 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 demonstra que o grupo que usou o código do outro grupo realmente
entende o funcionamento do referido código.
O resultado deve ser uma seqüência de gráficos sendo calculados 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 termina o programa deve terminar.
mínimo perfeito | 7 | |
a | falta tela mostrando execução da rotina de atendimento da interrupção | -1 |
b | falta explicação da pilha na rotina | -0,5 |
c | falta tela mostrando o descritor (nas 2 janelas) | -0,5 |
d | menos do que 10 telas | -...2 |
e | não funciona | -...2 |
f | falta código para funcionar | -...2 |
g | Capturando mais interrupções (por exemplo timer) | +0,5...+0,7 |
h | Explicações detalhadas/erradas | +/-...2 |
i | Mais comentários no código | +...0,3 |
j | Código bonito (subrotinas, etc.) | +...0,3 |
k | Visualização (fractais e pisca) mais bonita | +...0,3 |
l | entrega atrasada | -0,1/dia |
Obs.: a nota máxima é 10.
O programa principal deve fazer acesso de escrita a um endereço linear que não tem um endereço físico associado a ela 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. Um acesso de leitura no mesmo endereço deve mostrar que a operação de escrita tinha dado certo.
mínimo perfeito | 7,5 | |
a | falta tela mostrando execução da rotina de atendimento da falha de pagina | -1 |
b | falta explicação da pilha | -0,5 |
c | falta explicação da pilha dentro da rotina | -0,5 |
d | falta tela mostrando o descritor (nas 2 janelas) | -0,2 |
e | falta tela mostrando a paginação (nas 2 janelas) | -1 |
f | não funciona | -...2 |
g | falta código para funcionar | -...2 |
h | Explicações erradas/detalhadas | +/-...2 |
i | Mais comentários no código / comentários errados | +/-...0,3 |
j | Código bonito (subrotinas, etc.) | +...0,3 |
Obs.: a nota máxima é 10.
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. De dentro do programa carregado que deve roda 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 | 6,5 | |
a | falta tela mostrando execução do aplicativo carregado | -1 |
b | falta explicação da pilha na chamada ao sistema | -0,5 |
c | falta tela mostrando os descritores (nas 2 janelas) | -0,5 |
d | não funciona | -...2 |
e | falta código para funcionar | -...2 |
f | Explicações detalhadas/erradas | +/-...2 |
g | Mais comentários no código | +...0,3 |
h | Código bonito (subrotinas, etc.) | +...0,3 |
i | realizando ataques (por ataque diferente) | +...0,4 |
j | na chamada ao systema aumenta-se o tamanho do segmento de variáveis | +...0,4 |
Obs.: a nota máxima é 10.