Quelqu´un pourrait il m´expliquer les différences ( du point de vue de l´incidence sur le programme généré) engendrées par la déclaration de variables non initialisées ( ?) après la directive . data? au lieu de . data ?

J´ail lu que le fait de les placer après . data? générait un exécutable plus petit : je suppose que c´est dû au fait que l´assembleur ce contente de dire : " alloue tel espace mémoire au lancement du programme", plutôt que " alloue tel espace mémoire au lancement du programme et intialise le avec ces données qui ne sont pas définies ( je suppose qu´il ne fait rien, mais que chaue emplacement est tout de même explicitement défini comme indéfini, là où après.data?, cet indéfinission est implicite)"

Quelqu´un pourrait-il me conforter dans mon interprétation ou me corriger svp ?

Tien et puis tant que j´y suis :

DUP, ca marche comment ( techniquement) ?
Comme dans :

variable BYTE 20 DUP(0)

C´est une directive pour l´assebleur qui va se charger de recopier 20 fois la valeur ´0´ avant assemblage, ou est ce que cela engendre un code avec une boucle pour l´initialisation appelée au lancement du programme ( je penche fortement pour la première hypothèse, mais bon...)

DUP je pense que c´est une macro MASM et donc que c´est l´assembleur qui remplace ça par 20 fois 0 avant de commencer ( en même temps, je connait pas mais bon).

pour . DATA et . DATA? je pense que globalement il n´y a pas de différence, ce qui dit la doc de masm qui ça fait des exe plus petit quand tu mets dans . DATA? c´est qu´il vaut mieux les mettres dans . DATA? que dans . DATA et les déclaré avec ? .

pour le DUP il ne dise pas que c´est une macro, mais bon c´est peut-être un mots clef de l´asm de MASM sans être pour autant ni un mnémonique ni une macro.

ok merci dnob

. DATA? prend moins de place, pour sur car il mets moins d´info dans l´exe.

Pour DUP j´en sais rien, c´est une " directive" MASM un peu comme INVOKE. Je crois quelle existe aussi sous nasm, mais j´en ai pas la certitude.

Je m´intéressait plus en fait à la mise en oeuvre concrète des différences .data et .data? du point de vue exécutable généré : ca pèse moins lourd, certes, mais comment s´effectuent les initialisation des variable situées dans ces 2 directives ( les différences)

d´après moi tout ce que tu mets dans . DATA? ne sers qu´a l´assembleur à définir dans le prog la mémoire dont tu as besoin et qui est alloué au démarrage du programme. De plus ça donne des adresse aux variables probablement dans le tas qui n´est pas initialisé lorsque le programme démarre ( donc, comme en C++, on peut y trouver n´importe quoi).

Dans . DATA au contraire les données sont stocké dans l´exécutable et chargé en même temps que le code au démarrage du programme.
Donc js pense que . DATA prend de la place dans le fichier source lui même.

Mais c´est qu´une conjecture.

Encore une petite question, toujours avec masm :

J´ai assemblé avec masm 6.15 un projet minimal puisque le source est :

. 386
. MODEL small
. STACK 4096

. code
main PROC

    mov ax,@data
    mov ds,ax

main ENDP
END main

Après assemblage, j´obtiens un exécutable de 519 octets qui ressemble à ca :

00000000 :4D 5A 07 00 02 00 01 00 - 20 00 01 01 FF FF 01 00
00000010 :00 10 00 00 00 00 00 00 - 1E 00 00 00 01 00 02 00
00000020 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
00000030 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
00000040 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
00000050 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
00000060 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
00000070 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
00000080 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
00000090 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
000000A0 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
000000B0 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
000000C0 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
000000D0 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
000000E0 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
000000F0 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
00000100 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
00000110 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
00000120 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
00000130 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
00000140 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
00000150 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
00000160 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
00000170 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
00000180 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
00000190 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
000001A0 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
000001B0 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
000001C0 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
000001D0 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
000001E0 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
000001F0 :00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
00000200 :66 B8 00 00 66 8E D8

Ca fait quand même beaucoup de zéros pour pas grand chose, non ? :/

essaye avec . MODEL FLAT

mais je pense que le small impose quand même une taille minimum à un exécutable.

Mais . model flat, c´est pas pour utiliser le mode protégé ?

Autre question ( j´aurais dû l´appeler : topic des question sur l´asm x86 )

Il parait que le processeur peut lire et ecrire plus rapidement sur des données situées à des addresse paires ( d´où lexistence de la directive ALIGN 1/2/4 sous MASM)

C´est vrai sur tous les processeurs ? Pour quelle raisons ?

j´ai regardé dans l´aide de MASM, il y a aussi un model TINY après SMALL mais il faut une directive spéciale pour l´assemblage. Ca doit être mieux que small sans être FLAT.

Pour ton autre question je sais pas j´ai jamais entendu dire ça.

J´ai jeté un oeil sur la msdn et j´ai trouvé ca :

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_core_even_and_align_directives.asp

" This makes instruction-fetch operations more efficient for some processors."

Donc apparement cela ne concerne qu´une certaine catégorie de processeur.
( d´autre part je tirai intialement cette info du bouquin " Asembleur x86" de Kip Irvine, que la msdn a donc confirmé...)

Je suppose qu´après il faut sr référer aux manuels de référence intel propres à chaque processeur