PDA

Voir la version complète : [GBA][Tutorial] Initiation à l'assembleur - Partie 1


Dr.Vince
14/09/2006, 12h21
PETITE INITIATION A L'ASSEMBLEUR ARM DE LA GBA
Auteur : MIKEGBA


Bon,

Ce topic n'a pas pour prétention de donner des cours, mais seulement de faire découvrir
un language qui peut se réveler une autre alternative pour développer sur gba que le C et autres Dragon basic,
voire parfois venir en simple complémént. ;)

je ne reviendrai pas sur les avantages et inconvénients de chaque languages, cela a déja été vu dans d'autres posts !! :D

Je vais essayer d'etre le moins rébarbatifs en abordant le sujet par des exemples....
simples et concret qui trouveront une application directe pour notre petite console préférée, comme par exemple la lecture du pad, plotter un point en mode 4, afficher une image
, afficher un sprite ( éventuellement le déplacer ) en essayant de faire le tour du jeu d'instruction de ce bon vieux processeur arm7 !! :rolleyes:

Si ce topic intéresse du monde, on pourrait essayer de faire au fil des semaines un jeu simple genre space invader ou un truc du genre! :o



J'insiste aussi sur le fait que les petits exemples proposés ne seront pas forcémment "optimisés"
et n'auront que pour seul but de faciliter la compréhension !!
Dailleurs un truc sympa, serait pour les divers exemples proposés que vous postiez d'autres solutions
qui améne au meme résultat.... plus vite !! :chair:



Pour aujourds'hui, juste une petite présentation générale !

l'arm7 est donc un prosseur RISC 32 bits, ou processeur à jeu d'instruction réduit.

Ce processeur dispose de 2 jeu d'instruction, le thumb ( jeu d'instruction 16 bits ) et l'Arm, jeu d'instruction 32
bits, et c'est à ce dernier que l'on s'interressera.

En mode arm, chaque instruction est codée sur 32 bits ( quelle que soit l'instruction ).

Quand je dis que l'instruction est codée sur 32 bits, cela englobe la TOTALITE de l'instruction et de ces
opérateurs !!

par exemple l'instruction suivante:

mla r0,r1,r2,r3 qui signifie multiplier le registre r1 avec r2, puis ajouter au résultat le registre r3 et stoker le résultat final dans le registre r0
( mla = commande pour multiplie and accumulate )


Tout cela est stoké sur 32 bits !!, et non pas 32 bits pour mla, 32 bits pour r0, 32 bits pour r2, etc...

Vous pouvez déja imaginer la puissance de la bete !! en une seule et unique instruction , on réalise déja une multiplication
et une addition !!

On dispose pour travailler de 16 registres de 32 bits ( il y'en a un 17eme, mais on laisse de coté pour l'instant )

de r0 à r12: registres de travail
r13: la pile ( contientr l'adresse de notre pile )
r14: le registre qui contient l'adresse de retour pour les branchements avec lien
r15: contient l'adresse de la prchaine instruction éxécutée

Les registres sont en fait des zones de mémoires internes au cpu sur lesquels ce dernier est capable
d'effectuer toutes sorte de traitement: addition, multiplication, soustractions, opérations logiques genre AND,
or, etc...
Nous sommes donc obligé de passer par ces registres, le cpu ne sachant pas directement faire d'opération
sur les données en mémoire.

On opére donc selon le schéma suivant:

-chargement des données dans le ou les registres
-traitement des données
-stockage du résultat.

si je reprend l'exemple précédent que je complete par le chargement préalable de mes 3 registres:

ldr r4,=adresse de stockage
mov r1,2
mov r2,r1 lsl 5
mov r3,0xff

mla r0,r1,r2,r3

str r0,[r4]

notre premier programme va occuper donc 32 bits * 6 instructions= 24 octets ! => c'est la fête !! :D


voyons donc ce que cela va nous donner:

1) ldr r4,=adresse de stockage ; on charge dans r4 l'adresse ou l'on va stocker notre résultat.

2) mov r1,2 ;on charge r1 avec la valeur 2 !!

3) mov r2,r1 lsl 5 ;on charge r2 avec le contenu de r1 que l'on multiplie par 32 au préalable, décalage logique de 5 bits vers la gauche = multiplication par 32, donc r2=2 * 32 = 64 !!!

