No código temos:

LDR	r1, =0x20026		
SWI	0x123456

que se refere a uma software interrupt pedindo um servico do monitor da placa evaluator7t. Como estamos rodando de forma simulada, essa software interrupt irá travar o gdb. Assim, nao rodem o SWI (basta colocar um breakpoint). Uma pergunta interessante é:

• qual a diferenca entre LDR e MOV? Observem que ambas as instrucoes carregaram valores imediatos nos registradores. A diferenca é que com LDR é possível carregar valores quaisquer de 32 bits enquanto que com o MOV não. Isso será importante para a questao 3.10.1

No ambiente codewarrior existe um make. Durante o nosso curso, nao precisaremos do make uma vez que o proprio arm-elf-gcc dispara o assembler e o linker. Para ver o que foi gerado pelo arm-elf-gcc basta fazer:

$ ls -alt|more

Esse comando coloca no topo os arquivos recentemente modificados ou criados. Apenas relatem o que foi feito - uso do arm-elf-gcc, geracao do arquivo e arm-elf-gdb para rodá-lo.

A pergunta 2.4.2 pergunta sobre a diferenca entre step e stepin no codewarrior . Para o gdb, a pergunta se refere a: step: passo a passo entrando na rotina next: passo a passo mas sem entrar na rotina. Existe um problema GRAVE no uso do next. O arm-elf-gdb misteriosamente se perde ao ver um label como:

  mov r0,1
label:
  move r0,2

Ao executar mov r0,1; o debugger nao pula para a instrucao seguinte usando next. Por isso, muito preferencialmente use 'step'.

Se quisermos ver os registradores na tela do arm-elf-gdb usando C-x 2, teremos dois formatos hexa e decimal. Porém, é possível observar memória e registradores em outros formatos. Veja o manual do gdb - http://sourceware.org/gdb/download/onlinedocs/gdb/index.html Exemplos:

p/x $pc
p/x $cpsr
x/i $pc

Usando o help help x help p

Voce deve ter observado que x - serve para ver memoria externa.

x/d $r1

apresenta o conteudo de r1 em hexadecimal e o conteudo apontado por r1 na memoria em decimal.

p/d $r1

apresenta o conteudo de r1 em decimal.

Uma forma !!!PERIGOSA!!! de ver os bits do registrador de status eh:

p/t $cpsr

porem, os primeiros zeros serao OMITIDOS e voce pode estar vendo menos que 32 bits. Tome cuidado! Compare o cpsr com o comando "info registers". A forma segura eh:

p/x $cpsr

ADD r0, r1, #0xc5, ROR 10 ver desenho na pagina 3-6.

1100 0101 para a direita em um registrador de 32 bits

depois de rodar 8 vezes temos

1100 0101 0000 … e depois de 10 vezes temos:

0011 0001 0100 …

o que fornece um o resultado da apostila:

31 40 00 00 0011 0001 0100 0000 0000 0000 0000 0000

Use LDR para carregar valores de 32 bits em registradores. Ao inves de fazer:

mov r1,#0x12345678

faça:

ldr r1,=0x12345678

ADD nao atualiza as flags do CPSR ADDS atualiza as flags do CPSR.

Se representarmos numeros em 4 bits em complemento de 2, podemos representar desde o -8 ateh o 7. Ao somarmos -1 e 1 temos carry mas nao temos overflow. Somando 5+4, temos que 9>7 e portanto temos o overflow.

• no resultado tivemos a flag N setada, embora multiplicamos dois numeros negativos (e o resultado deveria ser positivo). Isso deve ter acontecido porque o bottom foi "negativo" e a flag foi atualizada depois do resultado.

O resultado faz sentido? Se quisermos observar o bottom (32 bits menos significativos) contendo o numero todo, temos que multiplicar numeros que caibam em representacoes de 16 bits. Para entender melhor veja no site da ARM, a especificacao da instrucao MUL. http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0068b/CIHIHGGJ.html

Obs: Na apostila ARM Lab Manual temos na pg 3-5 UMULL r6, r8, r0, r1 ; {r6,r8} = r0 × r1 onde aparentemente r6 eh o mais significativo. Pelo site da ARM temos que o r6 (primeiro argumento) eh o menos significativo.

• pense em algum shift.
• use MOV com deslocamento. Veja:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/BABHGAJI.html

• tragam numa folha (nao vale no computador), a solucao rascunhada a mão do exercicio de divisao 3.10.7; ou seja, como é o algoritmo da divisao. Nao eh para trazer todo o algoritmo em codigo ARM já implementado, mas se quiser coloque algumas partes em codigo ARM. A operacao de divisao deve ser feita com shift como faz a profa. do primário e nao o algoritmo ineficiente e simples que retira um numero do outro.

