Registres et processeur
GameBoj – Étape 3

Les registres des différents composants peuvent être soit invisibles, soit visibles aux autres composants.

Lorsqu'un registre est invisible aux autres composants, seul le composant propriétaire du registre peut y accéder. Cette situation est un peu similaire aux attributs privés d'une classe Java.

Lorsqu'un registre est visible aux autres composants, son contenu est accessible à travers le bus à une addresse qui lui est réservée, soit en lecture seule, soit en lecture et en écriture. Dans ce cas, on parle de registre « mappé en mémoire » (memory-mapped register).

Par exemple, sur le Game Boy, le registre A du processeur, mentionné plus haut, est invisible aux autres composants. Dès lors, seul le processeur peut lire et/ou modifier son contenu.

Par contre, le registre LCDC mentionné plus haut est mappé en mémoire, à l'adresse FF40₁₆. Dès lors, il est possible de connaître la configuration actuelle de l'écran LCD en lisant la valeur se trouvant à cette adresse, et de modifier cette configuration — p.ex. pour allumer ou éteindre l'écran — en écrivant à cette adresse.

Plusieurs registres peuvent être groupés en un banc de registres (register file). Par exemple, en plus du registre A déjà mentionné, le processeur du Game Boy possède 7 autres registres similaires (nommés F, B, C, D, E, H et L). Ces 8 registres sont regroupés en un banc.

Notez que cette notion de banc est assez vague et peut être utilisée pour désigner tout groupe de registres similaires stockés dans un même composant. Lorsqu'un composant est mis en œuvre physiquement, un banc de registres prend généralement la forme d'une petite mémoire contenant les registres côte à côte. De manière similaire, dans ce projet, nous représenterons un banc comme un tableau d'entiers de type byte contenant chacun la valeur d'un des registres du banc.

Le processeur du Game Boy possède les registres suivants, qui ne sont pas visibles aux autres composants du système :

• huit registres 8 bits nommés A, F, B, C, D, E, H et L, à usage (plus ou moins) général,
• un registre 16 bits nommé PC, contenant le compteur de programme,
• un registre 16 bits nommé SP, contenant l'adresse du sommet de la pile (voir plus bas),
• d'autres registres liés à la gestion de ce que l'on nomme les interruptions, et qui seront décrits dans une prochaine étape.

Tous ces registres sont initialisés à 0 au démarrage du processeur.

Les huit registres 8 bits sont arrangés par paires (AF, BC, DE et HL), et certaines instructions permettent de manipuler une telle paire comme un registre 16 bits. Dans un tel cas, le premier registre contient les 8 bits de poids fort de la valeur 16 bits, le second ses 8 bits de poids faible.

Il faut noter que les registres 8 bits ne sont pas tous équivalents, et deux d'entre eux en particulier ont un rôle bien spécifique :

• A, qui est parfois nommé l'accumulateur (accumulator), est le registre dans lequel le résultat de la plupart des opérations est stocké ; par exemple, comme nous le verrons à l'étape suivante, les instructions permettant de calculer un et logique bit à bit stockent leur résultat dans le registre A,
• F est le registre contenant les fanions produits par l'UAL, dans ses 4 bits de poids fort (Z est le bit 7, N le bit 6, H le bit 5 et C le bit 4), ses 4 bits de poids faible valant toujours 0.

De même, la paire HL joue un rôle spécial car plusieurs instructions utilisent son contenu comme une adresse 16 bits dont les 8 bits de poids fort sont dans H, ceux de poids faibles dans L. C'est d'ailleurs de cet usage que provient le nom des registres : H signifie high, L signifie low.

Finalement, le registre SP a pour but de toujours contenir une adresse, raison pour laquelle il fait 16 bits et non 8. Cette adresse est celle de ce que l'on nomme le sommet de la pile (stack), et le nom du registre vient de là, SP signifiant stack pointer (pointeur de pile). Le fonctionnement de la pile sera expliqué dans une étape ultérieure, pour l'instant il n'est pas nécessaire de comprendre son but exact.

Le processeur du Game Boy possède un relativement grand nombre d'instructions, qui seront décrites dans cette étape et les deux suivantes. Ces instructions peuvent être groupées en quatre catégories principales :

1. les instructions de chargement et de stockage, qui permettent de transférer des données entre le bus et les registres du processeur, ou alors entre les registres eux-mêmes,
2. les instructions arithmétiques et logiques, qui appliquent les opérations de l'UAL à des données de provenances diverses,
3. les instructions de contrôle, qui permettent de contrôler l'exécution du programme, p.ex. en effectuant un saut ou en appelant une fonction,
4. les instructions ne faisant partie d'aucune des catégories précédentes.

