Lab. Microprocessadores

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

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 http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0497a/CIHDDCIF.html

• 1. O que há de errado nas seguintes instrucoes:
  

  a. ADD r3,r7, #1023
  b. SUB r11, r12, r3, LSL #32
  

  Sugestao:

  • vejam os codigos de maquinas e observem que certos numeros nao servem para fazer o codigo de maquina.
  • coloquem no gnuarm e vejam o erro.

• 2. Sem usar a instrucao MUL, de as seguintes instrucoes para multiplicar o registrador R4 por:
  

  a. 132
  b. 255
  c. 18
  d. 16384
  

  Dicas (apenas para pensar em como resolver os itens a,b,d,e acima):

  • como vc. faria para multiplicar um valor por 4? Dica: use o MOV com o deslocamento. r1 = 4*r0
  • como vc. faria para multiplicar um valor por 5? Dica: use ADD com deslocamento - r1 = r0+4*r0
  • como vc. faria para multiplicar um valor por 3? r1 = r0*4 - r0; veja a diferenca entre SUB e RSB
  • como vc. faria para multiplicar um numero por 15? Multiplica por 3 e depois por 5.

• 3. Escreve uma rotina que compara 2 valores de 64-bits usando somente 2 instrucoes. (dica: a segunda instrucao é condicionalmente executada, baseada no resultado da primeira comparacao).
  

• 4. Escreva uma rotina que desloque um valor de 64-bits (armazenado em 2 registradores r0 e r1) de um bit para a direita.
  

• 5. idem 4, para a esquerda.
  

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

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?

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.           

