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.

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

Para fazer os exericios, voce vai precisar de desvio condicional. Veja a tabela na apostila em: 5.2 Execution conditions . Exemplo de uso:

CMP R0,R1
BGT label

onde GT estah na tabela. Assim, podemos ter varios desvios condicionais como: BEQ, BNE e ateh mesmo BAL, mas como AL eh "default", use simplesmente "B" para o desvio incondicional. Em ARM eh possivel combinar qualquer instrucao com uma condicao. Ex: MOVEQ - move caso EQ.

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

mov r1,#0x12345678

faça:

ldr r1,=0x12345678

• no resultado tivemos a flag N setada, embora multiplicamos dois numeros negativos (e o resultado deveria ser positivo). A instrucao MULS (tem 1 L somente, nao confunda com MULLS), multiplica 2 numeros de 32 bits e coloca o resultado em um numero de 32 bits. Isso nao funciona bem. Vamos pensar em numeros de 4 bits variando de -8 a 7 em complemento de 2. Se multiplicarmos -1 e -8 em complemento de 2, temos +8. Porem, 8 nao pode ser representado em complemento de 2, 4 bits. A apostila quer mostrar que as flags foram atualizadas erradas nessa instrucao. Na verdade, nem as flags e nem o conteudo dos registradores eh confiavel dado que nao se consegue sempre multiplicar 2 numeros de 32 bits e colocar o resultado em 32 bits. O certo eh colocar o resultado em um numero de 64 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 . Se quisermos observar o bottom (32 bits menos significativos) em MULS contendo o numero todo, temos que multiplicar numeros que caibam em representacoes de 16 bits.

• pense em algum shift.
• use MOV com deslocamento. Veja: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/BABHGAJI.html

Retorne o printscreen da tela de SEU computador referente ao exericio 3.10.4, seguindo:

Write the ARM code to implement the above algorithm, and test it with the values of A = 0xF631024C and B = 0x17539ABD . Show your instructor the contents before and after the program has run.

Nao eh necessario anexar a tela do conteudo antes de rodar o programa, apenas depois. A tela deve conter:

• seu codigo e
• os registradores depois de ter rodado o codigo.

Cada equipe deve entregar um unico relatorio que estah na pasta do google drive compartilhada entre voces; porem todos devem realizar a atividade de entrega do relatorio proposta pelo google classroom para valer como nota de relatorio. O relatorio deve ser entregue ateh o final da aula, 17:10, assim a equipe deve trabalhar ateh 17:05 e reservar os minutos finais para a entrega do relatorio. Talvez algumas equipes nao vao conseguir fazer todos os exercicios ateh 17:10H, mas mesmo assim o relatorio deverah ser entregue ateh esse horario (se nao for, o sistema recusarah e nao aceitarah o relatorio). Sugiro que aqueles que nao conseguirem fazer os exercicios, facam depois da aula mesmo assim, para fins de aprendizado e para a prova que exigirah tais conhecimentos.

• 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.

Para fazer os exericios, voce vai precisar de desvio condicional. Veja a tabela na apostila em: 5.2 Execution conditions . Exemplo de uso:

CMP R0,R1
BGT label

onde GT estah na tabela. Assim, podemos ter varios desvios condicionais como: BEQ, BNE e ateh mesmo BAL, mas como AL eh "default", use simplesmente "B" para o desvio incondicional. Em ARM eh possivel combinar qualquer instrucao com uma condicao. Ex: MOVEQ - move caso EQ.

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. De preferencia, facam primeiro o exercicio 3.10.6 . Pequeno erro do UMULL na apostila explicado no item 3.10.2

Uma dica para se ter o absoluto de um numero eh fazer (zero - numero) caso o numero seja negativo.

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

Teste que deve funcionar:

• 1234567 por 1234

Teste que talvez falhe:

• 123456789 por 1234

Nao precisa de se preocupar caso esteja falhando para codigos onde o bit de sinal do dividendo seja 1.

• Erro1: Em: "The 2-bit Gray code occupies only bits [7:0] of r1, and the 3-bit Gray code occupies only bits [23:0] of r2."; deveriamos ter the 3-bit Gray code occupies only bits [15:0]
• Erro2 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.

