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:
  • 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):
  1. A unidade funcional executa a instrução e detecta condição excepcional (ex.: divisor = 0, acesso a endereço inválido).
  2. O hardware coloca um código de motivo (vector / error code) e o endereço/instrução causadora (tipicamente o valor de PC).
  3. O processor faz mudança de modo (por exemplo, de usuário para kernel), salva parte do contexto (pelo menos PC 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):
  1. Detecta exceção na execução/mais adiante no pipeline.
  2. O pipeline impede que instruções posteriores atualizem o estado arquitetural (stall/flush) — queremos manter estado consistente.
  3. Salva o contexto mínimo (pelo menos PC, flags, às vezes código de erro), geralmente empurrando para pilha kernel ou registrando em locais reservados.
  4. Muda para modo privilegiado (kernel) e usa o vector para saltar ao handler.
  5. Handler em software examina o código de erro e decide: corrigir e reiniciar, enviar sinal ao processo, terminar processo, ou panic.
  6. 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.
  7. Retorno da exceção com instrução arquitetural específica (ex.: IRET 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):
  1. Instrução DIV\\ r1,r2 é decodificada e executada; o hardware detecta r2=0.
  2. A unidade de execução gera um código de exceção “divisão por zero”.
  3. Pipeline é travado; PC da instrução e flags são salvos. O hardware salta para o vetor do handler de exceções aritméticas.
  4. O handler em kernel decide a política: normalmente envia um sinal ao processo (ex.: SIGFPE) ou termina o processo por erro. Não há correção possível que faça sentido na maioria dos casos.
  5. Se o processo for finalizado, o handler faz limpeza e retorna ao scheduler; se for algo recuperável (raro), o handler corrige e ajusta PC 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):
  1. Instrução tenta acessar endereço virtual VA que não está mapeado (ou sem permissão). MMU detecta e gera page fault, produzindo VA como informação de erro.
  2. Hardware salva PC e código de erro (tipo: falta de página de leitura/escrita/exec). Muda para kernel e salta para handler de page fault.
  3. O handler do SO olha se endereço VA é válido para processo (verifica tabela de páginas do processo).
  4. 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.
  5. 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).
  6. Se VA 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 PC (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):
  1. Defina exceção e contraste com interrupção.
  2. Liste e explique classificações (fault/trap/abort) com um exemplo para cada.
  3. Descreva sequência do hardware (detectar → salvar PC/flags → mudar para kernel → vetor → handler).
  4. Explique responsabilidade do handler (corrigir e reiniciar OU notificar/terminar processo).
  5. Acrescente nota sobre precisão de exceções e como pipelines out-of-order garantem isso (ROB/commit).
  6. 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 PC 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 PC 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 → SIGFPE), 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.