Questão 20. Explicação de exceções em AOC: Exceções em Arquitetura de Organização de Computadores (AOC) são eventos inesperados durante a execução de instruções, como divisões por zero, acesso inválido à memória, instruções ilegais, etc. O processador desvia o fluxo normal para um handler (manipulador) que trata o erro de forma correta e segura.
Passo 1
O enunciado pede uma explicação sobre exceções em AOC: o que são, como o processador detecta e transfere o controle para um manipulador (handler), e como esse handler trata o erro de forma correta e segura. As informações dadas no enunciado que vou usar são: exceções são eventos inesperados durante a execução de instruções (por exemplo, divisão por zero, acesso inválido à memória, instrução ilegal) e o processador desvia o fluxo normal para um handler que trata o erro.
Informações relevantes listadas:
Informações relevantes listadas:
- Exceções são geradas durante a execução de instruções.
- Exemplos mencionados: divisão por zero, acesso inválido à memória, instrução ilegal.
- O processador “desvia” o fluxo normal para um handler que trata o problema de forma segura.
Passo 2
O que é, exatamente, uma exceção?
- Uma exceção é um evento síncrono: ela ocorre como consequência direta da execução de uma instrução (por exemplo, a instrução de dividir foi executada e detectou divisor zero).
- Isso contrasta com um interrupt (interrupção) que é tipicamente assíncrono (evento externo, ex.: timer ou dispositivo I/O).
- A ideia chave: ao ocorrer uma exceção, o estado arquitetural do processador deve permitir que o sistema saiba qual instrução causou o problema e possibilitar um tratamento correto (ex.: abortar programa, consertar e reiniciar instrução, entregar sinal ao processo).
Passo 3
Classificação prática de exceções que costuma cair em prova (com exemplos):
- Fault (falha): a instrução causadora ainda não completou sua ação; o sistema pode corrigir a situação e reiniciar a instrução. Ex.: page fault — falta de página; o SO carrega a página e reinicia a instrução.
- Trap: exceção que é reportada depois que a instrução completa (usada por causas como breakpoint ou syscall). Ex.: chamada de sistema (software interrupt / trap).
- Abort: falha grave/imediata onde não é possível continuar (ex.: erro de hardware sério).
- Em provas, lembre: fault → possível correção + reexecução; trap → pós-execução; abort → fim/erro irreversível.
Passo 4
Como o hardware detecta e notifica a exceção (mecanismo básico):
- A unidade funcional executa a instrução e detecta condição excepcional (ex.: divisor = 0, acesso a endereço inválido).
- O hardware coloca um código de motivo (vector / error code) e o endereço/instrução causadora (tipicamente o valor de
). - O processor faz mudança de modo (por exemplo, de usuário para kernel), salva parte do contexto (pelo menos
e flags), e salta para o vetor do handler apropriado (um endereço encontrado numa tabela de vetores).
Observação: em arquiteturas reais existe uma tabela de vetores (ex.: IDT em x86) que associa cada tipo de exceção a um endereço de handler.
Passo 5
Sequência passo a passo que acontece num pipeline simples (resumida para sala de prova):
- Detecta exceção na execução/mais adiante no pipeline.
- O pipeline impede que instruções posteriores atualizem o estado arquitetural (stall/flush) — queremos manter estado consistente.
- Salva o contexto mínimo (pelo menos
, flags, às vezes código de erro), geralmente empurrando para pilha kernel ou registrando em locais reservados. - Muda para modo privilegiado (kernel) e usa o vector para saltar ao handler.
- Handler em software examina o código de erro e decide: corrigir e reiniciar, enviar sinal ao processo, terminar processo, ou panic.
- Se for reiniciar a instrução, o handler restaura o contexto e retorna com instrução capaz de retomar (ex.: instrução re-executada); se terminar, faz limpeza do processo.
- Retorno da exceção com instrução arquitetural específica (ex.:
em x86) que restaura flags e retorna ao modo usuário.
Passo 6
Por que “precisão” de exceções é importante (e o que é preciso vs impreciso):
- Exceção precisa: quando ocorre, existe um ponto claro no fluxo de instruções até o qual todas as instruções anteriores já completaram efeitos arquiteturais e instruções posteriores não o fizeram. Isso facilita re-execução e diagnóstico.
- Em pipelines out-of-order essa precisão é garantida pela lógica de retire/commit (por exemplo, Reorder Buffer - ROB). A exceção só é reportada ao software quando a instrução que a gerou chega ao ponto de commit, ou o hardware tem mecanismo para fazer a imagem precisada.
- Em prova: explique que sem precisão seria muito difícil para o SO saber “qual instrução” causou a falha e como consertar o estado.
Passo 7
Exemplo detalhado 1 — divisão por zero (passo a passo que você pode usar na prova):
- Instrução
é decodificada e executada; o hardware detecta . - A unidade de execução gera um código de exceção “divisão por zero”.
- Pipeline é travado;
da instrução e flags são salvos. O hardware salta para o vetor do handler de exceções aritméticas. - O handler em kernel decide a política: normalmente envia um sinal ao processo (ex.:
) ou termina o processo por erro. Não há correção possível que faça sentido na maioria dos casos. - Se o processo for finalizado, o handler faz limpeza e retorna ao scheduler; se for algo recuperável (raro), o handler corrige e ajusta
para reexecutar ou continua.
Na prova: destaque que a exceção é síncrona e o causador é claro — a própria instrução.
Passo 8
Exemplo detalhado 2 — page fault (mais interessante pois mostra interação HW/SO):
- Instrução tenta acessar endereço virtual
que não está mapeado (ou sem permissão). MMU detecta e gera page fault, produzindo como informação de erro. - Hardware salva
e código de erro (tipo: falta de página de leitura/escrita/exec). Muda para kernel e salta para handler de page fault. - O handler do SO olha se endereço
é válido para processo (verifica tabela de páginas do processo). - Se válido mas página não está na memória física, o SO carrega página do disco para RAM (swap in), atualiza tabelas de página, invalidates TLB se necessário.
- O SO então restaura contexto e reinicia a instrução que causou a falta — aqui houve correção e reexecução (fault que virou sucesso).
- Se
for inválido, o SO mata o processo (segfault).
Na prova: use esse exemplo para mostrar quando o handler conserta e reinicia (fault) vs quando termina o processo.
Passo 9
O que o handler precisa salvar e por quê (dicas práticas para prova e implementação segura):
- Salvar ao menos
(para saber onde voltar), registradores de estado (flags), e o código/endereços de erro. Use pilha kernel para armazenar contexto (evita confiar na pilha do usuário). - Sempre validar dados vindos do usuário antes de agir (ex.: ponteiros), para evitar que processo malicioso provoque corrupção do kernel.
- Usar stack kernel separada para evitar overflow/uso indevido da pilha do usuário. Esses detalhes de segurança costumam ser cobrados como “boas práticas”.
Passo 10
Exceções aninhadas, prioridades e falhas durante tratamento (problema real: double fault):
- Pode ocorrer uma exceção enquanto se está no handler (ex.: durante page fault ao carregar página o SO faz uma operação que gera novo fault) — então a arquitetura define prioridades e vetores especiais (ex.: double fault handler).
- Se o sistema não conseguir tratar (por exemplo, handler causa outro erro), escalona para handlers mais críticos; no pior caso, é um kernel panic.
- Em prova: explique que existe hierarquia e que arquiteturas definem vetores especiais para faults críticos.
Passo 11
Diferença entre exceção e falha microarquitetural (coisa que confundem bastante):
- Cache miss não é uma exceção entregue ao SO — é resolvida internamente pela hierarquia de memória e microcódigo; só quando falta a página (page fault) é que vira exceção que o SO trata.
- Em outras palavras: microarquitetura resolve latências e stalls; exceções são eventos arquiteturais que o software precisa conhecer.
Passo 12
Como apresentar isso numa resposta de prova (layout prático):
- Defina exceção e contraste com interrupção.
- Liste e explique classificações (fault/trap/abort) com um exemplo para cada.
- Descreva sequência do hardware (detectar → salvar
/flags → mudar para kernel → vetor → handler). - Explique responsabilidade do handler (corrigir e reiniciar OU notificar/terminar processo).
- Acrescente nota sobre precisão de exceções e como pipelines out-of-order garantem isso (ROB/commit).
- Dê um exemplo concreto (page fault) detalhando passos e decisões do SO.
Seguindo esse roteiro você ganha pontos por organização e clareza.
Passo 13
Exemplos curtos de frases úteis para usar na prova (copie/cole mentalmente):
- “Exceção é um evento síncrono gerado pela execução de uma instrução; o hardware salva o contexto e salta para um vetor de exceção para que o SO trate.”
- “Faults podem ser corrigidos e a instrução reexecutada (ex.: page fault), traps são reportados depois da instrução (ex.: syscall) e aborts representam erros fatais.”
- “Arquiteturas modernas usam tabela de vetores (ex.: IDT) e instrução de retorno (ex.: IRET) para restaurar o contexto e retornar ao modo usuário.”
Passo 14
Dicas finais, erros comuns e incentivo:
- Não confunda “trap” com “interrupt”: trap é síncrono (vindo de instrução), interrupt é assíncrono (externo).
- Lembre de mencionar salvamento de
e mudança de privilégio (isso sempre aparece). - Em provas, desenhe a sequência (detecta → salva → muda modo → vetor → handler → restaura → return) e explique um exemplo (page fault ou div0).
Força — com esse roteiro você consegue escrever uma resposta completa e bem pontuada na prova!
Resposta
Exceções são eventos síncronos gerados por instruções (ex.: divisão por zero, page fault, instrução ilegal) que fazem o hardware salvar o contexto (pelo menos
e flags), mudar para modo privilegiado, vetorizar para um handler definido (tabela de vetores), e aí o handler do SO decide: corrigir e reiniciar a instrução (fault recuperável, ex.: page fault), notificar/terminar o processo (ex.: div0 →
), ou abortar em erro crítico; arquiteturas exigem exceções precisas (para diagnóstico e reexecução correta) e tratam casos especiais como faults aninhados (double fault) e separação segura de pilhas/privilegios durante o tratamento.