| ★ CODING ★ MICRONEWS - Z80 ASSEMBLEUR FACILE (3e partie) ★ |
| Cours et initiation du Magazine Micro News | Micro News n°08 : Z80 Assembleur Facile (3e partie) |
Je suppose que les variations sur les boucles qui ont précédés vous ont mis en appétit et qu'à présent vous aimeriez passer à l'action. Comment faire concrètement, puisqu'aussi bien tout laisse présager qu'en Assembleur il ne suffit pas de se mettre à son micro et de taper "Auto". Établissons d'abord une distinction entre "mnémoniques" assembleur et "codes machine". Les codes machines, valeurs situés entre 0 et 255, que vous connaissez certainement sous leur forme hexadécimale, représentent des instructions assembleur (pour faire technique disons mnémoniques assembleur) codifiées dans la seule forme accessible au Z80. Notre calculateur ne "comprend " que les codes machines. A partir de là deux possibilités : soit vous ancodez votre programme directement en codes machine que vous "pokerez" d'une manière ou d'une autre dans la mémoire, soit vous utiliserez les outils à votre disposition (il s'agit en fait de programmes) qui vous permettront d'écrire une "source" en langage tout de même plus évolué -les fameux mnémoniques- étant entendu qu'un programme d'assemblage réalise à l'encodage de votre "source" pour la transformer en "objet". Vous travaillez selon la première manière chaque fois que vous reprenez dans une revue des "Datas" représentant un programme en langage machine. Est-il possible d'aller plus loin ? Théoriquement oui, car il existe une correspondance point par point entre mnémoniques et codes machines. LD A,20H 3E 20 A noter que certains mnémoniques sont codifiés sur plusieurs octets. S'il ne s'agissait que de traduire des mnémoniques, on pourrait écrire qu'avec beaucoup de courage et encore plus de patience il est parfaitement possible de codifier "à la main", en se référant aux quelques ouvrages exempts d'erreurs de typographie, si l'objet rare existe. C'est exactement ce que vous ferez lorsque vous "bidouillerez", c'est-à-dire que vous corrigerez directement l'objet pour gagner du temps. Mais il y a également le problème du calcul des déplacements et des adresses. Si j'écrie : "JR NZ,SUITE" il faut calculer le nombre d'octets que comporte le saut relatif en arrière ou en avant vers "SUITE". Si j'écrire : "JP SUITE" il faut définir sans erreur l'adresse exacte à laquelle se situe "SUITE". Bref, encoder à la main réserve une telle quantité de pièges et de difficultés qu'à l'évidence cette solution n'est pratiquement pas valable. Et puis votre micro n'est pas là pour servir de garniture. Nous retiendrons de l'encodage à la main uniquement les perspectives qu'il nous offre pour bidouiller. Vous rédigerez donc votre programme en mnémoniques, constituant la "source". Vous saisirez cette source à l'aide d'un programme qui n'est ni plus ni moins qu'un petit gestionnaire de texte spécialisé. Deux cas de figure se présentent : soit votre gestionnaire de texte débouche directement sur l'assemblage, le moment venu, lorsque vous déclencherez cette opération par une commande propre à chaque programme. Soit le gestionnaire de texte se contente d'alimenter un fichier texte, relu et exploité par un programme d'assemblage travaillant de manière indépendante. La deuxième solution permet de doper le programme de saisie, puisqu'aussi bien on dégage la mémoire de tout ce qui concerne l'assemblage à proprement parler. Votre gestionnaire de texte permet donc de saisir, supprimer, insérer, copier des blocs, transférer des blocs, effectuer des recherches sur un mot, etc. Dans tous les cas la phase de saisie est suivie par le lancement de l'assemblage, opération au cours de laquelle sont générés les codes machines que vous recueillerez sur cassette ou sur disquette selon le cas. Vous aurez droit à un compte-rendu d'assemblage, sur écran ou sur imprimante. Le travail réalisé par le programme d'assemblage est complexe : encodage, mais aussi vérifications. Si j'écrie "JP SUITE" le programme d'assemblage vérifie l'existence de "SUITE" après avoir noté que JP est correctement orthographié, il calcule l'adresse physique de "SUITE" à partir d'une base que nous aurons fixé. Si "SUITE" est absent, ou présent à plusieurs reprises, le programme d'assemblage signale l'erreur. Il faut alors corriger La "source" et ré-assembler jusqu'à ce que l'assemblage passe. Un certain nombre de fautes sont considérées par l'assembleur comme mineures. Il se contente de les signaler, génère quelques zéros pour remplir l'espace et continue son travail. Il faut être juste. S'il existe tant de candidats à la future fédération du sport qui nous occupe, c'est que bien souvent nécessité fait loi. Assembler sur micro est un véritable plaisir lorsqu'on songe que quelques 4000 mnémoniques, ce qui fait déjà un petit programme trapu, passent en 5 à 7 minutes, pour peu que l'on refuse les listes écran ou imprimante. Avec une honnête machine de gestion, du type mini en service dans une PME il faut déjà raisonner en heures pour le même travail. Et les programmes de saisie des instructions sont infiniment moins poussés que à certains utilisateurs développés pour micros. Ceci explique celà. Nous voici donc en présence d'un "objet" dont nous pouvons lancer l'exécution. Nous n'avons plus de fautes de syntaxe, mais notre programme peut comporter N+1 fautes de logique, qui font qu'il fonctionne complètement de travers. Encore heureux s'il ne provoque pas un "reset" général. Si cela vous arrive, ne paniquez pas : c'est arrivé à d'autres qui se croient malins ! Pour trouver les fautes, nous allons faire appel au programme moniteur. Au fur et à mesure que nous trouverons des fautes nous las corrigerons en "bidouillant" l'objet ou, tout au moins à nos débuts, en corrigeant la source, avec nouv&l assemblage, etc. A ce niveau interviennent donc plusieurs itérations jusqu'à ce que le programme soit nettoyé de tous ses poux, c'est-à-dire entièrement "débuggé". Avant de parler plus en détail du moniteur, une question mérite réponse. Vaut-il mieux, pour commencer, réaliser de petits programmes indépendants ou des routines à intégrer dans un programme Basic ? Je penche incontestablement pour le programme indépendant. En effet, ce programme étant pour ainsi dire fermé sur lui-même, il vous est facile de le "débugger" au moniteur. La routine à intégrer au Basic a bien souvent besoin de paramètres ou de données venant du Basic. Si vous désirez travailler cette routine au moniteur, il vous faut simuler l'environnement Basic, ou modifier la routine pour faire comme si. C'est-à-dire que vous cumulez les difficultés. D'ailleurs vos premiers essais peuvent très bien se limiter à une sorte de colonne vertébrale dont partent sans arrêt des appels (call) vers les routines de la ROM. Vous minimiserez les dégâts. Qu'est-ce qu'un programme moniteur ? C'est un programme capable de contrôler votre balbutiant chef-d'œuvre. Les deux programmes, le moniteur et votre application, seront présents en mémoire côte à côte et en même temps et votre application tournera sous surveillance du moniteur. Listing en main vous pourrez faire du "pas à pas" pour voir ou passe le programme (pour bien faire il faut une pipe et l'air décontracté !). Vous pourrez à tout moment vérifier le contenu des registres ou de la mémoire, poser un point d'arrêt pour piéger le programme à un niveau précis, etc. Et pour finir, vous pourrez bidouiller à votre aise. La plupart des moniteurs sont capables de "désassembler" c'est-à-dire de retraduire en mnémoniques les codes machine, ce qui simplifie considérablement le travail. Le moniteur est donc un outil indispensable pour programmer en Assembleur. A défaut de moniteur vous serez condamné au jeu stérile de la devinette. Toutes les bonnes maisons mettent à votre disposition les outils décrits ici. Les directives d'assemblage sont des ordres que vous glisserez dans votre source, qui ne sont là que pour guider le travail d'assemblage et à ce titre ne donneront lieu à aucun code objet. Certaines de ces directives ne concernent que la mise en page du listing. Plus importante est la directive ORG (de ORGanize, organiser la mémoire). Il a été indiqué de nombreuses fois déjà qu'en Assembleur le programmeur est responsable de la mémoire de son micro. ORG participe à la gestion de la mémoire. Cette "pseudo-instruction" indique au programme d'assemblage quelle base vous avez retenue pour l'implantation en mémoire de votre application, cette base servant au calcul de toutes les adresses. ORG 9000H : je veux implanter mon programmes en 9000H et demande que toutes les adresses soient calculées a partir de cette base. Bien évidemment vous mettrez cer.e directive en tête de votre source. Notez que le point d'entrée de votre programme ne se confond pas nécessairement avec cette adresse. Vous pouvez bien démarrer quelques part en 9800H ou ailleurs. Non, il s'agit du début physique de votre programme. Pour être aussi complet que possible, signalons ici l'existence d'un troisième larron, l'éditeur de liens (linkage éditor). Mettons que vous ayez plusieurs modules, assemblés séparément à ORG 0. On aura laissé les adresses en filigrane. L'éditeur de liens vous permet de bourrer tout ce beau monde à la queue leu leu en actualisant les adresses. On se passe très bien d'un éditeur de liens, notamment en raison de la possibilité que nous avons de définir des "équivalences". Prenons le problème d'assez loin et supposons que dans une applications vous avez à charger à maintes reprises, dans l'une ou l'autre des paires de registres, les valeurs 1BF5H. 432H, FCE9H. Ce sont là des valeurs sans signification particulière, choisis pour l'illustration du propos. Vous pouvez bien entendu écrire : LD BC,1BF5H Mais gageons qu'arrivé à la page 10 de votre source, vous aurez tendance à confondre une valeur avec l'autre, sans parler des fautes de frappe. Il est donc intéressant de pouvoir établir les équivalences suivantes : VAL1 EQU 1BF5H Si vous trouvez des applications plus parlantes à votre intellect, vous avez le choix. Dans le corps du programme vous écrirez : LD BC,VAL1 Le programme d'assemblage prend en compte les substitutions à faire. Vous pouvez définir des équivalences, non seulement pour les valeurs, mais aussi pour les adresses situées hors de votre programme. CLS EQU 0195H Dans le programme, vous ferez un appel à CLS sous la forme ; CALL CLS ou à SPROG sous la forme CALL SPROG ou même JP SPROG. Dans un moment d'agacement, un philosophe célèbre a défini l'homme comme un animal paresseux. Je dirais que Z80 l'a si bien compris qu'il a inventé les équivalences EQU.
|
