Instructions de contrôle
Gameboj – Étape 5

Le processeur du Game Boy a la particularité de contenir une mémoire vive de 127 octets, nommée mémoire haute (high RAM). Etant donné que cette mémoire est interne au processeur, il peut y accéder sans devoir passer par le bus. Comme nous le verrons ultérieurement, cela peut être utile dans certaines situations.

Le processeur expose la mémoire haute sur le bus, de l'adresse FF80₁₆ à l'adresse FFFE₁₆ (incluse) — voir la carte mémoire de l'étape 1. La mémoire haute se trouve donc tout en haut de l'espace d'adressage du Game Boy, d'où son nom.

Pour mémoire, en informatique on appelle pile (stack) une collection dont les éléments sont toujours ajoutés ou supprimés de la même extrémité, que l'on nomme le sommet de la pile (top of stack).

La plupart des processeurs, dont celui du Game Boy, utilisent une pile pour sauvegarder temporairement des valeurs, et il est utile de comprendre comment cette pile fonctionne.

La totalité des instructions décrites dans les deux précédentes étapes s'exécutent en séquence. Cela signifie que dès que le processeur a terminé l'exécution d'une instruction, il continue avec celle qui la suit directement en mémoire.

Pour pouvoir écrire des programmes intéressants, il est toutefois nécessaire d'avoir à disposition des instructions dites « de contrôle », qui permettent de changer le cours de l'exécution. Ces instructions permettent p.ex. d'exécuter du code différent selon le résultat d'un test, d'effectuer des boucles, ou d'appeler des fonctions. Leur but est d'exprimer le même genre de choses que l'on exprime en Java avec des constructions comme le if ou le switch, les différents types de boucles — while, do…while, for — et les appels de méthodes.

Les instructions de contrôle du processeur du Game Boy existent généralement en deux variantes : inconditionnelle et conditionnelle.

Une instruction inconditionnelle est une instruction dont l'effet sur l'état du processeur est toujours réalisé. Toutes les instructions examinées dans les étapes précédentes sont de ce type.

Une instruction conditionnelle, par contre, a un effet qui n'est réalisé que si une condition donnée est vraie. Si cette condition est fausse, rien ne se passe, et l'instruction se comporte en gros comme une instruction NOP — à la différence près qu'elle peut prendre plus d'un cycle pour s'exécuter.

Sur le processeur du Game Boy, la condition attachée aux instructions conditionnelles est très simple et ne peut rien faire d'autre que tester l'un ou l'autre des fanions Z et C stockés dans le registre F. Au total, il y a quatre conditions différentes, qui sont encodées au moyen de 2 bits de l'opcode des instructions conditionnelles, selon la table ci-dessous :

Un exemple d'instruction conditionnelle est l'instruction de saut, JP, décrite plus bas. Cette instruction a été utilisée dans le programme donné en exemple à l'étape 3 et qui calcule le douzième terme de la suite de Fibonacci. Pour mémoire, elle y était utilisée ainsi :

JP NZ, 0006

La signification de cette instruction conditionnelle est la suivante : si la condition NZ est vraie, c-à-d si le fanion Z est faux, alors elle effectue un saut à l'adresse 6 ; sinon, c-à-d si le fanion Z est vrai, alors elle n'a aucun effet et se comporte comme une instruction NOP d'une durée de 3 cycles.

Il faut noter que les instructions conditionnelles ont la particularité importante de s'exécuter en un nombre de cycles qui dépend de si la condition qui leur est attachée est vraie ou non. Par exemple, l'instruction JP s'exécute en 3 cycles si la condition est fausse, mais en 4 cycles si elle est vraie.

Les sauts (jumps) sont les instructions de contrôle les plus simples, et leur but est de changer le cours de l'exécution du programme en modifiant le contenu du compteur de programme.

Les instructions de saut du processeur du Game Boy peuvent être conditionnelles ou non, et la destination du saut — c-à-d l'adresse à placer dans le registre PC — peut être spécifiée de deux manières différentes :

1. de manière absolue (instruction JP), c-à-d sous forme d'une valeur de 16 bits,
2. de manière relative (instruction JR, pour jump relative), c-à-d sous forme d'une valeur de 8 bits signée à ajouter à l'adresse de l'instruction suivant celle de saut.

Chaque type de saut a ses avantages et inconvénient :

• les sauts absolus ont l'avantage de pouvoir sauter à n'importe quelle adresse, mais l'inconvénient de nécessiter 3 octets pour être encodées (1 pour l'opcode, 2 pour l'adresse 16 bits),
• les sauts relatifs ont l'inconvénient de ne pouvoir sauter que à une adresse se trouvant à une distance de -128 à +127 octets de l'instruction suivant le saut, mais l'avantage de ne nécessiter que 2 octets pour être encodées (1 pour l'opcode, 1 pour la distance de saut).

Les instructions de saut sont décrites par la table ci-dessous, dans laquelle PC' représente l'adresse de l'instruction qui suit celle en cours d'exécution :