4) mov r3,0xff ;pareil que pour le cas numéro 2, mais notation en hexa, 0xff= 255

5) mla r0,r1,r2,r3 ;notre multiplication + addition= r0=(r1*r2)+r3= ( 2*64) + 255 = 383 = 0x17f

6 ) str r0,[r4] ;on stocke notre résultat r0, à l'adresse pointée par r4

Nous y reviendrons plus tard, mais on peut déja voire que notre résultat tient sur 9 bits, et que l'on a stocké
le registre complet r0 qui fait 32 bits . on occupe déja 4 octets alors que 16 bits aurait suffit !! :wacko:


On remarque également que l'on a utilisé 2 instructions différente ( ldr et mov ) pour charger les registres,

on aurait pu tout aussi bien faire ldr r1,=2 , ça aurait marché ... mais beaucoup plus lentement, on verra pourquoi
plus tard.


Ce cpu dispose également, et c'est très important pour nous , de 32 ko de mémoire vive interne, c'est la
fameuse IWRAM dans notre gameboy, celle qu'on appelle mémoire rapide, qui en plus dispose d'un bus 32 bits.

cela veut donc dire que si on a la bonne idée de placer notre code dans cette mémoire, c'est là que l'on tirera
la meilleure performace de notre machine:

en effet, lorsque que le processeur execute une instruction, il doit dabords la charger. souvenez vous, l'instruction est codée
sur 32 bits, donc, si l'instruction est en iwram par rapport à la rom, il y'a 2 avantages:

1) le temps d'acces de l'iwram est baucop plus rapide
2) le bus de l'iwram est en 32 bits alors que celui de la rom est en 16 bits, donc en rom notre instruction va voyager
jusqu'au processeur par 2 paquets de 16 bits succéssifs, alors qu'1 seul paquet de 32 bits suffira si l'instruction est en
IWRAM.

c'est comme sur une autoroute, par rapport à une nationale, à la meme vitesse , on fait passer 2 fois plus de
voiture !! :lol:

Sinon, pour résumer, à part pour l'iwram, toutes les autres zones mémoires de la gba ont un bus 16 bits. ( sauf sauvegarde
en 8 bits )

On verra aussi plus tard qu'il y'a aussi des restrictons en écritures pour certaines zones mémoires, par exemple la ram vidéo
qui ne peut pas par exemple etre adressée en 8 bits, mais au minimim en 16 ou 32
C'est important de le savoir, car ça veut dire par exemple que si l'on veut plotter des pixels en mode 4 par exemple,
on ne pourra le faire que par 2 ou 4... ce qui nous conduira a voire ce qu'est l'alignement.Ce qui peut sembler etre une
contrainte au départ ( ne pas pouvoir plotter des pixels individuellement ) se revelera en fait etre un avantage
terrible car on verra qu'il est possible en une seule instruction d'en plotter 4 ... ( voire meme 40 !!! ) :P


Voilà pour cette première présentation sommaire, n'hésitez pas à recadrer ou indiquer quelle orientation
vous voudriez voire prendre ce topic.

à bientot !
:)

omg
14/09/2006, 14h14
Wooooo Très interressant!
Dr.Vince tu nous gates ces jours ci!

Darkmath
14/09/2006, 14h48
Auteur : MIKEGBA


Merci, je suis interessé par l'idée du petit jeu simple (shoot em up) en assembleur.
Je vois que tout ceci est pour la GBA et son ARM7 y a-t-il de grandes différences avec la DS et son ARM9?

Dr.Vince
14/09/2006, 15h23
pour le petit jeu simple, en fait le lien sur l'ancien PA était un lien rapid share donc mort maintenant. Mikegba ne retrouve plus l'archive.

donc si quelqu'un l'avait sur son ordi merci de me le signaler comme ça je pourrais la mettre dans le tuto

omg
14/09/2006, 16h10
Au temps pour moi j'ai lu que le gros titre! :)

Narf!
14/09/2006, 21h59
moi j'aime des topic comme ca.
super interessant.

Darkmath
16/09/2006, 11h35
par ailleurs si vous aviez des références en bouquins sur l'assembleur, je suis interessé.

DJP
16/09/2006, 16h28
par ailleurs si vous aviez des références en bouquins sur l'assembleur, je suis interessé.

1) Livre d'architecture ("Architecture des ordinateurs") pour comprendre comment ça marche
2) Les feuilles de référence du CPU concerné