En assembleur, ce qui compte le plus c'est le cerveau du programmeur. Il va sans dire, d'ailleurs, qu'une part importante de la programmation passe par cet organe. Mais la puissance de l'assembleur ainsi que les méthodes à utiliser ne sont absolument pas à négliger ...
Il est bien loin le temps où on programmait en assembleur avec des interrupteurs. C'est ainsi qu'on insérait des programmes au sein de la machine. On positionnait des commutateurs de manière à agir sur huit bits, et cela fait on pressait sur un bouton de validation. Inutile de vous dire que si la moindre erreur se glissait dans un programme, il valait mieux tout recommencer à zéro. Au regard de ces méthodes archaïques, nos assembleurs sont des usines à gaz de grande puissance. Pourtant si on regarde d'autres machines, comme l'Amiga ou le PC, on s'aperçoit que les outils dont elles disposent sont encore au dessus des capacités de nos bons vieux camarades. DEVPAC II ou Masm sont de véritables monstres au regard de Dams ou de Pyradev. Mais entre tout cela, n'y a-t-il pas de méthodes nous permettant de choisir efficacement un outil selon le travail à effectuer? A BON TRAVAILLEUR, BONS OUTILS  Ne connaissez-vous pas ce bon vieux dicton? Si on veut s'y référer de manière cohérente, on peut l'appliquer ainsi: on ne prend pas un hélicoptère pour aller acheter sa baguette au coin de la rue et de la même manière, ce n'est pas à pied qu'on va tirer sa caravane pour partir au soleil. Vous avez certainement compris la démonstration. Cela dit il n'est pas nécessaire d'utiliser le gros Pyradev pour assembler trois lignes de code ni Dams pour créer un programme de 30 Ko. Dans les deux cas, on se complique la vie pour pas grand-chose. Pyradev est très puissant mais le fait qu'il travaille en fichiers séparés, dans un faux intégrateur, alourdit son utilisation. Si on veut débugger une toute ch'tiote routine, on s'arrache les cheveux. Alors que Dams, dans ce cas, devient un outil de rêve. Pour assembler plusieurs Ko de code, en revanche, il vaut mieux passer par le Monstre plutôt que par ce dernier. On sera ainsi sûr que le code source ne se fera pas bouffer par une quelconque fausse manipulation. Ce type de problème m'est arrivé, alors que mon code source était trop haut dans la mémoire, et le fait de charger un binaire avait radicalement pulvérisé des centaines de lignes de source. SPEED LIMITED Avec Dams, il faut faire attention. A partir de la gestion d'un source de 15 Ko, on peut avoir des surprises ( je sens que je vais me faire traiter par les amoureux de ce produit ). Il faut alors descendre le moniteur au maximum dans la mémoire. Le problème, dans ce cas, est de faire bien attention à la directive « M » qui décidera à partit de quel endroit les données d'assemblage ne devront plus monter vers le haut de la mémoire. Lorsque vous travaillez avec des sources de taille conséquente sous Dams, je vous conseille fortement de le faire avec des copies de sauvegarde. Générez dans ces cas des noms de programmes avec une extension évolutive: Source,001, Source.002 ... Source.NNN Avec cette méthode, vous serez certain de retrouver au moins une partie de votre code. Ce n'est malheureusement pas une solution mais simplement un palliatif. Si votre source gonfle trop, il vous sera toujours possible de le transformer pour le jeter sous un autre assembleur dont les capacités sont plus grandes ( Pyradev, Devpac …). La manière dont Dams code ses programmes n'est pas bien sorcière. Il affecte en fait une valeur à chaque instruction, ce qui lui permet de garder une version compactée des programmes en mémoire. Si vous désirez en savoir plus, nous vous proposerons ces routines au sein de cette rubrique. ;
ORG #BF00 ; Adresse d'assemblage
JR R2 ; EntrÚe secondaireRUN
DI ; EntrÚe chargement
LD BC,#7FC1 ; Banque supÚrieure activÚe
OUT (C) ,C ; sur le premier plan mÚmoire
LD HL,#1000 ; Adresse de chargement de Dams
LD DE,#C000 ; Adresse de stockage
LD BC,#4000 ; Taille Ó envoyer
LDIR ; Transfert
LD BC,#7FC0 ; Remise en forme
OUT (C),C ; de la mÚmoire
EI ; On range tout
RET ; ciao R2 ; Point dtentrÚe utilisateur
OR A ; ParamÞtre dans DE ?
JR NZ,DEOK ; Alors l'utiliser
LD DE,#1000 ; Par dÚfaut DE = 1000
DEOK
PUSH DE ; Adresse Ó dÚpiler par RET final
LD BC,#7FC1 ; Commuter les banques
OUT (C),C ; Comme pour le chargement
LD HL,#C000 ; De #C000O
LD BC,#4000 ; Sur #4000 octets
LDIR ; Dams relogÚ en (DE)
LD BC,#7FCO ; On range
OUT (C),C ; C'est mieux
LD BC,0 ; Border 0
CALL #BC38 ; Pour la beautÚ
LD BC,0 ; Fond noir
XOR A ; C'est mieux
CALL #BC32 ; Ink 0,0
LD BC,#1A1A ; Ecriture en blanc
LD A,1 ; C'est propre
CALL #BC32 ; Ink 1,27
;
LD A,#FF ; IC nous commenþons Ó enrichir Dams
LD (#B632),A ; en redÚfinissant le pavÚ numÚrique
LD DE,TOUCHE ; DE pointe sur la table de redÚfinition
LD C,12 ; Des 12 touches touches visÚes
REDEF
LD A, (DE) ; Chargement de l'ID clavier
LD B,A ; dans B
INC DE ; avance
LD A,(DE) ; chargement du code touche
INC DE ; dans A
CALL #BB27 ; RedÚfinition
DEC C ; et on boucle
JR NZ,REDEF ; sur le clavier
RET ; Appel de Dams par CALL DE
;
TOUCHE
DEFB 48,15,49,13,50,14,51,5
DEFB 52,20,53,12,54,4,55,10
DEFB 56,11,57,3,13,6,35,7 ; Le problème de la programmation en assembleur est que les programmes générés ne fonctionnent pas systématiquement et qu'il faut souvent s'y reprendre à au moins deux fois pour obtenir un truc qui fonctionne correctement. Lorsque le code est vraiment sain, pas de problème. On retourne sous Dams et on effectue les modifications. En revanche, il arrive que de grosses erreurs d'écriture détruisent jusqu'aux routines de Dams le Grand, lui-même en personne! Dans ce cas, il faut se recogner le chargement de Dams, du source et enfin la modification du programme. Pour éviter au moins la première de ces étapes, nous allons vous offrir, au sein de ce numéro, un petit programme qui permet, aux possesseurs de 6128, de stocker l'assembleur dans les banques de mémoire parallèle. Ainsi, lorsqu'on plante le CPC sans avoir d'autres ressources que le « Control Shift Esc », il suffit d'un petit CALL pour que Dams revienne comme par magie au sein de la mémoire. Pour ceux qui possèdent un bouton Reset, il n'existe pas de cas dans lequel Dams ne reviendra pas en mémoire centrale. Ceci passe par une astuce que nous décrivons dès maintenant.PASSE-MOI LE BEURRE FAIS RISETTE A PAPA  Lorsqu'on réinitialise le CPC par la voie normale (CALL 0 ou en lançant la séquence de touches « Control Shift Esc » ), toute la mémoire est nettoyée, sauf un groupe de Gaulois récalcitrants entourés de fortifications romaines ??? Pouf-pouf... Sauf la zone de mémoire qui s'étend de &BF00 à &BFFF pour tous les CPC et les banques mémoires pour les 6128. Cela veut donc dire que nous pouvons stocker dans la zone visible, juste sous la mémoire vidéo, quelques instructions. Un simple CALL en &BFXX nous permet dans ce cas de lancer une routine qu'il faut préalablement charger une fois à chaque extinction du CPC. Cette dernière sera protégée des attaques conventionnelles du système, ce qui nous permet de jouer tranquillement. En ce qui me concerne, je me suis amusé à loger la routine d'initialisation de Dams dans cette zone. Je peux ainsi déplacer Dams dans les banques et reprogrammer le pavé numérique du clavier pour qu'il fonctionne sous l'assembleur. Quoi de plus normal que de vous offrir cette routine ... COMMENTAIRE A TERRE J'ai personnellement choisi de loger Dams en #1000, ceci pour me permettre une grande zone de travail en haut de mémoire. Malheureusement, cette pratique prend beaucoup de place au Basic, et il ne faut pas penser produire de gros programmes dans ce langage avec une telle configuration. Voici comment cela fonctionne. Le programme Basic de lancement de Dams charge l'assembleur en & 1000 et fait un CALL en &BF02. Le programme est alors transféré dans la première banque mémoire supplémentaire. A chaque problème, plantage ou reset, le fait de forcer un CALL &BF00 branche sur le programme débutant en R2. Si un paramètre a été passé, il est dans DE. Dans ce cas, nous le gardons et il représente l'adresse de relogement de Dams. Dans le cas contraire, si aucun paramètre n'est précisé, nous réimplantons l'assembleur en #1000. Ceci fait, il ne nous reste qu'à hisser nos couleurs et à redéfinir les touches bien utiles du pavé numérique. Notez que nous utilisons le symbole « # » sur la touche « . » et que la touche Enter est remise en fonction. ASTUCE POUR UN Et un pour tous ... Remarquez l'astuce qui nous permet de forcer automatiquement le lancement de Dams en rempilant une adresse. Si nous réalisons le petit programme suivant: LD A,7
LD HL,#BB5A
PUSH HL
RET cela revient à exécuter les lignes suivantes: LD A,7
JP #BB5A Suivez la pile et vous verrez que cela n'est pas magique. Il faut tout de même se méfier de telles programmations, car le type de bug engendré par ces lignes peut se révéler indétectable, même pour les yeux d'un programmeur averti. Je vous conseille donc de n'utiliser ces cabrioles que sur de très courtes routines, et si le besoin s'en fait vraiment sentir. Voilà, la prochaine fois, nous ferons des petits programmes tout de même plus intéressants que ce type d'installation. M'enfin, cela fait partie des choses qu'il faut prendre en compte de manière à bien utiliser ses outils. Aux bons travailleurs, salut.. Sined le Barbare à cas, ACPC n°47, p16-17 | ★ AMSTRAD CPC ★ A voir aussi sur CPCrulez , les sujets suivants pourront vous intéresser... |
CPCrulez[Content Management System] v8.7-desktop/c
Page créée en 237 millisecondes et consultée 1721 foisL'Amstrad CPC est une machine 8 bits à base d'un Z80 à 4MHz. Le premier de la gamme fut le CPC 464 en 1984, équipé d'un lecteur de cassettes intégré il se plaçait en concurrent du Commodore C64 beaucoup plus compliqué à utiliser et plus cher. Ce fut un réel succès et sorti cette même années le CPC 664 équipé d'un lecteur de disquettes trois pouces intégré. Sa vie fut de courte durée puisqu'en 1985 il fut remplacé par le CPC 6128 qui était plus compact, plus soigné et surtout qui avait 128Ko de RAM au lieu de 64Ko. |
|
|
