ARM instructions inconnues au battaillon - Page 1

Bonjour,

Afin de connaître le nombre de MIPS disponibles sur mon ARM9, j'ai créé une boucle while en C que j'ai compilé à l'aide de gcc pour en obtenir le code assembleur correspondant. Par la suite, il me sera possible de connaître le nombre de cycle et d'en déduire le nombre de MIPS.

J'ai déjà fait de l'assembleur auparavant mais certaines instructions me sont inconnues.

.L3:
ldr r3, .L5 <== Je ne sais pas exactement ce qu'il charge dans r3
ldr r3, [r3, #0] <== Récupère la valeur de cpt
add r2, r3, #1
ldr r3, .L5
str r2, [r3, #0]
.L2:
ldr r3, .L5
ldr r2, [r3, #0]
ldr r3, .L5+4
cmp r2, r3
bne .L3
ldmfd sp, {r3, fp, sp, pc}
.L6:
.align 2
.L5:
.word cpt
.word 180000000
.size main, .-main
.ident "GCC: (GNU) 4.3.4"
.section .note.GNU-stack,"",%progbits

Ce sont surtout les ldr rx, .L5 qui ne sont pas très explicite.

--
Si vous connaissez un simulateur, debugger, ... pour ARM9, aussi bien sur linux que windows, je suis preneur.

Merci par avance

un cours sur le fonctionnement de l'architecture arm te serait plus utile.

parce que ldr c'est load, tout simplement. Donc il charge le contenu de la mémoire à l'adresse .L5 dans r3.

et comme .L5 est une adresse dont le contenu est l'adresse de cpt, ben le ldr r3, [r3+0] récupère vraiment le contenu de la variable cptr, sa valeur quoi.

c'est une astuce utilisée car l'arm n'a pas d'instruction pour charger directement le contenu d'une adresse complète dans un registre. Il ne peut charger que des adresses sur 8 bits significatifs je crois. Donc l'astuce c'est de lui faire charger le contenu d'une adresse "pas loin", qui elle contient vraiment l'adresse que tu veux.

en gros, c'est impossible de faire directement ldr r3, cpt, parce que cpt peut être à une adresse que l'instruction ldr peut pas encoder. Donc il faut un intermédiaire.

le débogueur s'appelle gdb, il y a un "target sim" qui permet de simuler l'arm sur pc.

squalyl (./2) :
c'est une astuce utilisée car l'arm n'a pas d'instruction pour charger directement le contenu d'une adresse complète dans un registre. Il ne peut charger que des adresses sur 8 bits significatifs je crois. Donc l'astuce c'est de lui faire charger le contenu d'une adresse "pas loin", qui elle contient vraiment l'adresse que tu veux.

Les boules

Ok merci, c'est ce que je pensais, sans être trop sûr

Par la suite, il fait un :
ldr r3, .L5+4
Je pense qu'il récupère directement la valeur du 2e word, mais pourquoi 4? La longeur d'un word c'est bien 2 octets? Il ne devrait pas faire +2?
Pourquoi fait-il ça? et non ldr r3, [r3, #2]?

Merci d'avance

non un word fait 4 octets car c'est une architecture 32 bits. 16 bits ou 2 octets, c'est pour un short.

Folco: c'est caractéristique de ce qu'on appelle une machine RISC load/store. Les opérations favorisent les registres. Dès que tu touches la mémoire principale, il faut des opérations spéciales.

en fait c'est plus sioux que ça. en ARM les instructions font toutes 32 bits exactement et pas moyen d'utiliser 2 mots de 32 bits comme sur le 68k.

LDR se démerde pour encoder en 32 bits :
- un code de condition
- un bit pour savoir si on doit affecter les flags
- d'autres flags
- deux registres parmi 16
- une constante de 8 bits
- et un shift de cette constante

voir
http://simplemachines.it/doc/arm_inst.pdf#13
http://simplemachines.it/doc/arm_inst.pdf#33

donc 'est vraiment 8 bits significatifs mais les valeurs peuvent être en fait bien plus grandes, style 0x42<<5.

Mais là, le compilo il est emmerdé, cpt est potentiellement un relogement ou les 32 bits peuvent changer, donc paf il peut pas utiliser un simple LDR. par contre si l'offset est connu on peut optimiser.

Impec!
Merci pour les réponses!
Je n'ai plus qu'à lire les docs pour pouvoir en déduire le nombre de cycle.
Merci

Toujours dans la même optique de connaître le nombre de MIPS, j'ai analysé le nombre de CPI (Cycle Par Instruction) et je souhaiterais savoir s'il est juste, je ne prends pas en compte la gestion de la mémoire, qui, je pense, ne joue pas de rôle :

L3:
ldr r3, .L5 => 3 cycles
ldr r3, [r3, #0] => 3
add r2, r3, #1 => 1
ldr r3, .L5 => 3
str r2, [r3, #0] => 1
.L2:
ldr r3, .L5 => 3
ldr r2, [r3, #0] => 3
ldr r3, .L5+4 => 3
cmp r2, r3 => 1
bne .L3 => 3
ldmfd sp, {r3, fp, sp, pc}
.L6:
.align 2
.L5:
.word cpt
.word 180000000
.size main, .-main
.ident "GCC: (GNU) 4.3.4"
.section .note.GNU-stack,"",%progbits

Est-ce correcte?
Merci

squalyl (./5) :
en fait c'est plus sioux que ça

Normal, pour un bi-endian, il êst de fait encore plus sioux

(hem, désolé )

(moi je préfère les Wendat )

Folco (./3) :

squalyl (./2) :
c'est une astuce utilisée car l'arm n'a pas d'instruction pour charger directement le contenu d'une adresse complète dans un registre. Il ne peut charger que des adresses sur 8 bits significatifs je crois. Donc l'astuce c'est de lui faire charger le contenu d'une adresse "pas loin", qui elle contient vraiment l'adresse que tu veux.

Les boules

C'est logique, comment tu veux encoder le chargement d'une valeur 32 bits dans une instruction 32 bits sinon?

Je savais pas que l'instruction faisait 32 bits

Ne me dites pas que j'ai tout bon, je ne le croirai pas!

Folco : pourtant on avait déjà discuté de l'architecture ARM sur IRC et il me semble bien que je t'avais parlé de ça

EDIT : faut bien séparer deux choses par contre :
- le fait qu'il y ait des instructions dédiées pour accéder à la mémoire, et que toutes les autres instructions ne travaillent qu'avec des registres, c'est typique des processeurs RISC
- le fait qu'on ne puisse pas charger de valeur immédiate de la taille d'un registre (dans ce cas, l'adresse d'un truc que l'on veut lire, mais ça peut être n'importe quoi), c'est spécifique aux ARM. Les autres processeurs RISC que je connais utilisent une instruction plus longue que la normale pour éviter le problème.

Oui, j'avais oublié, mais ça me revient, le coup des entiers 32 bits toussa

et le PIC qui a fait une belle entorse au RISC avec son MOVFF

crosser: ça j'en sais rien, t'as juste à lire la spec kivabien, c'est infaillible. en plus ça doit dépendre des versions non?

squalyl, c'était plus pour vérifier que je ne me suis pas trompé, car la doc kivabien, je pense l'avoir.
La majorité des instructions est réalisée en un cycle, par contre quand on attaque la mémoire c'est plus long!
En tout cas, merci.

Zerosquare (./13) :
- le fait qu'on ne puisse pas charger de valeur immédiate de la taille d'un registre (dans ce cas, l'adresse d'un truc que l'on veut lire, mais ça peut être n'importe quoi), c'est spécifique aux ARM. Les autres processeurs RISC que je connais utilisent une instruction plus longue que la normale pour éviter le problème.

Heu non sauf erreur en MIPS non plus. Si tu veux charger $12345678 tu écris un truc du genre:

lui $t0, 0x1234
addi $t0, $t0, 0x5678

2 instructions mais toujours plus rapide ou équivalent à une indirection ou au placement d'une constante 32 bits dans un pool ^^

Je te crois sur parole, j'avais justement un doute sur le MIPS (j'ai jamais touché à cette bête-là).