• 4.5.1
  Assignments with operands in memory Assume an array of 25 words. A compiler associates variables x and y with registers r0 and r1, respectively. Assume that the base address for the array is located in r2. Translate this C statement/assignment using the post-indexed form:

  x = array[5] + y
  

  Now try writing it using the pre-indexed form.

  Declare um programa em C bem simples que contenha uma array como variável global e que fique em um loop fazendo:

  x = array[5] + y
  

  Compile o programa com a opcao -S para gerar o codigo em assembly. Observe como o assembly gerou a área de dados e como o label array foi usado no programa com instrucoes do tipo ADR. Nao se preocupe em entender todo o codigo gerado. O objetivo eh apenas observar a "cara" do assembly no mundo GNU que é diferente do assembly usado na apostila - o codewarrior.

  Uma forma simples de se declarar dados, por exemplo, uma array, estah em http://www.coranac.com/tonc/text/asm.htm :

      mov     r2, #1
  @ Byte loads
      adr     r0, bytes
      ldrb    r3, bytes       @ r3= bytes[0];     // r3= 0x000000FF= 255
      ldrsb   r3, bytes       @ r3= (s8)bytes[0]; // r3= 0xFFFFFFFF= -1
      ldrb    r3, [r0], r2    @ r3= *r0_b++;      // r3= 255, r0++;
  @ Halfword loads
      adr     r0, hwords
      ldrh    r3, hwords+2    @ r3= words[1];     // r3= 0x0000FFFF= 65535
      ldrsh   r3, [r0, #2]    @ r3= (s16)r0_h[1]; // r3= 0xFFFFFFFF= -1
      ldrh    r3, [r0, r2, lsl #1]    @ r3= r0_h[1]? No! Illegal instruction :(
  
  @ Byte array: u8 bytes[3]= { 0xFF, 1, 2 };
  bytes:
      .byte   0xFF, 1, 2
  @ Halfword array u16 hwords[3]= { 0xF001, 0xFFFF, 0xF112 };
      .align  1    @ align to even bytes REQUIRED!!!
  hwords:
      .hword  0xF110, 0xFFFF, 0xF112
  

  Para observar os dados na memória dentro do gdb, voce pode fazer

  x/20 0x100
  

  para ver 20 words a partir de 0x100

  x/21h hwords // hwords eh o label no codigo acima
  

  para ver 21 half words a partir do label hwords.

  x/20db array // hwords eh o label no codigo acima
  

  para ver 20 bytes em formato decimal a partir do label array

  Terminando este item pule para o 4.5.2, lembrando que mais referencias estao em: http://www.coranac.com/tonc/text/asm.htm : pagina mostrando diversos codigos e dados para o gnu assembler

  http://www.microcross.com/gnu-arm7t-microcross.pdf http://bel.gsi.de/scripts/gnu-arm-assy-quick-ref.pdf

  e os manuais do GNU estão (por exemplo) em: https://sourcery.mentor.com/sgpp/lite/arm/portal/release830

• 4.5.4
  Suponha que ao inves de b) init_Pointers (int *a, esteja escrito b) init_Pointers (int *array,

• 4.5.5, 4.5.6 sao muito parecidos.
  A diferenca eh que 4.5.6 nao pede para calcular a sequencia na memoria, podendo simplesmente usar registradores para isso. Nao existe de fato muita diferenca. Alguns alunos questionaram se 4.5.6 deveria calcula f(n) para qualquer n inteiro. O primeiro problema eh que o resultado deveria caber na memória do computador e portanto n sempre terah que ser limitado: nao eh isso que vamos fazer. Assuma n limitado para resultados cabendo em byte ou word.

• 1. Traduza as seguintes instrucoes em uma unica instrucao ARM:
  
  • a. adicione resgistradores r3 e r6 somente se N = 0 (N estah "clear"). Armazene o resultado no registrador r7.
    
  • b. adicione resgistradores r3 e r6 somente se N = 1. Armazene o resultado no registrador r7.
    
  • c. Multiplique os registradores r7 e r12, colocando os resulados no registrador r3 somente se C estah setado (C = 1) e Z = 0
    
  • d. Multiplique os registradores r7 e r12, colocando os resulados no registrador r3 somente se C clear and Z set .
    
  • e. Compare os registradores r6 e r8 somente se Z estah zerado.
    
  • f. Compare os registradores r6 e r8 somente se Z set, N ≠ V
    
    1. Observe a seguinte funcao em C:

    int foo(int x, int y) {
       if (x + y) >= 0)
             return 0;
       else
             return 1;
    }
    

    Suponha que ela tenha sido compilada e traduzida no seguinte codigo:

    foo        ADDS r0,r0,r1
                 BPL PosOrZ
    done      MOV r0, #0
                 MOV pc, lr
    PosOrZ  MOV r0,#1
                 B done
    

    O compilador gerou o código corretamente? O compilador retorna 0 ou 1 em r0. Se não está bom o código, corrija. Altere o código para que ele execute a funcao em somente 4 instrucoes (dica: use execucao condicional).

5.5.4 Finite state machines: a nonresetting sequence recognizer

• 1. Consider an FSM with one input X and one output Z. The FSM asserts its output Z when it recognizes an input bit sequence of b1011. The machine keeps checking for the sequence and does not reset when it recognizes the sequence. Here is an example input string X and its output Z:
  

  X = ...0010110110...
  Z = ...0000010010...
  

  Write ARM assembly to implement the sequence recognizer. Start with the initial input X in r1. Finish with the output Z in r2 at the end of the program.

• 2. Now write the code to recognize any sequence Y up to 32 bits. Start with the recognizing sequence Y in r8 and the size of Y in r9. For example, to recognize the sequence Y = b0110110, then r8 = 0x36 and r9 = 0x7 before program execution. Everything else should be the same is in Step 1. Make sure that your program works for every case, including the case when r9 = 1 or r9 = 32.
  

  Uma idéia é fazer o item 2 e usá-lo para resolver o item 1.

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

• Find maximum value
  In this exercise, you are to find the largest integer in a series of 32-bit unsigned integers. The length of the series is determined by the value in register r5. The maximum value is stored in the memory location 0x5000 at the end of the routine. The data values begin at memory location 0x5006. Choose 11 or more integers to use. Use as much conditional execution as possible when writing the code. Demonstrate the program to your lab instructor and print out the memory space starting at 0x5000 before and after the program runs. Be sure to include enough memory space to show all of your 32-bit integer values.

  0x5006 não é múltiplo de 4 - as words devem estar alinhadas em múltiplos de 4. Sinta-se aa vontade para deixar o valor maximo em registrador em passar para a memoria.

  • Obs: A apostila foi escrita para o codewarrior e estamos usando o gnuarm e nesse ambiente é razoavelmente simples definir toda uma área de dados em uma certa posição de memória (no ldscript), mas não é simples definir que dados sejam alocados em um endereço específico - para isso podemos usar ponteiros para a posição fixa.
    Nesse laboratório, ao invés de usar 0x5000, defina uma área de dados de 100 bytes assim:

    dados .space 100
    

    e no programa podemos fazer, por exemplo:

    LDR r0,=dados+4
    

    e dessa forma não dependemos da posição fixa 0x5000 Caso queira dados jah pre-inicializados faca:

    dados .word 0x1, 0x2 ...
    

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

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

• http://www.pcs.usp.br/~jkinoshi/2014/UM_KS32C50100_REV1.PDF
  UM_{KS32C50100REV1}.PDF - Manual do KS32C50100 RISC MICROCONTROLLER que está na placa do evaluator7t

• http://www.pcs.usp.br/~jkinoshi/2014/dui0134_evaluator7t.pdf
  dui0134_evaluator7t.pdf - Manual da placa do evaluator 7t

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.

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 experincia 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).