Veja: http://courses.cs.vt.edu/~cs1104/Division/ShiftSubtract/Shift.Subtract.html e coloque no papel a simulacao de 1101 dividido por 10.

nao percam tempo com a restricao da apostila: usem instrucoes condicionais para facilitar. No cap. 5 da apostila existe uma tabela com todas as condicoes possiveis. Uma dica para se ter o absoluto de um numero eh fazer (zero - numero) caso o numero seja negativo. De preferencia, facam primeiro o exercicio 3.10.6 .

o arm-elf-gcc nao estah compilando uma instrucao que lide com RRX como mov … RRX porem compila outras como mov … ROR

• Erro na apostila ARM Lab Manual: A sequencia b010 011 001 000 101 111 110 100 nao eh um codigo de gray de 3 bits (ex: erro ao passar de 000 para 101 alterando dois bits). O codigo pode ser

000 001 011 010 110 111 101 100. Se tiver duvidas em como se forma o codigo gray, consulte o wikipedia.

B.1) Descreva o conteúdo do registrador R13 depois que as seguintes instruções forem executadas, assumindo que a memória contenha os valores mostrados abaixo. O registrador R0 contém 0x24, e o sistema de memória é little-endian (o menos significativo é colocado no endereco mais baixo).

LDRSB r13, [r0]
LDRSH r13, [r0]
LDR r13,[r0]
LDRB r13,[r0]

B.2) Indique se as seguintes instruções usam o modo pré ou pós indexado de endereçamento:

STR r6, [r4,#4]
LDR r3, [r12], #6
LDRB r4, [r3,r2]!
LDRSH r12, [r6]

B.3) Calcule o endereço efetivo das seguintes instruções se o registrador r3 = 0x4000 e o registrador r4 = 0x20

STRB r9, [r3,r4]
LDRB r8,[r3,r4,LSL #3]
LDR r7, [r3], r4
STRB r6, [r3], r4, ASR #2

B.4) O que há de errado na seguinte instrução? Veja "incorrect example" em: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0068b/Chdbifed.html

LDRSB r1,[r6],r3,LSL #4

Cada equipe deve trazer numa folha de papel a resposta em letra de mao (nada de coisa impressa) para a seguinte pergunta. Escreva o código em Assembly que faça:

for (i=0; i<8; i++) {
  a[i] = b[7-i];
}

Vai ter mais nota quem colocar o programa mais proximo da realidade; ou seja, evitem usar pseudo instrucoes. Para observar um codigo bem proximo da realidade, sugiro instalar o gnuarm na maquina de voces e testar. Procurem usar as seguintes instrucoes em seu código: LDR ou ADR (isto é: declarem os dados na memória e leiam de lá; por exemplo, onde comeca o a array b e a array a). BGE (usem instrucoes que facam o desvio condicional, nao necessariamente BGE). RSB (para o 7-i) STR (isto é: armazene de fato o dado na memória).

4.3.1 Direct loading with MOV and MVN

MOV r0, #0x1, 30 ; r0 = 1020         32 - 30 = 2; 2 ** 2 = 4 portanto pula de 4 em 4.
MOV r0, #0xFF, 28 ; r0 = 4080        32 - 28 = 4; 2 ** 4 = 16 portanto pula de 16 em 16.
MOV r0, #0x1, 26	 ; r0 = 4096   32 - 26 = 6; 2 ** 6 = 64 portanto pula de 64 em 64.

mas na realidade eh:

│0x8218 <main>           mov    r0, #4           1 *4 = 4                                 │
│0x821c <main+4>         mov    r0, #4080        255 * 16 = 4080                          │
│0x8220 <main+8>         mov    r0, #64 ; 0x40   1 * 64 = 64.

5.5.4 Finite state machines: a nonresetting sequence recognizer

Se vc. considerar que nao eh necessario usar MOVNE, delete essa instrucao do codigo sugerido. (mas talvez precise sim - um registrador nao pode ser origem e destino na multiplicacao).

se quiser, declare um numero binario como: 0b10101 dentro do codigo.

1 O que há de errado com as seguintes instruções:

a) STMIA r5!, {r5, r4, r9}
b) LDMDA r2, {}
    STMDB r15!, [r0-r3, r4, lr}

2 Se o registrador r6 possui 0x8000 (como ponteiro para a memória); após executar

LDMIA r6,{r7,r4,r0,lr}

o que fica em r0, r4, r7 e em lr?

3 Assuma que a memória e registradores estejam:

r0=0x13; r10xffffffff; r2 = 0xeeeeeeee; r3 0x8000

Descreva a memória e conteúdos dos registradores após a instrução:

