O hardware que sustenta o sistema operacional

Este bloco é dispensável para quem tem circuitos digitais fresco na memória — e é o mais importante para quem não tem. Ele responde à pergunta que a revisão inteira pressupõe sem nunca enunciar: de que, exatamente, um processador é feito?

A resposta é curta e não tem letra miúda: de portas lógicas, ligadas por fios. Não existe um oitavo tipo de componente escondido, nem uma peça “inteligente” em algum canto. Tudo o que a disciplina vai chamar genericamente de “o hardware” é uma destas sete montagens — e cada uma resolve uma pergunta:

Repare no que essa tabela já entrega de graça: não há nada na coluna do meio que se pareça com “executar um programa”. Um processador não sabe o que é um programa, um usuário ou um sistema operacional — ele sabe somar, escolher uma linha e segurar um bit. Todo o resto da disciplina é construído em cima dessa modéstia.

Na bancada abaixo cada peça aparece isolada, uma aba de cada vez, com o valor que a porta realmente calculou — e cada aba termina apontando exatamente onde aquela peça reaparece montada no simulador do bloco seguinte. São sete desafios; faça-os antes de seguir.

Um processador não “roda programas”. Ele repete, para sempre, três passos: buscar a próxima instrução, decodificar e executar. Não há nada além disso — nem noção de programa, nem de usuário, nem de sistema operacional.

Isso tem uma consequência que organiza a disciplina inteira: o sistema operacional é apenas mais um conjunto de instruções nessa mesma fila. Quando o SO “assume o controle”, o que aconteceu no hardware foi simplesmente que o PC passou a apontar para o código dele. Todo o resto — proteção, multitarefa, memória virtual — é construído em cima desse fato modesto.

No simulador a seguir, a máquina está inteira exposta: registradores, memória, cache, ULA e a unidade de controle. Ande de clock em clock e observe uma coisa só — em cada ciclo, alguém dirige o barramento e alguém captura. Depois desça às abas de portas lógicas: o somador, o decodificador de endereço, o comparador da cache e a trava que guarda um bit.

Se o SO é só mais um programa, por que um aplicativo qualquer não pode fazer o que ele faz? Porque existe um bit no registrador de status que o hardware consulta antes de executar certas instruções.

Três consequências que caem em prova, e que o simulador abaixo deixa você comprovar na marra:

• A fechadura não abre por dentro. Escrever no bit de modo é, ela própria, uma instrução privilegiada.
• O modo muda por evento, nunca por endereço. Saltar para dentro do núcleo não dá privilégio: o bit não acompanha o PC.
• São duas cercas. O bit de modo barra instruções; a MMU barra endereços. As duas leem o mesmo bit.

O SO não fica “vigiando” o programa — ele está parado, sem CPU nenhuma. Só volta a executar quando um evento força o desvio. E os eventos são de três tipos, que se distinguem por uma pergunta só: de onde veio, no tempo?

Os três convergem para o mesmo caminho de hardware: salvar contexto → consultar o vetor → executar o tratador em modo núcleo → retornar. Quem muda é só a causa e o número do vetor. É por isso que se estuda os três juntos.

Em um sistema de propósito geral, a latência de interrupção é um detalhe. Em um sistema embarcado com prazo, ela é requisito de projeto — e o que a define não é a média, é o pior caso.

A conta tem quatro parcelas, e três delas dependem de decisões do sistema operacional:

1. Terminar a instrução corrente — o hardware não interrompe no meio (a divisão longa é o pior caso clássico).
2. Tempo com interrupções mascaradas — toda região crítica do núcleo empurra o atendimento para frente.
3. Salvar o contexto e desviar pelo vetor — custo fixo do hardware, mas cresce com quantos registradores existem.
4. Prioridade — se um tratador mais prioritário estiver rodando, o seu espera.

Na bancada abaixo, dispare dispositivos, mascare linhas e observe a latência medida contra o prazo. Para projetar em sala, ela também abre em tela cheia.

Contar instruções engana. Duas execuções do mesmo programa, com o mesmo número de instruções, podem diferir muito no tempo — e a diferença mora na memória, não na ULA.

No simulador do primeiro bloco, o programa do laço roda em 216 ciclos com a cache ligada e 300 sem ela: as mesmas 35 instruções, quase 30% de diferença. E ele ainda perde acertos por conflito de mapeamento direto — dois blocos disputando a mesma linha, com o resto da cache vazio ao lado.

Isso importa para a disciplina por um motivo direto:

Se você levar uma única tabela para a prova, leve esta. A coluna da esquerda é hardware; a da direita é o que o sistema operacional consegue prometer por causa dela — e o que aconteceria sem ela.

• Descrever os passos de LDA 13 desde o PC até o acumulador, dizendo quem dirige o barramento em cada ciclo.
• Explicar por que escrever no bit de modo precisa ser privilegiado — e o que aconteceria se não fosse.
• Classificar oito eventos em interrupção, exceção ou trap, justificando pela origem no tempo.
• Listar as quatro parcelas da latência de interrupção e dizer quais o SO controla.
• Explicar por que uma troca de contexto custa mais do que os registradores salvos.
• Dizer, para cada linha do quadro-resumo, o que o SO perderia sem aquela peça de hardware.