Dans le cadre de cette étape, seules les instructions de la première catégorie seront examinées en détail — et simulées —, les autres le seront dans des étapes ultérieures. Avant de décrire ces instructions, il convient de dire quelques mots concernant leur encodage.

Chaque instruction du processeur du Game Boy est encodée en 1, 2 ou 3 octets. De manière générale, le premier octet permet, à lui seul, de déterminer à quel genre d'instruction on a affaire — p.ex. une addition, ou alors un chargement. Les 1 ou 2 octets suivants éventuellement n'ont que pour but de contenir une valeur de 8 ou 16 bits qui sert de paramètre à l'instruction³.

Etant donné que le premier octet de l'encodage d'une instruction est celui qui détermine le genre d'opération effectuée par l'instruction, on l'appelle l'opcode (pour operation code).

La table ci-dessous illustre quatre exemples d'encodage d'instructions du processeur du Game Boy. Chaque ligne présente une instruction différentes et, pour chacune d'entre elles, la syntaxe assembleur est donnée, suivie de l'encodage et d'une description de son effet sur le processeur. Dans la colonne de gauche, notez que les constantes hexadécimales sont précédées d'un signe dollar ($), qui est l'équivalent assembleur du préfixe 0x de Java.

Comme expliqué plus haut, le premier octet de l'encodage de chaque instruction est son opcode, tandis que les éventuels autres constituent un de ses paramètres. Par exemple, à l'avant-dernière ligne, le second octet de l'encodage est 56, qui est le paramètre donné à l'instruction LD. La dernière ligne illustre quant à elle une particularité de l'encodage, à savoir que la constante (hexadécimale) 16 bits 5678 est encodée par les octets 78 et 56, dans cet ordre ! En d'autres termes, l'octet de poids faible est placé avant celui de poids fort.

Cette manière d'ordonner les octets en mémoire en allant des poids faibles aux poids forts est nommée petit-boutienne (little endian en anglais). La convention inverse, consistant à placer les octets de poids forts d'abord, est dite grand-boutienne (big endian). Des détails sur l'origine de ces termes étranges sont donnés sur la page Wikipedia qui leur est consacrée.

En comparant les lignes 2 et 3 de la table ci-dessus, on constate qu'elles contiennent deux instructions qui sont très similaires, puisque toutes les deux décrémentent le contenu d'un registre — B dans le premier cas, C dans le second. Ces deux instructions ont un opcode différent (05 et 0D respectivement), mais elles sont clairement liées étant donné que leur effet est semblable. Elles forment ce que nous nommerons une famille d'instructions, c-à-d des instructions d'opcode différent mais de comportement similaire.

Comme on peut s'y attendre, l'encodage des instructions constituant une famille est construit de manière systématique. Dans le cas de la famille d'instructions DEC, par exemple, l'encodage est le suivant (en binaire) :

00rrr101

où rrr représente les 3 bits qui déterminent le registre à décrémenter, et dont la signification est donnée par la table ci-dessous :

Ainsi, DEC B s'encode en binaire comme 00000101 (05₁₆) et DEC C s'encode en binaire comme 00001101 (0D₁₆). Plusieurs autres familles d'instructions utilisent le même encodage des registres pour spécifier l'un de leurs arguments. Par exemple, la famille permettant d'additionner au contenu du registre A le contenu d'un autre registre est encodée ainsi :

10000rrr

Il s'ensuit que l'instruction ADD A,B s'encode 10000000 en binaire (80₁₆).

Certaines familles d'instructions décrites plus bas travaillent sur les paires de registres, et chaque paire est encodée au moyen de deux bits dans l'opcode de l'instruction. L'encodage utilisé est le suivant :

Comme la dernière ligne le montre, les deux bits 11 sont soit utilisés pour désigner la paire AF, soit pour désigner le registre 16 bits SP, en fonction des instructions.

Pour donner une idée du jeu d'instructions du processeur du Game Boy, voyons comment écrire un petit programme permettant de calculer \(\cal{F}_{11}\), le douzième terme de la fameuse suite de Fibonacci. Pour mémoire, cette suite est définie ainsi :

et ses 12 premiers termes sont :

Un programme Java permettant de calculer et d'afficher le douzième terme est donné ci-dessous. Notez qu'il est écrit dans un style étrange, avec des variables portant des noms peu évocateurs. Ceci est volontaire, et a pour but de faciliter la comparaison avec le programme Game Boy plus bas. Vous ne devriez toutefois pas avoir trop de peine à le comprendre en notant que, au début de la boucle, la variable b contient \(\cal{F}_{n-2}\), tandis que a contient \(\cal{F}_{n-1}\). A la fin de cette même boucle, b contient \(\cal{F}_{n-1}\) tandis que a contient \(\cal{F}_n\).

 1: byte b = 0;             // b = F(0)
 2: byte a = 1;             // a = F(1)
 3: byte c = 10;            // nb d'itérations restantes
 4: do {
 5:   byte d = a;           // d = F(n-1)
 6:   a = (byte)(a + b);    // a = F(n-1) + F(n-2) [= F(n)]
 7:   b = d;                // b = F(n-1)
 8:   c = (byte)(c - 1);    // c = c - 1
 9: } while (c != 0);