L'utilité des sauts relatifs peut être illustrée au moyen du programme d'exemple donné dans l'énoncé de l'étape 3. A l'adresse A₁₆, celui-ci contient un saut absolu à l'adresse 6, encodé de la manière illustrée par la table ci-dessous (qui est une version abrégée de celle de l'étape 3) :

Ce saut peut être remplacé par un saut relatif, encodé au moyen de 2 octets seulement. On obtient alors :

L'opcode de l'instruction de saut relatif JR vaut 20₁₆ et son argument est FA₁₆. Cet argument est une valeur 8 bits qui doit être interprétée en complément à deux, ce qui donne -6. Dès lors, l'adresse de destination du saut est C₁₆ - 6 = 6, comme attendu.

En plus des instructions de saut, le processeur du Game Boy offre des instructions permettant d'effectuer des appels de fonctions. Les fonctions sont, en gros, l'équivalent assembleur des méthodes statiques en Java.

Les instructions d'appel et de retour sont décrites dans la table ci-dessous. Les fonction push et pop utilisée dans la description de leur effet permettent respectivement de placer et de retirer une valeur 16 bits de la pile. Elles font exactement la même chose que les instructions PUSH et POP décrites à l'étape 3, si ce n'est qu'elles sont utilisées ici pour sauvegarder et restaurer le contenu du registre PC.

Notez que l'instruction RST est presque identique à l'instruction CALL, la seule différence est que l'adresse de la fonction à appeler est calculée en fonction de la valeur de 3 bits fournie en paramètre et stockée dans l'opcode.

Comme cette table l'illustre, les instructions d'appel (CALL et RST) sauvegardent l'adresse de la prochaine instruction sur la pile avant de sauter à l'adresse donnée. On appelle l'adresse sauvegardée l'adresse de retour (return address). C'est en effet l'adresse à laquelle l'exécution du programme doit continuer une fois la fonction terminée. Pour cette raison, l'instruction de retour (RET) ne fait rien d'autre que placer cette adresse dans le compteur de programme.

Il est fréquent que le programme exécuté par un processeur doive réagir rapidement à un événement externe. Par exemple, un jeu exécuté par le Game Boy doit pouvoir réagir immédiatement lorsqu'un bouton du clavier est pressé. De même, le pointeur de souris affiché sur l'écran d'un ordinateur de bureau doit se déplacer au moindre mouvement de la souris.

La question se pose donc de savoir comment le programme actuellement en cours d'exécution sur le processeur peut être rapidement informé de l'occurrence d'un tel événement externe.

La solution consiste à offrir ce que l'on appelle des interruptions (interrupts). Les composants externes au processeur ont la possibilité de lever (raise) une telle interruption, forçant ainsi le processeur à interrompre temporairement l'exécution normale du programme, et à exécuter à la place un gestionnaire d'interruption (interrupt handler). Ce gestionnaire est une espèce de fonction, dont le seul but est de traiter l'événement externe signalé par l'interruption. Lorsque ce gestionnaire se termine, l'exécution normale du programme se poursuit là où elle avait été interrompue par l'arrivée de l'interruption.

Assez naturellement, le processeur utilise la pile pour sauvegarder l'adresse de l'instruction à laquelle poursuivre l'exécution lorsqu'une interruption se produit. On peut donc voir les interruptions comme des appels de fonction — la fonction appelée étant le gestionnaire correspondant à l'interruption — qui ne sont pas provoqués explicitement par le programme au moyen d'une instruction comme CALL, mais implicitement par l'arrivée d'un événement externe.

Les interruptions d'un processeur sont similaires à celles de la vie réelle. Par exemple, lorsqu'une personne travaille à une tâche particulière et que son téléphone sonne, elle interrompt temporairement son travail pour y répondre et, une fois l'appel terminé, reprend son travail là où elle s'était interrompue.

Deux instructions permettent d'arrêter temporairement le Game Boy, dans le but d'économiser de l'énergie :

En pratique, STOP n'est presque jamais utilisée, donc nous ne prendrons même pas la peine de la simuler.

L'instruction HALT a pour effet d'arrêter le processeur du Game Boy, qui n'exécute alors plus aucune instruction. Il reste dans cet état jusqu'à ce qu'une interruption dont le bit vaut 1 dans IE soit levée, même si IME est faux.

En d'autres termes, si le processeur est à l'arrêt suite à une instruction HALT, le fait qu'il existe au moins un bit valant 1 à la fois dans IE et dans IF provoquera son réveil, quelle que soit la valeur du fanion IME. Une fois réveillé, le processeur exécutera :

• la première instruction du gestionnaire d'interruption, si IME est vrai, ou
• l'instruction qui suit le HALT, si IME est faux.

L'interface publique de la classe Cpu doit être augmentée pour offrir la possibilité à ses utilisateurs de lever des interruptions. Cela implique l'ajout d'une énumération pour décrire les interruptions, et d'une méthode pour en lever une.

L'énumération est nommée Interrupt et implémente l'interface Bit car à chaque interruption correspond un bit dans chacun des registres IE et IF. Elle est déclarée ainsi :

public enum Interrupt implements Bit {
  VBLANK, LCD_STAT, TIMER, SERIAL, JOYPAD
}

La méthode permettant de lever une interruption est quant à elle :

• void requestInterrupt(Interrupt i), qui lève l'interruption donnée, c-à-d met à 1 le bit correspondant dans le registre IF.

En plus de ces ajouts à l'interface publique de la classe Cpu, il faut modifier les méthodes read et write, qui étaient vides jusqu'à présent. En effet, elles doivent désormais donner accès à la mémoire haute et aux registres IE et IF. Pour mémoire, ces différents éléments ont des addresses qui sont données par des constantes du fichier AddressMap fourni et qui sont :

• AddressMap.REG_IE pour le registre IE,
• AddressMap.REG_IF pour le registre IF,
• AddressMap.HIGH_RAM_START et AddressMap.HIGH_RAM_END pour la mémoire haute (n'oubliez pas que la première valeur est inclusive, alors que la seconde est exclusive).

N'oubliez pas que les méthodes read et write doivent vérifier la validité de leurs arguments !

Notez que nous vous conseillons de ne pas utiliser un contrôleur mémoire (RamController) pour la mémoire haute, car cela ne fait que compliquer le code. La classe RamController n'est destinée à être utilisée que pour les mémoires connectées directement sur le bus, pas celles contenues dans d'autres composants.

Etant donné que vous avez maintenant terminé la classe modélisant le processeur, il est temps de modifier la classe GameBoy pour ajouter une instance du processeur au système.

Cela implique premièrement de modifier le constructeur de cette classe pour qu'il crée un processeur (c-à-d une instance de Cpu) et l'attache au bus.

D'autre part, il faut fournir une méthode publique permettant d'obtenir le processeur du Game Boy :

• Cpu cpu(), qui retourne le processeur du Game Boy.

De plus, étant donné que votre Game Boy simulé contient désormais un composant piloté par l'horloge (le processeur), il convient d'ajouter une méthode permettant de faire avancer la simulation, et une autre permettant de connaître le nombre de cycles déjà simulés :

• void runUntil(long cycle), qui simule le fonctionnement du GameBoy jusqu'au cycle donné moins 1, ou lève l'exception IllegalArgumentException si un nombre (strictement) supérieur de cycles a déjà été simulé,
• long cycles(), qui retourne le nombre de cycles déjà simulés.

Pour simuler le fonctionnement du Game Boy, la méthode runUntil ne fait rien d'autre qu'appeler de manière répétée la méthode cycle de tous les composants pilotés par une horloge existant dans le système. A l'heure actuelle, le seul composant de ce type est le processeur.

Au moyen de cette nouvelle version de la classe GameBoy, il devient possible d'effectuer une simulation jusqu'à un certain cycle, p.ex. 2 dans l'exemple ci-dessous :

GameBoy g = new GameBoy(null);
g.runUntil(2);
System.out.println(g.cycles());

L'appel à runUntil a pour effet d'appeler la méthode cycle du processeur du Game Boy deux fois de suite : la première fois avec l'argument 0, la seconde avec l'argument 1. Ensuite, la valeur affichée à l'écran par la dernière ligne est 2.

(Notez bien qu'à l'heure actuelle aucun programme n'est disponible à l'adresse 0, donc en pratique cet exemple de simulation ne fait rien d'intéressant. Son seul but est d'illustrer l'utilisation des méthodes runUntil et cycles. Il vous faudra encore attendre une étape avant de pouvoir simuler des programmes en utilisant uniquement la classe GameBoy.)

Comme d'habitude, nous vous fournissons un fichier de vérification de signatures contenu dans une archive Zip à importer dans votre projet.

De plus, pour vous aider à débuter vos tests, nous vous fournissons ci-dessous la déclaration d'un tableau Java contenant l'encodage du programme de calcul de Fibonacci¹ récursif présenté à la §1.6.1.

En plaçant son premier octet à l'adresse 0 et en simulant ensuite l'exécution du programme qu'il contient jusqu'à ce que le PC vaille 8 — adresse de l'instruction HALT —, vous devriez constater qu'à ce moment le registre A contient 89, comme attendu.

new byte[] {
  (byte)0x31, (byte)0xFF, (byte)0xFF, (byte)0x3E,
  (byte)0x0B, (byte)0xCD, (byte)0x0A, (byte)0x00,
  (byte)0x76, (byte)0x00, (byte)0xFE, (byte)0x02,
  (byte)0xD8, (byte)0xC5, (byte)0x3D, (byte)0x47,
  (byte)0xCD, (byte)0x0A, (byte)0x00, (byte)0x4F,
  (byte)0x78, (byte)0x3D, (byte)0xCD, (byte)0x0A,
  (byte)0x00, (byte)0x81, (byte)0xC1, (byte)0xC9,
};