Antes de continuar, é preciso abrir um parênteses para explicar o que acontece quando o processamento normal do microntrolador é alterado por uma interrupção (leia os posts I e II antes, caso esteja começando por este!). Obviamente isto é uma questão dependente do hardware mas existem algumas ações esperadas. Como o ponto do processamento irá mudar para que a interrupção seja atendida (posição de memória diferente), o contexto do sistema precisa ser salvo, isto é, uma foto dos registros e modo de operação do processador naquele instante, para que isto possa ser posteriormente recuperado quando a interrupção terminar. Em geral, é comum realizar o salvamento de:
- O contador de programa, mais conhecido como program counter (PC), que indica onde está a execução no momento da interrupção. Em geral o PC é um registro que armazena o valor do endereço de memória da próxima instrução a ser executada. Sem dúvida, algo necessário para se achar novamente o fio da meada.
- O ponteiro da pilha ou stack pointer (SP). O SP indica a posição corrente do stack, podendo apontar para o endereço de memória da próxima posição livre na pilha. Algumas plataformas usam o SP de forma diferente, fazendo que ele aponte para a última posição ocupada. Fique atento.
- O registro de status, ou status register (SR), no momento da interrupção. Por exemplo, tinha um flag de overflow ligado no momento da interrupção ? Se sim, ele precisa estar ligado quando o contexto for restaurada.
- Registros de finalidade geral, totalmente dependentes da sua arquitetura.
Algumas arquiteturas, como a ARM7TDMI, possuem registros espelhados. Por exemplo, ao entrar no modo interrompido, você tem um registro específico para o SP em modo interrompido, trocado no momento da interrupção, automaticamente, pelo processador. Enfim, o que salvar é altamente dependente do processador que você está usando e não vai ter como seguir sem dar uma boa estudada no manual.
Para piorar, o seu compilador também pode influenciar neste processo. Por exemplo, se no atendimento de uma interrupção ele só usa um subconjunto dos registros, ele pode gerar um código assembly que só salve este subconjunto, gerando um chaveamento de contexto mais rápido do que salvar todos os registros. Não é a toa que plataformas como ARM permitem o salvamento simultâneo de vários registros, numa única instrução. Somente em assembly você vai ter controle pleno do que salvar ou não, mas vai ter muita dor de cabeça se seu código for grande (não para o Mel, claro).
No caso do MSP430, existem 16 registros:
- R0: PC - R1: SP - R2: SR - R3: CG (gerador de constantes) - R4-R15: Registros gerais
Ao acontecer uma interrupção, o processador coloca na pilha os valores correntes do SR e PC, automaticamente. Qualquer salvamento adicional é feito pelo compilador, na geração do código. Ou, se você está escrevendo em assembly, precisa salvar os registros que pretende usar dentro da sua função de interrupção na pilha e restaurá-los antes do retorno. O retorno de uma interrupção é feito com a instrução reti, que devolve os valores do PC e SR, voltando o contexto anterior. Só para fixar: apenas o SR e PC são feitos pelo processador, você (ou o compilador) é responsável pelos outros registros.
+------------------- +
| ... | -> outros valores na pilha
+--------------------+
| Status Register |
+--------------------+
| Program Counter | -> endereço de retorno
stack pointer -> +--------------------+
Bom, já deve ter ficado claro que este post é a base para o entendimento das mudanças de contexto pelo escalonador. Voltaremos nisso no próximo post.
Marcelo Barros