LDMIA r3!, {r0,r1,r2}

4 Suponha que a pilha esteja como o diagrama abaixo. Que instrução seria necessária para sair do estado original e ir para o estado a), depois b) e depois c)?

Voce pode escolher entre:

• apresentar o codigo rodando no seu PRÓPRIO computador no comeco de aula
• ou rascunho no papel.

6.5.2 Bubble sorting 6.5.3 Magic Squares

dado um numero, identificar se ele é primo.

colocar em um vetor, na memoria, os primeiros 30 numeros primos.

2 horas.

como planejamento rascunhem a solucao de cada um dos exercicios abaixo trazendo isso em PAPEL (retirarei pontos caso nao seja em papel rascunhado - nao deve ser impresso).

Os exercicios abaixo devem ser feitos com um cuidado extra mostrando como o codigo assembly faz de fato a entrada e saida, passo a passo. Nao existe informacao suficiente na apostila e por isso estou passando em anexo o manual da placa dui…pdf. Vejam o capitulo 3 - Programmer's reference do arquivo dui…pdf que contem codigo em C para o acessos dos leds, display de 7 segmentos e dip switches. Para o planejamento serah importante observar esse codigo e transpor para o assembly do ARM. O documento UM_KS … eh o data sheet do ARM produzido pela Samsung. Os enderecos dos registradores estao no item 7.4.1 do ARM Lab Manual.

Se tiverem duvidas, perguntem.

Dica: Voce farah algo da seguinte forma para lidar com registradores. Como eles estao mapeados em memoria, acessamos os registradores como se estivessemos acessando a memoria normal.

- Escrevendo 0xf0 no IOPMOD:
ldr	r0, =0x3ff5000 	@ IOPMOD
ldr	r2, =0xf0	@ seta 1 nos bits [7:4]
str	r2, [r0]	@ seta IOPMOD como output

7.5.1 - Escrita nos LEDS Displaying the hex digits in binary to the surface-mounted LEDs Write ARM assembly to flash the hex digits in binary form to the surface-mounted LEDs in ascending order. Now slightly modify the code to flash the digits in descending order. Make sure to use a delay so that the digits can be seen. The digits should not stop flashing.

Para o delay crie um loop onde o registrador R0 eh inicializado com 0xfffff e eh decrementado ateh zero.

7.5.3 - Escrita no display de 7 segmentos Displaying the contents of a memory location to the seven-segment display Write ARM assembly to inspect memory location 0x4000. If the location contains a decimal number in the range 0-15, display the contents in hex on the seven-segment LED display. As an example, if 0x4000 contains 14, display an E.

7.5.5 - Leitura dos dip switches Displaying the value of the DIP switches to the surface-mounted LEDs Write ARM assembly to inspect DIP1 to DIP4, which act like four binary digits. Display the contents in binary on the surface-mounted LEDs. See Figure 2-10 of Evaluator-7T User Guide for bit assignments

• O professor passou segment.c, segment.h. Gere o arquivo segment.o e execute no kit. Veja que aparece um numero no display. Note que segment.c imprime o numero no main. Ver PASSO-1 da apostila.

A apostila foi feita para se rodar a experiencia na placa evaluator-7t

arm-elf-gcc segment.c –o segment.o

porém, para debugar voce precisa adicionar a opcao -g

arm-elf-gcc -g segment.c –o segment.o

• crie a funcao imprime em segment.c que recebe um numero e coloca esse numero no display. Para isso basta retirar do main a parte pertinente. Compile e teste. Ver PASSO-2 da apostila.
• crie o arquivo imprime.c com a funcao imprime gerada no item anterior. O codigo executavel eh gerado atraves de: arm-elf-gcc -g imprime.c segment.c -o segment.o; teste o codigo gerado. Ver PASSO-3 da apostila.
• compile imprime.c gerando seu objeto: arm-elf-gcc -S impime.c (gerando imprime.s). Refaca o codigo usando imprime.s + segment.c. Teste. Ver PASSO-4 da apostila.

No passo 4, existem duas formas de gerar o arquivo .elf para ser executado na placa:

a) O gcc faz tudo (monta e linka): arm-elf-gcc –g imprime.s segment.c –o segment.o

b) O gcc soh compila:

Para o segment.c e para o imprime.c fazer:

arm-elf-gcc -S segment.c
arm-elf-as -o segment.o segment.s

E depois linkar o segment.o e imprime.o usando arm-elf-ld. Porém utilize a forma a) para evitar problemas com linkar com a biblioteca do ambiente (para uma funcao usada para chamar o main e para o printf).