10: 
11: System.out.println(a);  // affiche 89

Ce programme Java peut être traduit assez directement en un programme assembleur pour le Game Boy, présenté ci-dessous. Pour le déchiffrer, il faut savoir que chaque ligne (sauf la 4) contient une instruction du processeur. Ces instructions sont identifiées par leur nom (LD, ADD, DEC, JP et HALT ici) et prennent généralement un ou plusieurs paramètres. Dans cet exemple, les paramètres sont soit des registres (A, B, C et D), soit des valeurs entières (0, 1, 10), soit des conditions (NZ à la ligne 9), soit des étiquettes (loop à cette même ligne). L'étiquette loop est définie à la ligne 4, et sa valeur est celle de l'adresse de l'instruction qui suit, qui est la première instruction de la boucle.

A la droite de chacune des instructions (sauf la dernière) se trouve un commentaire décrivant son effet. Ce commentaire — uniquement destiné au lecteur humain — est précédé d'un point-virgule (;) qui est l'équivalent assembleur de la double barre oblique (//) de Java.

 1:         LD B, 0        ; B = 0
 2:         LD A, 1        ; A = 1
 3:         LD C, 10       ; C = 10
 4: loop:                  ; do {
 5:         LD D, A        ;   D = A
 6:         ADD A, B       ;   A = A + B
 7:         LD B, D        ;   B = D
 8:         DEC C          ;   C = C - 1;  Z = (C == 0)
 9:         JP NZ, loop    ; } while (C != 0)
10:         HALT

L'effet de ces instructions devrait être relativement facile à comprendre grâce au commentaire qui leur est attaché, et grâce à la correspondance très directe existant entre les lignes 1 à 9 de ce programme et celles du programme Java donné plus haut.

La manière dont l'équivalent de la boucle do…while est programmé mérite toutefois quelques explications. Le corps de cette boucle est constitué des lignes 5 à 8. La ligne 9, quant à elle, contient ce que l'on nomme un saut conditionnel (conditional jump en anglais, d'où le nom JP). Son but est d'exécuter une fois encore le corps de la boucle, en revenant à la ligne 4, si et seulement si C est différent de 0. Pour ce faire, elle teste si le fanion Z de l'UAL est faux, ce qui est exprimé par la condition NZ (not zero), et n'effectue le saut que dans ce cas. Si la condition est fausse — c-à-d si le fanion Z est vrai — le saut ne se fait pas, et l'exécution se poursuit avec l'instruction suivante, ici HALT. La raison pour laquelle il est possible de savoir si C est nul en testant le fanion Z de l'UAL est que l'instruction DEC de la ligne 8 ne se contente pas de décrémenter C : elle modifie de plus les fanions de l'UAL, dont Z, en fonction du résultat — comme indiqué dans le commentaire qui lui est attaché.

Notez que la description ci-dessus n'est pas tout à fait exacte, car la ligne 4 ne contient aucune instruction, et il n'est donc pas possible d'y sauter. La ligne 4 contient une étiquette (label), nommée ici loop, qui identifie l'adresse de l'instruction qui la suit, ici celle de la ligne 5. Dès lors, la destination du saut conditionnel de la ligne 9 est l'instruction de la ligne 5, qui est bien la première du corps de la boucle.

Comme tout programme assembleur, celui donné ci-dessus n'est pas, dans sa version textuelle, directement exécutable par le processeur du Game Boy. Pour qu'il le soit, il faut l'assembler, c-à-d le transformer en une suite d'octets représentant les différentes instructions. En faisant cela, on obtient la séquence de 14 octets suivante (donnée en hexadécimal)⁴ :

06 00 3E 01 0E 0A 57 80 42 0D C2 06 00 76

Lorsqu'on donne cette séquence d'octets au processeur d'un Game Boy pour qu'il l'exécute, il effectue le nombre attendu d'itérations de la boucle avant d'arriver à l'instruction HALT de la dernière ligne, qui stoppe son exécution. A ce moment, le registre A contient 89, comme attendu.

La table ci-dessous donne la correspondance entre les différentes instructions du programme et leur encodage sous forme d'octets, en supposant que la première instruction est placée en mémoire à l'adresse 0.

Cet exemple de programme ayant donné une idée des instructions offertes par le processeur du Game Boy, il est temps de les décrire de manière plus systématique.

Dans cette première étape consacrée au processeur, deux catégories d'instructions seront traitées : les instructions sans effet, et les instructions de chargement et de stockage. Dans les descriptions qui suivent, trois informations sont données pour chaque instruction :

1. sa syntaxe assembleur,
2. l'encodage binaire de son opcode,
3. son effet sur l'état du processeur et/ou des composants connectés au bus.

Dans la description de la syntaxe, les conventions suivantes sont utilisées :

r8

représente un registre 8 bits quelconque (A, B, C, D, E, H ou L, mais pas F),

r16

représente une paire de registres quelconque (AF, BC, DE ou HL) ; comme cela a été dit plus haut, dans certains cas qui seront systématiquement indiqués, AF est remplacé par SP,

n8

représente une valeur de 8 bits,

n16

représente une valeur de 16 bits,

[XXX]

représente la valeur à l'adresse donnée par XXX.

Dans la description de l'effet des instructions, la convention suivante est utilisée :

r ou s

représente un registre dont l'identité est encodée dans l'opcode,

n

représente la valeur 8 bits suivant l'opcode de l'instruction,

nn

représente la valeur 16 bits suivant l'opcode de l'instruction,

BUS[a]

représente une lecture ou écriture sur le bus, à l'adresse a.

Les instructions sans effet sont décrites d'abord, suivies des instructions de chargement, de stockage et de déplacement.

Comme leur nom l'indique, les instructions sans effet n'ont aucun effet sur l'état du processeur, ou presque : leur seul effet est de consommer un certain temps (1 cycle dans le cas du Game Boy) pour être exécutées.

Les instructions sans effet ne sont pas aussi inutiles qu'on peut le penser, car on peut p.ex. les utiliser pour laisser passer du temps sans rien faire. Dès lors, tous les processeurs possèdent une instruction sans effet, généralement nommée NOP ou NOOP (pour no operation).

Le processeur du Game Boy est particulier en ce qu'il ne possède pas une instruction sans effet, mais huit ! La première, nommée NOP, est la « vraie » instruction sans effet. Les autres sont rigoureusement des instructions permettant de copier le contenu d'un registre dans un autre. Toutefois, lorsqu'on les utilise pour copier le contenu d'un registre dans ce même registre, elles n'ont aucun effet.

En résumé, les instructions sans effet ont l'une des deux formes suivantes :

Les deux registres r et s de la seconde famille sont encodés selon la convention donnée plus haut.

Les instructions de chargement (load instructions en anglais) ont pour but de transférer une valeur depuis un composant connecté au bus — souvent la mémoire — vers un registre du processeur.

Toutes ces instructions sont nommées LD, pour load et leur premier argument est le registre dans lequel la donnée doit être écrite, le second est sa provenance.

La raison d'être des deux instructions marquées d'un obèle (†), qui permettent de lire des données provenant de la plage d'adresses FF00₁₆ à FFFF₁₆, est que cette plage est très fréquemment utilisée. En effet, elle contient presque tous les registres mappés en mémoire des différents composants. Notez que l'adresse FF00₁₆ est fournie par l'interface AddressMap que nous vous avons donnée, sous le nom de REGS_START, que vous pouvez utiliser dans votre code.

L'instruction marquée avec un double obèle (‡) permet de charger une valeur 16 bits dans l'une des paires de registres BC, DE ou HL, ou dans le pointeur de pile SP. Dès lors, si les deux bits rr de l'opcode valent 11, alors la valeur est chargée dans le registre SP, et pas dans la paire AF.

Les instructions de stockage (store instructions en anglais) ont pour but de transférer une valeur depuis un registre du processeur vers la mémoire — plus généralement, vers n'importe quel composant attaché au bus.

Malheureusement, toutes ces instructions sont aussi nommées LD, ce qui peut porter à confusion. Toutefois, l'ordre des arguments est cohérent, et comme précédemment, le premier représente l'endroit où la donnée est écrite, le second sa provenance.

Les instructions de copie, aussi dites de déplacement (move instructions en anglais) ont pour but de transférer une valeur d'un registre du processeur à un autre.

Malheureusement encore, ces instructions sont elles aussi nommées LD.

La classe Cpu est l'une des plus grosses du projet, et il est donc capital de bien l'organiser afin qu'elle reste compréhensible. Nous vous donnons donc quelques conseils ci-dessous sur la manière de procéder, entre autres en vous suggérant quelles entités privées — types énumérés, attributs et méthodes — créer.

Etant donné que les conseils qui suivent concernent la partie privée de la classe, vous êtes libres de les ignorer, partiellement ou totalement. Toutefois, ne le faites que si vous avez de bonnes raisons de le faire, et souvenez-vous que votre projet sera également jugé en fonction de son style. Ne le négligez donc pas !