• Aucun résultat trouvé

MASM ou TASM

Dans le document Microprocesseurs et Microcontrôleurs (Page 83-86)

Ces deux compilateurs assembleurs sont compatibles entre eux. Chacun d'entre eux a ses avantages et ses inconvénients, ils ont le même prix et les mêmes performances. Le choix n'est donc pas évident. Toutefois si nous avons l’intention d'inclure des modules en assembleur dans des programmes écrits en langage évolué, il est préférable de prendre un assembleur de même origine que le langage évolué. Si vous travaillez déjà avec un langage de Borland (par ex: Turbo-Pascal ou Turbo C/C++), TASM sera le meilleur choix. Si par contre, vous programmez en Fortran ou en VB ou VC, il vaut mieux acheter MASM de Microsoft. MASM possède une interface très perfectionnée avec les langages évolués, ce qui facilite l'inclusion de modules en assembleur. Par ailleurs, MASM 6.0 est compatible avec OS/2. Si vous optez un jour pour ce système, vous n'avez pas besoin de vous procurer une mise à jour de l'assembleur. TASM est réputé pour sa vitesse de traduction. Quiconque possède déjà un langage Borland se sent immédiatement à son aise. Vous pouvez maintenant faire votre choix librement en toute connaissance de cause. Dans nos exemples nous nous servirons essentiellement du macro assembleur MASM de Microsoft. Il s'agit en effet de l'assembleur le plus répandu. Tous les autres sont généralement compatibles avec lui.

VIII.1 Les Directives de compilation.

Initialement, les directives étaient prévues pour simplifier la vie du programmeur, au fur et à mesure des versions successives des assembleurs, leur nombre s'est tellement accru que l'effet inverse commence à être perceptible, même en admettant que chacune d'elles a son utilité, on peut légitimement craindre d'être quelque peu submergé par la variété des possibilités offertes: La simple énumération des directives

41 Jlassi Khaled disponibles suffirait à remplir quelques dizaines de pages. Leur nombre étant maintenant de loin supérieur à celui des instructions machine, mais la pratique quotidienne ne nécessite qu'un petit noyau de directives. Dans les paragraphes suivants. Nous allons passer en revue les directives les plus 'couramment’ utilisées.

VIII.1.1 Directives de sélection du processeur.

En fonctionnement de base, les assembleurs MASM et TASM sont prévus pour traduire du code destiné aux microprocesseurs 8088 et 8086 et au coprocesseur arithmétique associé. Lorsqu'un système abrite un processeur Intel plus évolué, de la classe x86, il peut être intéressant d'adapter le code pour en exploiter les perfectionnements. II faut alors demander à l'assembleur de mettre en service les instructions spéciales étendues. En pratique on insère dans le programme source une directive qui se compose d'un point et de la désignation abrégée du microprocesseur. Plus précisément, les directives suivantes sont à la disposition du programmeur :

.8086 : Active le jeu d'instructions du 8086 et 8088 et du coprocesseur 8087. C'est le paramétrage par défaut en l'absence de toute directive explicite de sélection du processeur.

.186 : Active le jeu des instructions du 80188 et 80186, y compris celles du coprocesseur 8087.

.286 : Active le jeu d'instructions du 80286 en mode réel, y compris les instructions du coprocesseur 80287.

.386 : Active le jeu des instructions du 80386 en mode réel, y compris les instructions du coprocesseur 80387.

.8087, .287, .387 : Activent uniquement le jeu d'instructions du coprocesseur arithmétique désigné sans se préoccuper du processeur.

Les instructions en mode protégé prévues pour le 80286 et 80386 et 80486 ne deviennent accessibles que si on accole la lettre "P" à la directive de sélection du processeur concerné (.286P, .386P, .486P). Toutes ces directives peuvent être utilisées dans n'importe quel module source. Chacune d'elles annule la précédente en vigueur.

42 Jlassi Khaled

VIII.1.2 Directives de sélection du modèle mémoire.

.Model SMALL: Ensemble le segment de code et le segment de données ne doivent pas dépasser 64 Ko mais ils ne commencent pas forcément à la même adresse. Toutes les adresses du programme sont de type court (NEAR).

.Model MEDIUM: La zone réservée aux données peut aller jusqu'à 64 Ko. Le code, c'est-à-dire le programme proprement dit, peut occuper de 0 à 640 Ko. Ne convient qu'aux programmes .EXE. L'accès aux données est réalisé par des adresses courtes (NEAR) tandis que le code contient des appels longs (FAR).

.Model COMPACT : C'est un peu l'inverse du modèle MEDIUM. Le code doit tenir dans 64 Ko. Mais la zone de données peut s'étendre de 0 à 640 Ko. Ne convient qu'aux programmes .EXE. L'accès au code est effectué par des appels courts (NEAR) tandis que les adresses des données sont systématiquement de type long (FAR). .Model LARGE : Le code et les données peuvent occuper de 0 à 640 Ko. Ne convient qu'aux programmes .EXE. L'accès aux données et au code est uniquement assuré par des appels ou des adresses de type long (FAR).

.Model HUGE : Interprété de la même façon que LARGE.

.Model FLAT : Ce modèle mémoire est utilisé dans le cas d’une programmation 32 bits. C’est le modèle mémoire utilisé par Windows.

Pour les programmes en assembleur à vocation autonome, il est plus simple de choisir le modèle SMALL. Le code généré est alors rapide et efficace. Il faut dire qu'un programme écrit en assembleur dépasse rarement 64 Ko. Mais il ne suffit pas de définir le modèle mémoire souhaité, les données et le code doivent être rangés sous des directives .DATA et .CODE. Les assembleurs connaissent à ce sujet quelques variantes que nous allons évoquer brièvement. Le segment .DATA ? est prévu pour héberger des données non initialisées du type court (adresses sous forme d'offsets). En temps normal, ce segment ne sert que si le module en assembleur est destiné à être inclus dans un programme de haut niveau. Dans ce cas il sera rempli par des déclarations du type DB (?) et DUP (?). Le segment .FARDATA est prévu pour recevoir des données initialisées accessibles par des adresses de type long (segment:offset). Normalement ce segment n'est utile que si le module en assembleur doit être inclus par la suite dans un programme de haut niveau. Le segment .FARDATA ? est prévu

43 Jlassi Khaled pour stocker des données non initialisées accessibles par des adresses de type long (segment:offset). Normalement ce segment ne se justifie que si le module en assembleur doit être inclus par la suite dans un programme de haut niveau. Dans ce cas, il sera rempli par des déclarations du genre DB (?) ou DUP (?). Les segments que nous venons de passer en revue sont rarement mis en service. La plupart des programmes de haut niveau peuvent être complétés par des modules exploitant uniquement les ressources des segments .CODE et .DATA. Nous donnons par la suite quelques exemples de déclaration de variables utilisant les segment .DATA et .DATA ?

-Déclaration de variables initialisées

.DATA octet db -2 octets db 8 dup(0) chaine db "Bonjour",0 mot dw 7FFFh doubleMots dd 2 dup(0FFFFFFFFh) nombre_reel real4 1.0

Dans le document Microprocesseurs et Microcontrôleurs (Page 83-86)