O grande objetivo da aula de hoje eh entender o vetor de interrupcao. Para a aula de hoje, ele deve obrigatoriamente ser posicionado em zero. Uma forma de declarah-lo em assembly eh:

.section INTERRUPT_VECTOR, "x"
.global _Reset
_Reset:
  B Reset_Handler /* Reset */
  B . /* Undefined */
  B . /* SWI */
  B . /* Prefetch Abort */
  B . /* Data Abort */
  B . /* reserved */
  B . /* IRQ */
  B . /* FIQ */
 
Reset_Handler:
  LDR sp, =stack_top
  BL c_entry
  B .

O vetor de interrupcao eh defindo pela ARM. Quando a placa eh resetada, o PC eh colocado na posicao zero. Quando uma instrucao indefinida for encontrada dentro de um codigo, o PC recebe 4; quando ele executar uma instrucao SWI (ou svc), o PC recebe 8 e assim por diante. Por isso, devemos ter os Branchs (B) para o tratamento de cada excessao.

Vamos rodar o programa em http://balau82.wordpress.com/2010/02/14/simplest-bare-metal-program-for-arm/ usando http://linux-kernel-lab.blogspot.com/2018/04/basics-on-arm-processor.html . Nao serah necessario instalar nada, pois temos tudo nessa imagem (qemu e arm-none).

e rode esse programa. O interessante é o startup.s que contém a inicializacao do vetor de interrupcao e faz o codigo rodar a partir da posicao zero.

No README.md de https://github.com/EpicEric/gcc-arm.git lemos como gerar os programas e rodah-los:

### Regular program

```
eabi-gcc c_entry.c -o c_entry.o
eabi-as startup.s -o startup.o
eabi-ld -T vector_table.ld c_entry.o startup.o -o program.elf
eabi-gdb program.elf
```

### Code on emulated board with QEMU

```
eabi-gcc c_entry.c -o c_entry.o
eabi-as startup.s -o startup.o
eabi-ld -T vector_table.ld c_entry.o startup.o -o program.elf
eabi-bin program.elf program.bin
qemu program.bin
```

In another terminal, open the same container with `./run_docker.sh` (without parameters).