(2 pontos) Formato: zip. Entregue ateh o final da aula os codigos fontes de cada exercicio em um arquivo zipado. No cabecalho de cada codigo, escreva como o arquivo deve ser gerado. Comente o codigo para voce mesmo entender na hora da prova. Caso tenha feito algum script para geracao do codigo (recomendado), anexe o script em seu codigo. Embora o codigo seja feito em grupo, a entrega eh INDIVDUAL.

(3 pontos) Formato: pdf. Entregue ateh o final da aula o relatorio (pdf) cada exercicio por seu grupo, com o codigo e screenshot do tela do gdb. Embora o relatorio seja feito em grupo, a entrega eh INDIVDUAL.

(5 pontos) Formato: png (ou jpg, imagem). Nao me anexe um zip com varias imagens! Entregue ateh o final da aula o screenshot do exercicio 3.10.7 - sobre a Divisao:

Write ARM assembly to perform the function of division. Registers r1 and r2 contain the dividend and divisor, r3 contains the quotient, and r5 contains the remainder. For this operation, you can either use a single shift-subtract algorithm or another more complicated one.

A divisao deve ser feita entre o seu numero USP e 1000 mostrando os registradores R1 (dividendo: seu numero USP), R2 (divisor: 1000), R3 (quociente), R5 (resto). Assim, retorne o screenshot da tela do gdb com os registradores, logo apos a divisao ter sido feita. O gdb deve estar mostrando duas telas: a tela contendo os registradores e a tela contendo o codigo. Retorne a foto (geralmente um arquivo .png) do screenshot. Nao me retornem um arquivo zipado.

B.1) Descreva o conteúdo do registrador R13 ou sp 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 sp, [r0]
LDRSH sp, [r0]
LDR sp,[r0]
LDRB sp,[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.           

(2 pontos) Formato: zip. Entregue ateh o final da aula os codigos fontes de cada exercicio em um arquivo zipado. No cabecalho de cada codigo, escreva como o arquivo deve ser gerado. Comente o codigo para voce mesmo entender na hora da prova. Caso tenha feito algum script para geracao do codigo (recomendado), anexe o script em seu codigo. Embora o codigo seja feito em grupo, a entrega eh INDIVDUAL.

(3 pontos) Formato: pdf. Entregue ateh o final da aula o relatorio (pdf) cada exercicio por seu grupo, com o codigo e screenshot do tela do gdb. Embora o relatorio seja feito em grupo, a entrega eh INDIVDUAL.

(3 pontos) Formato: png (ou jpg, imagem). Nao me anexe um zip com varias imagens! Entregue ateh o final da aula o screenshot do exercicio:

4.5.5 The Fibonacci sequence

com a serie de Fibonacci na memoria.

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.

(2 pontos) Formato: zip. Entregue no dia da aula os codigos fontes de cada exercicio em um arquivo zipado. No cabecalho de cada codigo, escreva como o arquivo deve ser gerado. Comente o codigo para voce mesmo entender na hora da prova. Caso tenha feito algum script para geracao do codigo (recomendado), anexe o script em seu codigo. Embora o codigo seja feito em grupo, a entrega eh INDIVDUAL.

(3 pontos) Formato: pdf. Entregue ateh o final do dia aula o relatorio (pdf) cada exercicio por seu grupo, com o codigo e screenshot do tela do gdb. Embora o relatorio seja feito em grupo, a entrega eh INDIVDUAL.

(3 pontos) Apresente o printscreen de 5.5.4 item 2 com X (R1) = 0x5555AAAA Y (R8) = 5 (padrao em binario = 0b101) nbits do padrao (R9) = 3 Apresente em seu printscreen as posicoes onde o padrao foi encontrado Z (R2).

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)?

Apresente o codigo assembly (nao eh necessario que esteja rodando, apenas eh necessario que vc tenha feito o codigo) de: 6.5.2 Bubble sorting

transmit the arguments by way of the stack with two subroutines, func1 and func2, that demonstrate stack functionality. É importante que o endereco de retorno seja colocado na pilha em func1. Declare os elementos na memoria usando .word (veja acima) e use o label ao inves de posicoes fixas como 0x4000, 0x4001, etc.