• Estude o codigo imprime.s.
  Como o numero eh passado como parametro? Como o fp é usado para isso? Isso corresponde ao PASSO-5 da apostila, mas não é necessário fazer esse passo.

  Em uma funcao, os registradores poderiam ser salvos e recuperados chamados assim:

  BL myfunction
  myfunction
             .....
             STMFD sp!, {r4-r10, lr}; guarda os registradores
             .....
             .....
             LDMFD sp!, {r4-r10, pc}; recupera os registradores; o retorno da funcao eh feito colocando lr em pc.
  

  Para entender melhor como funciona a chamada de rotinas, veja: http://infocenter.arm.com%2Fhelp%2Ftopic%2Fcom.arm.doc.ihi0042d%2FIHI0042D_aapcs.pdf Responda: Quais sao os registradores atribuidos a: fp, ip, sp, lr?

  Para que serve o fp? Responda.

  Para que serve o ip? Resposta: Register r12 (IP) may be used by a linker as a scratch register between a routine and any subroutine it calls (for details, see §5.3.1.1, Use of IP by the linker). It can also be used within a routine to hold intermediate values between subroutine calls.

• Agora que voce conhece imprime.s e imprime.c; altere imprime.c para se colocar codigo assembly dentro do codigo C usando o inline.
  Ver PASSO-6 da apostila. Observacao: O compilador gera lables com pontos na frente (ex: .L4). Apenas o compilador deve fazer isso. O código a ser inserido inline não deve ter labels comecando por ponto (ex: L4). Isso evita que o compilador e o usuário criem e usem labels iguais.

• Observe como o imprime do item 1.2 imprime um caracter no codigo assembly (gerado ao compilar .c com -S).
  Utilizando o gdb observe como o fp, ip e sp são utilizados em:

  stmfd sp!, {fp, ip, lr, pc}
  

  e como sao desempilhados em:

  ldmfd sp, {r3, fp, sp, pc}
  

  O arm-elf-gcc estah primeiro passando os parametros por registradores e depois empilhando-os dentro da rotina, por isso os parametros sao acessado via [fp - Numero] pois foram empilhados depois da entrada da rotina que empilhou ip, sp, fp. Supondo que uma funcao tenha 5 parametros, a funcao terah que obrigatoriamente empilhar alguns antes da chamada da rotina e esses parametros vao ser acessados via [fp + Numero]. Verifique colocando 5 parametros na funcao recursiva. Observe como eles sao empilhados e acessados.

  Observe que entre o stmfd e o ldmfd, o sp é alterado; por isso lr eh repassado para o pc.

  O grupo do Lucas,Ricardo,Gabril,Jonatas enviaram uma foto de como a pilha se comporta quando nas chamadas recursiva em:

  Perguntas: Como o parametro é passado para imprime? Na resposta explique o caso da rotina ter 5 parametros (via registrador e pilha) e da rotina ter poucos parametros (via registrador).

  Como esse parametro é empilhado (isso é necessário em caso de chamadas recursivas)? Como é aberto um espaco na pilha para o parametro de imprime? Onde isso é feito no código?

  Por que se faz fp-16 para acessar o parametro?

  Como esse parametro é desempilhado? Observe que o ip eh repassado para sp e com isso, a alteracao na pilha para abrir o espaco para o parametro de "imprime" é automaticamente refeito.

  • Declare a variavel local "int lixo" na funcao imprime.
    Dentro da funcao recursiva faca, lixo++. Observe o codigo assembly gerado pelo compilador. Responda no relatorio: Como lixo foi referenciado? Como foi aberto espaco na pilha para o lixo? Retire printscreens comparando a pilha sem o uso do int lixo e com o uso de int lixo. Variaveis locais devem ser empilhadas pois caso, a funcao seja recursiva elas fazem parte da recursao.

