gfortran pour les nuls: Ce n'mcmodel=moyen de faire exactement?

Depuis bar est assez grande, le compilateur génère allocation statique au lieu d'automatique de l'allocation sur la pile. Les tableaux statiques sont créés avec la .comm assemblée directive qui crée une allocation dite de section COMMUNE. Les symboles de cette section sont réunis, même nom les symboles sont fusionnés (réduit à un symbole de la demande avec une taille égale à la taille la plus grande de demande) et puis qu'est-ce que le repos est mappé à la BSS (données non initialisée) section dans la plupart des exécutables formats. Avec exécutables ELF la .bss est situé dans le segment de données, juste avant le segment de données partie du tas (il y a un autre segment de la partie gérée par anonyme mappages de mémoire qui ne réside pas dans le segment de données).

Avec le small modèle de mémoire de l'adressage 32 bits instructions sont utilisées pour traiter les symboles sur x86_64. Cela rend le code plus compact et aussi plus rapide. Certains assemblée de sortie lors de l'utilisation de small modèle de mémoire:

movl    $bar.1535, %ebx    <---- Instruction length saving
...
movl    %eax, baz_+4(%rip) <---- Problem!!
...
.local  bar.1535
.comm   bar.1535,2575411200,32
...
.comm   baz_,12,16

Il utilise un 32 bits déplacer à l'enseignement (5 octets de long) à mettre la valeur de la bar.1535 symbole (cette valeur est égale à l'adresse de l'emplacement du symbole) dans les 32 bits de poids faible de la RBX registre (le supérieur, 32 bits obtenir à zéro). Le bar.1535 symbole lui-même est alloué à l'aide de la .comm directive. Mémoire pour le baz bloc COMMUN est alloué par la suite. Parce que bar.1535 est très grand, baz_ finit plus de 2 GiB depuis le début de l' .bss section. Ceci pose un problème dans la deuxième movl instruction depuis une non-32bit (signé) compensation de RIP doit être utilisé pour répondre à la b variable dans laquelle la valeur de EAX doit être déplacé dans. Ce n'est détectée pendant le temps de lien. L'assembleur lui-même ne connaît pas le décalage adéquate, car il ne sait pas ce que la valeur du pointeur d'instruction (RIP) serait (cela dépend de l'absolu adresse virtuelle où le code est chargé et elle est déterminée par l'éditeur de liens), il met tout simplement un décalage de 0, puis crée un déménagement demande de type R_X86_64_PC32. Il indique à l'éditeur de liens pour le patch de la valeur de 0 avec la vraie valeur de décalage. Mais il ne peut pas le faire car la valeur de décalage ne serait pas apte à l'intérieur d'un entier signé de 32 bits et donc renflouent.

Avec le medium modèle de mémoire en place des choses ressembler à ceci:

movabsq $bar.1535, %r10
...
movl    %eax, baz_+4(%rip)
...
.local  bar.1535
.largecomm      bar.1535,2575411200,32
...
.comm   baz_,12,16

D'abord un 64 bits immédiat vers des instructions (10 octets de long) est utilisé pour mettre la valeur 64 bits qui représente l'adresse de bar.1535 dans le registre R10. Mémoire pour le bar.1535 symbole est alloué à l'aide de la .largecomm la directive et donc il se termine dans la .lbss section de l'ELFE exécutable. .lbss est utilisé pour stocker des symboles qui peuvent ne pas entrer dans les 2 premières GiB (et par conséquent ne devrait pas être traitées en utilisant 32 bits instructions ou RIP-l'adressage relatif), tandis que les plus petites choses aller à .bss (baz_ est toujours allouée à l'aide de .comm et pas .largecomm). Depuis le .lbss section est placé après le .bss section de l'ELFE linker script, baz_ ne serait pas finir par être inaccessible à l'aide de 32 bits RIP liées à l'adressage.

Tous les modes d'adressage sont décrites dans le Système V ABI: AMD64 Architecture de Processeur Supplément. C'est une lourde techniques de la lecture, mais d'une lecture indispensable pour quiconque veut vraiment comprendre comment de code 64 bits fonctionne sur la plupart des x86_64 systèmes Unix.

Lorsqu'un ALLOCATABLE tableau est utilisé au lieu de cela, gfortran alloue de la mémoire du tas (probablement mis en œuvre comme un anonyme, un plan de mémoire, compte tenu de la grande taille de l'allocation):

movl    $2575411200, %edi
...
call    malloc
movq    %rax, %rdi

C'est fondamentalement RDI = malloc(2575411200). À partir de là, les éléments de bar sont accessibles par le biais positif décalages à partir de la valeur stockée dans RDI:

movl    51190040(%rdi), %eax
movl    %eax, baz_+4(%rip)

Pour les endroits qui sont plus de 2 GiB depuis le début de bar, une description plus détaillée de la méthode utilisée. E. g. pour mettre en œuvre b = bar(12,144*144*450) gfortran émet:

; Some computations that leave the offset in RAX
movl    (%rdi,%rax), %eax
movl    %eax, baz_+4(%rip)

Ce code n'est pas affecté par le modèle de mémoire car rien de ce qui est supposé sur l'adresse où l'allocation dynamique. Aussi, puisque le tableau n'est pas passé autour, pas de descripteur de fichier est en cours de construction. Si vous ajoutez une autre fonction qui prend une hypothèse en forme de tableau et passer bar, un descripteur pour bar est créé comme une variable automatique (c'est à dire sur la pile de foo). Si le tableau est fait statique avec l' SAVE attribut, le descripteur de fichier est placé dans le .bss section:

movl    $bar.1580, %edi
...
; RAX still holds the address of the allocated memory as returned by malloc
; Computations, computations
movl    -232(%rax,%rdx,4), %eax
movl    %eax, baz_+4(%rip)

Le premier mouvement prépare l'argument d'un appel de fonction (dans mon exemple le cas call boo(bar) où boo a une interface qui déclare que la prise d'un supposé forme de tableau). Il se déplace à l'adresse du descripteur de tableau de bar en EDI. C'est un 32 bits immédiate déplacer si le descripteur est prévu pour être dans les 2 premiers GiB. En effet, il est affecté dans le .bss dans les deux small et medium modèles de mémoire comme ceci:

.local  bar.1580
.comm   bar.1580,72,32

OriginalL'auteur Hristo Iliev