Bubble Sort 6.5.2.1. Usem load e store multiplo envolvendo 2 posicoes consecutivas de memoria quando fizerem a "bolha" andar. Embora no exercicio da apostila esteja como byte, usar word porque LDM… usa word.

Quadrado Magico Nao é necessário preocupar-se em colocar o quadrado mágico em 0x4000. É mais fácil declarar na memória ao final do programa algo como .word 1,4, … colocando as words do quadrado mágico.

More stacks Write ARM assembly to implement a push operation without the use of load/store multiple instructions. Write the code to handle bytes, half-words, and words. Use r0 to indicate the data type. A value of 1 in r0 indicates that a byte is to be pushed, 2 indicates a half-word, and 4 indicates a word. Put the data to push in r1.

Lembrar que sp eh sempre um multiplo de 4. Tem que tomar um certo cuidado ao empilhar byte ou half word para que o sp permaneca multiplo de 4; ou seja, dependendo do caso a memoria eh desperdicada.

O mais facil eh sempre alocar 4 bytes mesmo que seja para um byte apenas, desperdicando memoria. Se quiser fazer dessa forma bem facil, faca.

O mais dificil eh ir alocando memoria dependendo do tipo de dado, economizando memoria. Para byte, empilha no topo da pilha sempre; para half word, empilha no endereco multiplo de 2 mais proximo do topo; para word, empilha no endereco multiplo de 4 mais proximo do topo da pilha. Nao eh necessario ir para essa solucao mais dificil pois ainda teriamos o problema de como desempilhar sem dar problemas.

Dica para olhar a pilha no gdb:

x/20 $sp

(2 pontos) Formato: zip. Entregue no dia da aula os codigos fontes de cada exercicio em um arquivo zipado. No cabecalho de cada codigo, escreva como o arquivo deve ser gerado. Comente o codigo para voce mesmo entender na hora da prova. Caso tenha feito algum script para geracao do codigo (recomendado), anexe o script em seu codigo. Embora o codigo seja feito em grupo, a entrega eh INDIVDUAL.

(3 pontos) Formato: pdf. Entregue ateh o final do dia aula o relatorio (pdf) cada exercicio por seu grupo, com o codigo e screenshot do tela do gdb. Embora o relatorio seja feito em grupo, a entrega eh INDIVDUAL.

2 horas.

Adaptei de http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.100748_0606_00_en/lmi1470147220260.html o codigo seguinte:

arquivo: file:///home/jk/docker-labmicro/gcc-arm/src/add.s

	.text
	.globl   myadd
			
myadd:                     	@ Function "myadd" entry point.
	add      r0, r0, r1   	@ Function arguments are in R0 and R1. Add together and put the result in R0.
	mov	pc, lr           @  Return by branching to the address in the link register.

arquivo: file:///home/jk/docker-labmicro/gcc-arm/src/main.c

#include <stdio.h>
					
extern int myadd(int a, int b);
					
int main()
{
	int a = 4;
	int b = 5;
	printf("Adding %d and %d results in %d\n", a, b, myadd(a, b));
	return (0);
}

Observe que o codigo em C chama myadd que estah em assembly. No assembly, a funcao myadd recebe os parametros em R0 e R1 e retorna o resultado em R0. Existe uma convencao em como o C passa os parametros para uma funcao em assembly e como recebe o retorno da funcao. Veja "Chapter 2. Using the Procedure Call Standard" em http://infocenter.arm.com/help/topic/com.arm.doc.dui0056d/DUI0056.pdf

Para compilar:

student:~/src$ gcc add.s main.c

que gera o codigo a.out

Fazendo gdb a.out :

Loading section .jcr, size 0x4 vma 0x1097c
Start address 0x8110
Transfer rate: 139776 bits/sec.
(gdb) b main
Breakpoint 1 at 0x8230: file main.c, line 7.
(gdb) r
Starting program: /home/student/src/a.out 

Breakpoint 1, main () at main.c:7
(gdb) n
Adding 4 and 5 results in 9
(gdb) 

Repita o que foi feito, criando o seu primeiro codigo que mistura C e assembly.

