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.
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, 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.
Je te crois sur parole, j'avais justement un doute sur le MIPS (j'ai jamais touché à cette bête-là).
—
Zeroblog —
« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » —
Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » —
GT Turbo