"attempt to define a local label before any non-local labels" + questions

Bonjour et bienvenue.

Non, ce n'est pas tout-à-fait la même chose. Les formats de fichiers exécutables du monde sont « a.out », « COFF » et « ELF », ce dernier étant en vigueur depuis SVR4, donc autant dire que c'est lui qui est réellement le format d'exécution officiel sous Unix aujourd'hui.

Ces trois formats d'exécutable, en revanche, contiennent par définition plusieurs sections telles que « .text », « .data », « .rodata » ou « .bss ». Elles sont nécessaires pour isoler les différentes parties d'un programme, en l'occurrence (et respectivement) le code exécutable compilé, les données spécifiées dans le code, les données réputées en lecture seule (par exemple une chaîne de caractère passée entre guillemets) et les données nécessaires à l'initialisation de certains objets comme les variables globales.

Ça veut dire que ces sections sont inhérentes au format de fichier exécutable que tu utilises et qu'elles seront donc générées à la compilation, quel que soit le contenu de ton fichier source.

En outre, dans le monde PC et Microsoft, D.O.S. avait initialement son propre format d'exécutable « MZ » utilisé dans les fichiers *.exe. Avec l'apparition de Windows, ce format a d'abord été étendu en « NE » (New Executable) puis rapidement en « PE » pour « Portable Executable », toujours en vigueur. Or, « PE » est réputé dériver de COFF. Donc, tu vas retrouver les sections décrites ci-dessus à peu près partout. Ça donne l'impression qu'ils s'agit de fondamentaux de la programmation bas niveau, mais ce n'est qu'un concours de circonstances.

Par contre, comme on l'a dit, ces sections seront générées dans le fichier exécutable, si elles sont nécessaires, par l'éditeur de liens et en fonction des informations à transmettre. Par contre, le nombre de sections n'est pas limité et tu peux éventuellement ajouter les tiennes si cela a un intérêt (c'est utile, par exemple, pour ajouter une icône à un fichier exécutable sous Windows). Il existe donc une directive en assembleur pour les déclarer mais il est très peu probable que tu en aies besoin lors de l'écriture de tes premiers programmes en assembleur.

La notation pointée utilisée par NASM pour ses étiquettes, label en anglais, elle, n'a rien à voir avec les sections d'un fichier exécutable. Elle sert à définir des « étiquettes locales ». Une étiquette placée devant une instruction sert à automatiquement assigner à son symbole l'adresse de cette instruction, de manière à pouvoir y faire un saut ou y accéder en lecture/écriture. Lorsque tu utilises une étiquette locale (débutant par un point) , celle-ci n'est valide qu'entre deux étiquettes globales ordinaires. C'est utile lorsque tu fais beaucoup de boucles successives ou que tu répètes le même bloc de code. Ça te permet d'éviter d'avoir à définir une étiquette différente pour chaque bloc, étiquette qui serait inutilement visible par le programme entier. Exemple :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 ; Efface le tableau numéro 1 clrtab1: mov di,tableau1 xor ax,ax mov cx,10 ; Dix éléments à effacer .pasfini: stosw loop pasfini ; Efface le tableau numéro 2 clrtab2: mov di,tableau2 xor ax,ax mov cx,16 ; Seize éléments à effacer .pasfini: stosw loop pasfini ; Incrémente les éléments du tableau 3 inctab3: mov di,tableau3 mov cx,13 ; Treize éléments à incrémenter .pasfini: inc es:[si] dec cx jnz pasfini
En revanche, ce qui était fréquent sous DOS, c'est la déclaration de plusieurs segments dans ton programme. Mais ça, c'est une caractéristique de l'Intel x86 en particulier (et ses compatibles, bien sûr) et en mode 16 bits uniquement, puisque c'est dans ce mode que DOS a été écrit et était exploité. Le 8086 associe tous les registres d'index avec des registres de segment CS, DS, ES, etc. qui permettaient en gros de déplacer une fenêtre exploitable de 64 Ko dans toute la mémoire disponible avec une granularité de 16 octets. « CS » signifiait « Code Segment » et était automatiquement associé à IP, le pointeur de programme, pour lire les instructions à exécuter. Et quand celles-ci faisaient des accès mémoire en passant un offset, celui-ci était implicitement associé à « DS » (Data Segment).

Dans la mesure, donc, où plusieurs segments pouvaient être définis et où, dans certains cas, c'était le programme lui-même qui devait les initialiser, alors MASM reconnaissait la directive « SEGMENT », qui permettait de définir littéralement différentes sections dans un programme, au moins sur la forme. On utilisait conjointement « ASSUME » pour indiquer au compilateurs quelles sections étaient pointées par quels registres de segments à certains endroits du programme.

Ces différents « segments » définis dans un programme correspondaient donc littéralement à des sections, et c'est comme cela qu'ils étaient traduits par l'éditeur de liens… pour autant que le format de destination les prenne en charge ! Si tu produisais un programme *.COM, le fichier ne contenait aucune méta-information.

NASM, aujourd'hui, reconnaît les directives « SECTION » et « SEGMENT », et les considère comme exactement synonymes : http://www.nasm.us/doc/nasmdoc6.html