(2 pontos) Formato: zip. Entregue no dia da aula os codigos fontes de cada exercicio em um arquivo zipado. No cabecalho de cada codigo, escreva como o arquivo deve ser gerado. Comente o codigo para voce mesmo entender na hora da prova. Caso tenha feito algum script para geracao do codigo (recomendado), anexe o script em seu codigo. Embora o codigo seja feito em grupo, a entrega eh INDIVDUAL.

(3 pontos) Formato: pdf. Entregue ateh o final do dia aula o relatorio (pdf) cada exercicio por seu grupo, com o codigo e screenshot do tela do gdb. Embora o relatorio seja feito em grupo, a entrega eh INDIVDUAL.

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:

• 16.1 ARM Laboratory Exercises - apostila - http://courses.cs.tamu.edu/rabi/cpsc617/resources/ARM Lab Mannual.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 o talvez voce tenha visto tudo funcionando bem (por acaso). Vamos corrigir em seguida.

O possivel motivo do lixo impresso foi que o ponteiro de pilha sp 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 (ou sp) e R14 sao diferentes, estao marcados/shaded, dependendo do modo, tanto que o SP no modo supervisor eh chamado de SP_supervisor e no modo undefined SP_undefined. Quando o processador passa de um modo para outro, ele passa a usar o SP 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 sp de um modo não é o mesmo registrador sp 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 16.1 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 SP_UNDEF (registrador sp no modo undefined). Inicilize SP_UNDEF com o valor 0x2000 e inicialize o SP_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 SP. Esse SP no modo undefined (SP_UNDEF) eh diferente do SP 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 sp (ou 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. Bata um pritscreen mostrando o retorno para a instrucao seguinte a 0xffffffff para ser enviado como tarefa.

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?

(2 pontos) Formato: zip. Entregue no dia da aula os codigos fontes de cada exercicio em um arquivo zipado. No cabecalho de cada codigo, escreva como o arquivo deve ser gerado. Comente o codigo para voce mesmo entender na hora da prova. Caso tenha feito algum script para geracao do codigo (recomendado), anexe o script em seu codigo. Embora o codigo seja feito em grupo, a entrega eh INDIVDUAL.

(3 pontos) Formato: pdf. Entregue ateh o final do dia aula o relatorio (pdf) cada exercicio por seu grupo, com o codigo e screenshot do tela do gdb. Embora o relatorio seja feito em grupo, a entrega eh INDIVDUAL.

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.
• Coloque um breakpoint logo no início da interrupcao de timer, o mais perto possivel do vetor de interrupcao, e rode até lá. Qual é o modo em que o processador roda? Qual é o sp? O que se vê na pilha? Relacione o PC que deveria apontar para a instrucao seguinte antes de ocorrer a interrupcao com o LR (veja que tem uma diferenca de 4 bytes).
• 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

timer_init:
 mrs r0, cpsr
 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

mais especificamente:

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

Obs: o timer pode ser configurado como "periodic" (interrompe de tempo em tempo) ou "free running" (interrompe apenas uma vez). O valor para periodic no site estah como 1, mas a equipe do Elton,Helio,Mafra-19 observaram que ocorre o contrario: o valor para periodic deve ser zero. Essa disnticao entre "free running" e "periodic" funciona ao usar o registrador TIMER0V. Quando o registrador TIMER0L recebe um valor, entao, sempre interrompe periodicamente.

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 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 a chamou (e nao como um endereco para onde o codigo eh desviado e nao retorna). 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. IMPORTANTE: tire um printscreen dos ' 's e '#' sendo impressos para entregar ao professor como atividade.
• 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).

(2 pontos) Formato: zip. Entregue no dia da aula os codigos fontes de cada exercicio em um arquivo zipado. No cabecalho de cada codigo, escreva como o arquivo deve ser gerado. Comente o codigo para voce mesmo entender na hora da prova. Caso tenha feito algum script para geracao do codigo (recomendado), anexe o script em seu codigo. Embora o codigo seja feito em grupo, a entrega eh INDIVDUAL.

(3 pontos) Formato: pdf. Entregue ateh o final do dia aula o relatorio (pdf) cada exercicio por seu grupo, com o codigo e screenshot do tela do gdb. Embora o relatorio seja feito em grupo, a entrega eh INDIVDUAL.

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