Discussion :

[noubigh]

Salut tout le monde S'il vous plait qqun peut m'expliquer qu'apporte une Macro de plus par rapport à une procédure et qu'il est son important interêt
Meeeeeeerci

[Forthman]

Hello,

Une procedure est un petit bout de code dans le programme, vers lequel on peut faire un saut.

Une macro est un bout de code qui est copie dans le programme a chaque
fois que l'on fait appel a la macro

Donc si dans ton programme, tu veux afficher le mot "BONJOUR" , il te faut
une routine pour afficher chaque caractere, si cette routine est une procedure,
a chaque lettre du mot bonjour tu fais un jump vers cette derniere,
si a la place de la procedure tu fais une macro, le bout de code sera
ajoute au programme pour chaque lettre

a+ Francois

[noubigh]

merci mais je ne vois pas la différence entre faire un saut vers la procédure pour chaque caractère de cette chaine et le fait d'ajouter le bloc de code de la macro au programme pour chaque caractère en d'autre terme en qoi la 2ème et mieu que la 1ère merci

[ALT]

Dit autrement :
- une macro :
Tu crées une macro (=suite logique d'instructions). À chaque fois que tu fais référence à cette macro dans ton code, l'assembleur remplace cette référence par tout le code de la macro. Avantage, l'exécution est plus rapide.
- une procédure :
Tu crées une procédure. À chaque appel de la proc., l'assembleur crée un saut vers le début de cette procédure. Avantage : le code exécutable est plus compact.

Il y a sans doute d'autres différences pratiques entre ces deux façons de procéder (exemple : meilleur comportement du code dans le cas d'une fonction ?), mais l'essentiel est là.

[Neitsa]

Bonjour,

Pour confirmer ce que dit ALT, une macro peut remplacer un bout de code sans pour autant que celui-ci ne présente ni ne nécessite tous les aspects d'une procédure.

Etant donnée qu'une procédure est appelée via un CALL (sous x86) et qu'elle génère un stack frame (prologue et épilogue de fonction), il est parfois inutile d'appeler une procédure pour les quelques lignes de code qu'elle procure.

Imaginons un exemple : Sous x86, les mouvements "mémoire <=> mémoire" sont interdits.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
.data
Variable1 BYTE 5;
Variable2 BYTE ?;

.code

MOV Variable2, Variable1 ; interdit !

il est par contre possible de le faire en temporisant, c-a-d en utilisant soit un registre temporaire, soit la pile :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
push Variable1
pop Variable2

Maintenant, pour me faciliter la vie, je crée une petite macro ayant l'apparence du mnémonique d'une instruction, "m2m" pour "memory to memory". (syntaxe de macro MASM) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
m2m MACRO M1, M2
    push M2
   pop M1
ENDM 
 
.code
M2M Variable2, Variable1

D'une part cela simplifie l'écriture (moins de code à écrire) et d'autre part on regroupe sous une même entité logique deux instructions. L'assembleur se chargera de remplacer "M2M" par le push et le pop en mettant les bonnes valeurs. On voit aussi qu'il n'y avait pas besoin de faire une procédure pour si peu de code.

Par contre l'intérêt de remplacer une procédure par une Macro est inexistant...

Il ne faut pas non plus réduire les macros au remplacement unique de code. Les macros ont d'autres avantages. Elles servent à manipuler des donnés avant compilation (et pas seulement du code). Le système de macro de MASM, par exemple, est à ce titre assez performant.

On peut par exemple convertir des chaînes ASCII en Unicode, compter le nombre d'opcodes utilisés par une instruction, changer ou influer certaines parties du format de fichier, compter le nombre de paramètre d'une fonction, etc. et ce avant compilation et sans produire une seule ligne de code.

Les valeurs de retour des macros peuvent par contre être utilisées par le code du programme. Dans ce cas là on peut considérer que les macros sont une sorte de méta-langage.

[noubigh]

-qu'est ce qui empèche de remplacer tous les proc'dures par des macros aprés tous les aventages de ces dernières

[noubigh]

salut tous le monde je crois que j'ai été ridicule avec mon dernier message! aprés réfléchire longuement je me suis pérsuadé que les macros ne sont utiles que pour gagner du temps lors de la saisie du code. au début de la compilation la Macro est chargée dans un tampon par le préprocesseur, puis à chaque fois q'il rencontre une invocation il la remplace par son contenu.

comparaison après achèvement de compilation:

Si onexécute le programme :

1- qui contient des invocation d'une macro:

l'exécution est fait sur la mme procédure car dedans on ne trouve plus de macro (elle est devenue des propres instructions )

2- qui contient des appels à une procédure:

l'exécution commence par la proc principale et à chaque CALL le processeur en sort pour débarquer chez la procédure appelée (qui constitue,elle, un programme complet indépendant)

Une Macro donc est, une représentation, souvent liée au programme invoquant, plus rapide grâce à l'absence des instrs CALL et RET ,plus rapide aussi lors de la compilation car elle est stockée dans un tampon, plus pratique aussi lors de la rédaction du code "pas la peaine d'ecrire la mme chose mille fois"

CONCLUSION:

On ne peut pas remplacer une procédure par une Macro car une macro ne génère que des recherche/remplacement.

Comme il faut pas concevoir toute une procédure rien que pour regrouper un ensemble d'instructions répétitives.


si je me trompe n'hésitez pas à me corriger

[usama2]

N.B: dans des applications industrielle (embarqué) il faut jamais utliser des macros car on ne peux pas connaitre d' avance ( avant l'implémentation du code source sur la mémoire du systéme indus.) la taille exacte du fichier car ce n'est qu'a la compilation ( generation du fichier.obj puis .exe) que le compilateur remplace les macros par leurs code correspondants et on aura une taille plus grande que celle estimée