• Altere imprime em imprime.c para que imprima 7 numeros de 1 a 7 (sem usar assembly no inline).
  Gere o codigo imprime.s. Estude como o fp (frame pointer) eh usado para marcar uma posicao na pilha empilhando parametros e variaveis locais. Apresente no relatorio como a pilha e o fp estao sendo usados. Corresponde ao PASSO-7 da apostila.

  Rode essa versao de imprime no gdb. Retire printscreen antes e depois de cada instrucao que faz alteracao na pilha, em particular:

  stmfd sp!, {fp, ip, lr, pc}
  ldmfd sp, {r3, fp, sp, pc}
  

  Pergunta: Quando imprime chama recursivamente imprime é necessário que o haja um ponteiro para o fp anterior. Como isso é feito? Quando imprime retorna para uma instancia anterior é necessário ue o fp retorne para servir de base para os parametros e variaveis locais anteriores. Explique como isso é feito.

  Ao final da aula, enviar email ao professor contendo o documento gerado com os printscreens. Para ver a pilha no gdb faca x/16 $sp

Antigamente essa toolchain estava mais livre. Agora, estao pedindo que se cadastre para fazer o download. Uma possivel forma de diblar isso é: http://fun-tech.se/stm32/CodeSourceryInstall/ O importante é ter o arquivo arm-none-eabi.bin para fazer a instalacao. Exemplo: http://www.pcs.usp.br/~jkinoshi/2014/arm-2011.03-42-arm-none-eabi.bin

Siga os passos em http://balau82.wordpress.com/2010/02/14/simplest-bare-metal-program-for-arm/ 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.

Veja http://balau82.wordpress.com/2010/02/28/hello-world-for-bare-metal-arm-using-qemu/ e observe que o código passa a executar a partir de 0x10000 e não a partir do zero. Provavelmente o Balau fez dessa forma, porque toda placa vem com um código em eprom que deve ser emulado que corresponde justamente ao código de boot. Para que isso seja possível, use test.ld (o ldscript) e statup.s em http://balau82.wordpress.com/2010/02/14/simplest-bare-metal-program-for-arm/ para fazer o código rodar a partir de 0x0 como acontece em uma placa real. Observe:

• o startup.s desse post contém o vetor de interrupcao na posicao zero.
• (CUIDADO) No arm..gdb, execute o "load" após o "target" .

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

Coloque uma instrucao invalida 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. Eh possivel que ocorra um erro e uma string totalmente errada seja impressa, ou que o qemu trave pois o ponteiro de pilha r13 no modo undefined nao foi inicializado.

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.

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.

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?

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.

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

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

• 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. 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.
• Usando a experiência passada, faça com que o handler_timer em C imprima o digito "1" a cada interrupcao.
• Altere o programa principal para que ele fique em um loop continuamente imprimindo o digito "2" de tempo em tempo (fique em um loop para gastar tempo). Assim, na tela voce deverá ver "1"s e "2"s intercalados. Tente acertar esses tempos de tal forma que se imprima pelo menos 10 "2"s para cada "1".
• 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 "2"s e "1"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 '1's e '2' sendo impressos.