```
eabi-qemu -se program.elf
[gdb] break c_entry
[gdb] continue
[gdb] ...
[gdb] quit
pkill qemu

Siga os passos em http://balau82.wordpress.com/2010/02/14/simplest-bare-metal-program-for-arm/ e rode esse programa.

A fim de imprimir "Hello World" usando o qemu (target remote:1234), vamos usar 2 posts do Balau:

1. http://balau82.wordpress.com/2010/02/28/hello-world-for-bare-metal-arm-using-qemu/
   • usa qemu e imprime string, endereco no vetor de interrupcao = 0x1000
2. http://balau82.wordpress.com/2010/02/14/simplest-bare-metal-program-for-arm/ - usa simulador e nao imprime nada, endereco do vetor de interrupcao = zero.

O que usa o simulador faz um print e o outro que usa o qemu nao printa nada. Por isso vamos rodar basicamente o segundo post, mas fazendo com que se imprima "Hello World" como no primeiro post. Portanto, vamos seguir a risca a forma de rodar o codigo do post hello-world-for-bare-metal-arm-using-qemu passando o test.ld e startup.s (com endereco zero) do segundo post para o primeiro.

Observe que em http://balau82.wordpress.com/2010/02/28/hello-world-for-bare-metal-arm-using-qemu/

o código passa a executar a partir de 0x1000 e não a partir do zero. Isso nao eh o que ocorre quando se faz o boot de uma placa. Provavelmente o Balau fez dessa forma, porque toda placa/simulador vem com um código em eprom que deve ser emulado que corresponde justamente ao código de boot. O que nos interessa nesse post eh a funcao print_uart0.

Observe que em http://balau82.wordpress.com/2010/02/14/simplest-bare-metal-program-for-arm/ o codigo estah escrito como acontece em uma placa de verdade, no caso a placa versatile que estah sendo emulada pelo qemu. Use test.ld (o ldscript) e statup.s desse post para fazer o código rodar a partir de 0x0 como acontece em uma placa real. Esse post nao explica como fazer a placa imprimir; por isso precisamos do primeiro post. Observe:

• o startup.s desse post contém o vetor de interrupcao na posicao zero.
• Quando ativamos o gdb para se contectar com o qemu usando o alias eabi-qmeu; executamos o script em gcc-arm/docker/files/.gdbinit/qemu abaixo. Observe que esse script faz a contexao com o qemu via target remote e apos isso, faz load. Este load irah carregar o seu programa na posicao zero no lugar do firmware da placa.

layout regs
target remote localhost:1234
load

• usem o test.ld abaixo que coloca o vetor de interrupcao em zero; nao usem o test.ld que coloca na posicao 0x1000.

ENTRY(_Reset)
SECTIONS
{
 . = 0x0;
 .text : {
 startup.o (INTERRUPT_VECTOR)
 *(.text)
 }
 .data : { *(.data) }
 .bss : { *(.bss COMMON) }
 . = ALIGN(8);
 . = . + 0x1000; /* 4kB of stack memory */
 stack_top = .;

Depois que conseguir imprimir "Hello World" usando o qemu, coloque um breakpoint antes de imprimir o "Hello World" e analise o cpsr. Qual é o modo em que o processador executa? Verifique se está em "Supervisor Mode". Qual é o valor de sp?

Consulte o cpsr em:

• ⁵ ARM Laboratory Exercises - apostila - http://courses.cs.tamu.edu/rabi/cpsc617/resources/ARM%20Lab%20Mannual.pdf

no capitulo 1, item 1.6.4

Voltando para http://balau82.wordpress.com/2010/02/28/hello-world-for-bare-metal-arm-using-qemu/, crie a funcao Undefined em C que imprime a string "instrucao invalida!" e fique em um loop infinito. Pendure essa funcao no vetor de interrupcao na posicao correspondente a undefined instruction. Observe que dentro do gdb é necessário executar o "load" após o "target".

Toda instrucao corresponde a uma word na memoria. Ex: "MOV R0,R1" corresponde a uma word que pode ser vista como um numero hexadecimal. Alguns numeros fazem sentido (podem ser executados) e outros nao fazem sentido. Por exemplo, a word 0xffffffff eh uma instrucao invalida.

Coloque uma instrucao invalida (0xffffffff) em startup.s (com o startup.s inicializando o codigo em 0x0). Para isso:

Reset_Handler:
	LDR sp, =stack_top
	BL c_entry
	.word 0xffffffff
	B .

Rode o test.elf com a instrucao invalida. Observe se a string eh impressa. Talvez voce tenha visto um lixo sendo impresso ou o qemu tenha travado. Vamos corrigir em seguida.

O motivo foi que o ponteiro de pilha r13 no modo undefined nao foi inicializado. Veja a figura 1-2 do ARM Lab Manual. Observe os registradores no modo supervisor e no modo undefined. O registrador R0 no modo supervisor e no modo undefined sao os mesmos porque nao estao marcados (nao estao shaded), assim como a maioria dos outros registradores. Contudo, o registrador R13 e R14 sao diferentes, estao marcados/shaded, dependendo do modo, tanto que o R13 no modo supervisor eh chamado de R13_supervisor e no modo undefined R13_undefined. Quando o processador passa de um modo para outro, ele passa a usar o R13 correspondente ao modo e se ele nao estiver inicializado teremos mproblemas.

Coloque um breakpoint antes e depois da instrucao invalida e analise o cpsr. Tente observar a mudanca de modo do processador. Conseguiram? Se sim, observe a mudanca no registrador sp (provavelmente o sp no modo Undefined está zerado ou com um valor qualquer. Verifique isso; portanto, qualquer alteracao de pilha nesse modo pode levar a erros com o sp errado). Se nao conseguiram, vejam o Undefined Handler no proximo item e observem a mudanca de modo dentro do Undefined Handler.

Pendure o seguinte Undefined_Handler no vetor de interrupcao em startup.s (certifique-se de que o ld script coloca o codigo em 0x0):

Undefined_Handler:
	LDR sp, =stack_top
	BL undefined

Coloque um breakpoint dentro do Undefined_Handler para observar a mudanca de modo no registrador de status.

Existem 2 erros nesse Undefined_Handler

• a pilha nao deve ser inicializada a cada entrada na rotina de excessao. Veja o proximo item - a pilha no Undefined mode.
• o retorno estah errado.

Quando o processador chaveia de modo, o registrador r13 de um modo não é o mesmo registrador r13 que no outro modo; por isso é necessário inicializar os sp's de todos os modos logo no reset da placa como visto na aula passada. Veja o item 1.6 "The ARM register set" da apostila de ⁵ e observe se existem outros registradores que variam conforme o modo do processador. Para evitar problema no uso da pilha no modo Undefined, é necessário que Reset_Handler inicialize também o ponteiro de pilha R13_UNDEF (registrador r13 no modo undefined). Inicilize R13_UNDEF com o valor 0x2000 e inicialize o R13_SVC (do supervisor) em 0x1000. Para isso é necessário utilizar a instrucao MSR (Move to Status Register). Usando MSR vah para o modo undefined e altere o R13. Esse R13 no modo undefined (R13_UNDEF) eh diferente do R13 no modo supervisor. Depois volte ao modo supervisor. Descubra o número a ser carregado em MSR (observando principalmente o modo e desabilitando as interrupcoes. Exemplo de como se altera a pilha:

MRS r0, cpsr    @ salvando o modo corrente em R0
MSR cpsr_ctl, #0b11011011 @ alterando o modo para undefined - o SP eh automaticamente chaveado ao chavear o modo
LDR sp, =undefined_stack_top @ a pilha de undefined eh setada 
MSR cpsr, r0 @ volta para o modo anterior

Pergunta:

• A pilha do Undefined eh inicializada onde?

resposta:

• Reset_Handler pois a pilha do Undefined nao deve ser alterada logo na entrada do Undefined_Handler - o erro eh semelhante a alterar o topo da pilha ao chamar uma funcao!

Refaça o item anterior observando se sp é alterado corretamente na troca de modos.

Crie o undefined handler em assembly de forma que ele salve e recupere os registradores. Veja:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0471c/Ciheidgb.html

Explique como o processador volta para o modo anterior ao sair do undefined handler. Rode o programa passo a passo observando os registradores e cpsr sendo salvos e recuperados.

A instrucao:

LDMFD sp!,{R0-R12,pc}^

serah a ultima a ser executada pelo undefined_handler. Ela deve fazer com que o pc continue a partir da instrucao indefinida com o modo anterior (no caso supervisor). Como essa instrucao faz isso?

Responda:

• por que tem um chapeuzinho no final da instrucao? Para que serve isso?
• por que essa instrucao nao salva os registradores r13 e r14?
• se essa eh a primeira instrucao a ser executada, o sp jah deve ter sido inicializado. Quem fez isso? (voce jah deve ter feito isso logo quando a placa eh incializada usando a instrucao MSR para chavear o modo e inicializar o sp).

Antes de escrever a instrucao de store que salva os registradores no comeco do undefined_handler coloque um breakpoint na entrada do undefined_handler e veja onde estah o endereco de retorno. Estah na pilha ou no registrador LR? Agora acerte o undefined_handler com as instrucoes que armazenam e recuperam o estado da pilha com o STMFD.

Agora, em seu codigo faca com que primeiro seja executada a instrucao indefinida e depois imprima o "Hello World" a fim de testar se o retorno do handler de undefined instruction estah funcionando. Apresente isso ao professor.

Embora existam diversos modos no ARM, podemos classificar em usuário e o resto. Quando o ARM comeca a executar está em modo supervisor. Passe para o modo usuário usando MSR e tente voltar do modo usuário para supervisor também usando MSR. O que acontece? Por quê? Refaca a experiencia trocando entre modos dentro do resto (undefined, abort, supervisor, etc.). O que acontece? É possível concluir então que existem dois grandes modos: usuário e supervisor?

TST r0, #0x0010 @verifica se é uma interupção de timer BNE handler_timer @vai para o rotina de tratamento da interupção de timer

A instrucao TST faz o ANDS bit a bit e seta a flag Z (usada pelo BNE) caso o resultado seja zero. O importante eh olhar se o bit estah setado. Se estiver, entao o resultado nao eh zero e por isso eh feito o desvio para o handler_timer.

As pilhas no modo supervisor e no modo IRQ nao sao inicializadas. Com base na experiência da aula passada, ajuste isso; usando MSR. Se voce nao fizer isso, terah problemas graves ao ocorrerem as interrupcoes porque o codigo nao vai retornar para a posicao certa antes da interrupcao.

Observe o codigo

do_irq_interrupt: @Rotina de interrupções IRQ
   STMFD sp!, {r0 - r3, LR}
   @Empilha os registradores
   LDR r0, INTPND @Carrega o registrador de status de interrupção 
   LDR r0, [r0]
   TST r0, #0x0010 @verifica se é uma interupção de timer
   BNE handler_timer @vai para o rotina de tratamento da interupção de timer
   LDMFD sp!, {r0 - r3,lr}
   mov pc, r14
   @retorna

O retorno do IRQ está errado em:

mov pc, r14

r14 é o LR. O LR é automaticamente setado pelo processador ARM quando ocorre a IRQ; porém da seguinte forma: LR = endereco_deretorno + 4 devido ao pipeline. Para resolver isso é necessário fazer retirar 4 de LR.

• Obs - logo ao entrar na rotina de interrupcao, observe para qual instrucao o LR aponta atraves de:

x/i $lr

depois de subtrair 4 de LR, observe novamente

x/i $lr

Agora faz sentido? Isso ocorre por que a propria ARM define assim; meu chute eh pelo pipeline que andou no irq, mas nao andou no undefined (visto na aula passada).

As duas instruções:

LDMFD sp!, {r0 - r3,lr}
mov pc, r14

não recuperam o cpsr anterior. Isso acarreta um problema. O CPSR contém um bit que diz se o processador atende as interrupcoes IRQ ou não. Logo quando ocorre a interrupcao o bit I do cpsr eh zerado para desabilitar que uma interrupcao ocorra dentro de outra. Como o CPSR nao retorna ao valor anterior, ele permanece com as interrupcoes desabilitadas. Com base nessa informacao, altere o código de forma a que a rotina de interrupcao IRQ TERMINE com:

LDMFD sp!,{R0-R12,pc}^

como vimos na aula passada e explicado em http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0471c/Ciheidgb.html

• Obs1: vários alunos trocaram a instrucao LDMFD sp!,{R0-R12,pc}^ por algo como LDMFD sp!,{R0-R12,lr}^ e depois alteraram o pc. Isso nao funciona pois o modo de operacao (e pilhas e backed registers) jah foram alterados. Eh obrigatorio executar LDMFD sp!,{R0-R12,pc}^ para retornar da rotina de interrupcao.
• Obs2: Se sua equipe nao estiver conseguindo retornar da interrupcao rodando LDMFD sp!,{R0-R12,pc}^ observe a pilha. Coloque um breakpoint nessa instrucao e examine como estah a pilha observando o sp. Os valores que estao na pilha correspondem aos que serao colocados nos registradores, e em especial no pc? O retorno deve ser para o loop infinito do programa principal. Esse endereco de retorno estah de fato na pilha? Ao observar o endereco de retorno na pilha, voce pode observar a instrucao que serah executada atraves do comando do debugger x/i ENDERECO.

Alguns alunos consideraram que o mais correto eh usar BLNE ao inves de BNE. Isso nao eh necessario, depende de como handler_timer retorna. A ideia da apostila era retornar para o loop do programa principal diretamente, portanto nao cosideramos isso como um erro da apostila. Contudo, o codigo da apostila nao estah elegante. O melhor eh fazer como no codigo abaixo usando BLNE e fazer handler_timer retornar para quem chamou ao inves de fazer LDMFD.

do_irq_interrupt: @Rotina de interrupções IRQ
   STMFD sp!, {r0 - r3, LR}
   @Empilha os registradores
   LDR r0, INTPND @Carrega o registrador de status de interrupção 
   LDR r0, [r0]
   TST r0, #0x0010 @verifica se é uma interupção de timer
   BLNE handler_timer @vai para o rotina de tratamento da interupção de timer
   LDMFD sp!, {r0 - r3,lr}
   mov pc, r14    @retorna

• debugue o codigo: rode até a instrucao LDMFD sp!,{R0-R12,pc}^ e examine a pilha. Verifique se o valor a ser carregado em PC está correto.
• Observe o código de inicializacao:

 mrs r0, cpsr
timer_init:
 bic
 r0,r0,#0x80
 msr cpsr_c,r0 @enabling interrupts in the cpsr
 LDR r0, INTEN
 LDR r1,=0x10 @bit 4 for timer 0 interrupt enable
 STR r1,[r0]
 LDR r0, TIMER0C
 LDR r1, [r0]
 MOV r1, #0xA0 @enable timer module
 STR r1, [r0]
 LDR r0, TIMER0V
 MOV r1, #0xff @setting timer value
 STR r1,[r0]
 mov pc, lr

• Coloque um breakpoint logo no início da interrupcao de timer e rode até lá. Qual é o modo em que o processador roda? Qual é o sp? O que se vê na pilha? Como o PC é salvo na chamada da interrupcao?
• Como o processador chaveia de modo ao sair da rotina de interrupcao? Verifique isso localizando a instrucao que faz isso. Quando estamos debugando passo a passo e observamos que o processador sai da rotina de interrupcao, pode acontecer do timer da maquina virtual continuar marcando o tempo e como nós seres humanos somos muito mais lentos que a máquina, é bem provável que logo ao sair da rotina de interrupcao, já tenha ocorrido outra interrupcao de timer. Verifique se isso acontece.

• Qual é a instrucao que habilita as interrupcoes? Desabilite as interrupcoes no cpsr e rode. O que acontece? Voce acha razoavel habilitar as interrupcoes enquanto se programa o timer? De fato isso nao eh razoavel, primeiro deve-se programar o timer para depois habilitar as interrupcoes. Isto eh: alterar cpsr zerando o bit I deve ser a ultima operacao a ser feita. Altere isso no codigo. Veja se funciona.
• Se tudo estiver correto, anexe esse código no email a ser enviado ao professor.

• Como o código definiu o vetor de interrupcao? Responda relacionando com o ARM e o ldscript.

• Observe como foi feita a programacao do timer em timer_init. A apostila faz

LDR r0, TIMER0V
MOV r1, #0xff @setting timer value
STR r1,[r0]

Isso nao estah de acordo com a documentacao em http://infocenter.arm.com/help/topic/com.arm.doc.ddi0271d/DDI0271.pdf pois o registrador TIMER0V eh para se ler o valor do timer, enquanto o registrador TIMER0L eh para se fazer a carga do valor inicial. Assim, consideramos que a programacao correta do timer deveria ser:

LDR r0, TIMER0L
MOV r1, #0xff @setting timer value
STR r1,[r0]

• Qual é o modo em que o processador roda logo no início enquanto o timer está sendo configurado? Qual registrador deve ser observado? Qual é sp utilizado?

O Mitsuo/2018 pensou no modo e na sequencia de programacao do timer, de tal forma que a alteracao do TIMER0L, altera o intervalo das interrupcoes. Troque o timer_init no seu codigo pelo codigo abaixo e faca experiencias alterando o valor de TIMER0L.

timer_init:
 LDR r0, INTEN
 LDR r1,=0x10 @bit 4 for timer 0 interrupt enable
 STR r1,[r0]
 LDR r0, TIMER0L
 LDR r1, =0xffffff @setting timer value
 STR r1,[r0]
 LDR r0, TIMER0C
 MOV r1, #0xE0 @enable timer module
 STR r1, [r0]
 mrs r0, cpsr
 bic r0,r0,#0x80
 msr cpsr_c,r0 @enabling interrupts in the cpsr
 mov pc, lr

O código está todo em assembly, mas é possível codificar parte dele em C. Para isso precisamos de seguir diversos passos:

• observe o código de handler_timer:

handler_timer:
	LDR r0, TIMER0X
	MOV r1, #0x0
	STR r1, [r0] @clear timer interrupt

	@ do whatever you want with the timer here

	LDMFD   sp!, {r0 - r3,lr}	 
	mov pc, r14

A instrucao mov pc, r14 corresponde ao retorno de do_irqinterrupt (feito de forma errada) e não de handler_timer.

• Altere o código assembly para que handler_timer seja uma rotina estanque chamada em do_irqinterrupt através de:

BLNE handler_timer; ou seja, handler_timer deverá se comportar como uma rotina normal que retorna para quem chamou. Verifique usando o qemu+gdb se voce consegue entrar na rotina handler_timer.

• Crie dois arquivos assembly irq.s e handler.s contendo handler_timer; verifique se funciona, observando duas ou mais interrupcoes de relogio e observe se o sp não está variando a cada chamada - se não está gradativamente empilhando coisas.

Observe que ao linkar, a ordem com que se colocam os objetos irq.o e handler.o eh extremamente importante. Deve-se colocar primeiro o codigo que contenha o vetor de interrupcao.

• Depois recodifique handler_timer em C. Ao fazer isso, declare um pointer em C referente a TIMER0X de forma a colocar o valor zero nessa posicao de memoria a fim de baixar o pedido de interrupcao. Nao eh preciso aproveitar a definicao de TIMER0X do assembly; eh muito mais facil declarar o ponteiro direto em C.

Obs: para exportar o nome handler_timer eh necessario usar .global

• A partir de agora, ao ativar o qemu retire a opcao que "mata" a serial: -serial /dev/null, pois caso contrário, voce não verá os caracteres na tela.
• Misture o codigo dessa experiencia com a da aula passada a fim de que o programa imprima uma vez "Hello World" no program principal, antes mesmo de programar o timer.
• Usando a experiência passada, faça com que o handler_timer em C imprima o digito "#" a cada interrupcao.
• Altere o programa principal para que ele fique em um loop continuamente imprimindo o digito " " (espaco) de tempo em tempo (fique em um loop para gastar tempo). Assim, na tela voce deverá ver " "s e "#"s intercalados.
• O que acontece se nao retirarmos o pedido de interrupcao na rotina que trata a interrupcao? Experimente deixando o programa rodar e explique. A frequencia com que os caracteres sao impressos varia se nao retirarmos o pedido de interrupcao? Ou seja, a relacao entre " "s e "#"s foi alterada? Explique no relatorio. Rode o programa de uma vez sem breakpoints. Em pelo menos uma equipe, aconteceu do resultado ser diferente rodando passo a passo pois nesse caso, o 1 e 2 eram intercalados enquanto que rodando de uma vez o resultado era o esperado (somente a rotina de interrupcao imprimia).

IMPORTANTE: Nao saia da aula sem apresentar os ' 's e '#' sendo impressos.