Discussion :

[Invité]

Tu t'engages sur une voie difficile et tu vas vite rencontrer un mur. Pour faire un assembleur, tu vas devoir franchir plusieurs étapes :
- apprendre à écrire un programme assembleur structuré (sais-tu par exemple qu'il y a le mode console et le mode Windows ?)
- comprendre le format coff et faire en sorte que tu puisses utiliser un linker standard pour te générer l'exe,
- si tu dois générer toi-même l'entête PE, alors, bon courage !
- le mode d'adressage utilisé par Intel (et AMD) est assez complexe et nécessite d'effectuer des combinaisons de bits (un tuto traite cette question sur ce site).
Kannagi dit que tu peux écrire ton assembleur en C/C++. C'est vrai. En fait, tu peux utiliser n'importe quel langage pouvant travailler au niveau du bit. Mais, si tu souhaites acquérir de solides connaissances en assembleur, il vaut mieux que tu utilises intégralement l'assembleur.
J'ai moi-même "écrit" un assembleur 16 bits il y a une vingtaine d'années. Beaucoup de travail et résultats à la limite du risible. Mais ça m'a servi à progresser en assembleur. C'est déjà ça mais mon rêve de révolutionner l'informatique s'est abîmé dans les flots. De profundis...
Et le 16 bits est une promenade de santé, comparé au 32 bits.

[chrtophe]

Si tu veux créer ton propre .exe, depuis un fichier source en assembleur, il va te falloir potasser la doc Intel sur l'encodage des opcodes. Tu devra aussi maitriser le format PE, la rellocation, l'appel de fonctions externes, etc.

T'es pas sorti de l'auberge, surtout que les CPU Intel encodent les instructions sur un nombre variable de bits.

[Kannagi]

Ce que tu dis est faux, grâce au mot clef

A quel sujet ?

[matrob72]

Apres il y'a a vraiment rien de bien sorcier ,c'est une analyse de texte + génération d'opcode.

La dessus, kannagi, rien de bien sorcier... regarde les messages au dessus.

[matrob72]

- apprendre à écrire un programme assembleur structuré (sais-tu par exemple qu'il y a le mode console et le mode Windows ?)

Oui je le sais, je sais même qu’il y a un octet qui défini quel application c’est (linker, mode console, mode Windows). Peut d’autre option ?

- comprendre le format coff et faire en sorte que tu puisses utiliser un linker standard pour te générer l'exe,
- si tu dois générer toi-même l'entête PE, alors, bon courage !
- le mode d'adressage utilisé par Intel (et AMD) est assez complexe et nécessite d'effectuer des combinaisons de bits (un tuto traite cette question sur ce site).

Effectivement, je veux créer moi même l’entête.

Kannagi dit que tu peux écrire ton assembleur en C/C++. C'est vrai. En fait, tu peux utiliser n'importe quel langage pouvant travailler au niveau du bit. Mais, si tu souhaites acquérir de solides connaissances en assembleur, il vaut mieux que tu utilises intégralement l'assembleur.
J'ai moi-même "écrit" un assembleur 16 bits il y a une vingtaine d'années. Beaucoup de travail et résultats à la limite du risible. Mais ça m'a servi à progresser en assembleur. C'est déjà ça mais mon rêve de révolutionner l'informatique s'est abîmé dans les flots. De profundis...

Et oui je me suis donné cet objectif justement pour avoir de solides connaissances en assembleur.
Tu aurais gardé quelque trace de l’assembleur que tu as fait ?

Et le 16 bits est une promenade de santé, comparé au 32 bits.

Si il y a autant de différence entre le 16 et le 32 bit, alors je préfère même pas y penser sur le 64bit. 🤯

Je savais bien qu’il y aurait du boulot mais je ne pensais pas qu’il y aurait autant de chose à prendre en compte...
Bon ben je vais continuer et voir jusqu’ou Sa vas me mener. 😊

Sinon merci, je ne savais pas que l’entête s’appelait entête ´PE’. Avec les bon mots, la recherche est plus simple. 😘

[Kannagi]

La dessus, kannagi, rien de bien sorcier... regarde les messages au dessus.

J'ai pas tort , je peux te passer des codes sources de compilateur ASM très basique

Mais il faut savoir lire en entier aussi j'ai rajouté aussi `Mais ça peut devenir plus complexe (si on veut faire un assembleur assez complet) vu que ça reste vouloir créer un compilateur. "
L'assembleur n'est pas un langage normalisé , donc tu peux tres bien faire un asm sans macro/define etc etc, ça restera un assembleur , quand tu veux par contre peaufiner un assembleur (macro /define/label temporaire / du preprocesseur plus conséquent) ça reste plus complexe.

Si tu parle du format PE c'est complexe , mais cela n'a pas forcément à voir avec l'assembleur ni un programme assembleur , ce que je dis est valide , tu peux faire un asm x86 qui fournit que du binaire.

[Invité]

...
Tu aurais gardé quelque trace de l’assembleur que tu as fait ?

Si il y a autant de différence entre le 16 et le 32 bit, alors je préfère même pas y penser sur le 64bit. 🤯

Je n’ai rien conservé de toutes mes activités à l’époque du 16 bits. De plus, j’ai cessé toute forme de développement informatique pendant une quinzaine d’années. Du reste, la segmentation de la mémoire et l’appel à des interruptions du DOS ou du BIOS imposaient un tout autre style d’écriture difficilement transposable. C’est sans doute Windows, d’ailleurs, qui a bousculé le plus l’écriture des programmes plus, probablement, que le passage de 16 à 32 bits.

Le 64 bits, c’est également un autre monde dans lequel il faut éviter de s’aventurer sans expérience confirmée du 32 bits. Le problème est toujours le même : il faut trouver le BON outil et là, autant te dire que les bons conseils sont rarissimes.

[matrob72]

J'ai pas tort , je peux te passer des codes sources de compilateur ASM très basique

Je suis toute ouï pour ces codes sources. Je pourrais m’en inspirer. 🧐

Je n’ai rien conservé de toutes mes activités à l’époque du 16 bits.
Le 64 bits, c’est également un autre monde dans lequel il faut éviter de s’aventurer sans expérience confirmée du 32 bits. Le problème est toujours le même : il faut trouver le BON outil et là, autant te dire que les bons conseils sont rarissimes.

Dommage. Tu aurais des exemples des différences entre le 16,32 et 64 bit ?
A part les instructions plus long il y a d’autre différence ?

[chrtophe]

Dommage. Tu aurais des exemples des différences entre le 16,32 et 64 bit ?
A part les instructions plus long il y a d’autre différence ?

Les différences sont essentiellement depuis les processeurs 64 bits :

Espace d’adressage étendu par le passage en 64 bits
nombre de registres doublés (ajouts des registres r8 à r15).
extensions des registres MMX (mais là je sais pas)
Plus de possibilité de lancer des applications 16 bits (abandon de TSS en 64 bits)
Plus de v86 mode
Plus de segmentation, les protections se font via la pagination.
Je crois qu'il y a un niveau supplémentaire dans les tables de pages.

Un CPU 64 bits démarre toujours en mode réel, si il est mis en 32 bits, il aura accès au fonctionnement antérieur (compatibility mode).

[Invité]

Pour completer, il y a bien 8 registres MMX
+ 16 registres XMM de 128 bits chacun
+ 16 registres YMM DE 256 bits chacun.
C’est assez phénoménal quand on y pense.

En 64 bits, je me contente, pour l’instant, de tester les programmes des autres (ceux du MASM 64 SDK)

[Kannagi]

Il y'a aussi l'extension AVX qui à des registres ZMM 512 bits
Mais bon je crois que ça mérite un topic entier les instructions SIMD

Après le nombre phénoménal ,oui mais si on compare avec la PS2 (qui date de 2000 ) avait 32 registres de 128 bits ! :p
Et la PS3 (2005) faisait 128 registre de 128 bits , bref je précise juste pour dire que les proc d'architecture x86 sont en faite en général assez en retard

[matrob72]

Mais qui dit un regitre de 128, 512 bits, dit plus de tour d’horloge sur des processeurs 32, 64bit, donc il se dise de développer peut être les bus en premier.
Sinon, auriez vous les codes de définition du processeur dont on développe le logiciel ?
(Je n’ai vue que des exemples sur : .386, .486, .586)

[matrob72]

Je voudrais également être éclairé sur le fichier PE en mode 64bit. Dans la déclaration de table, comment on fait quand le fichier fait plus de 4Go ? En mode PE+, le codage de la taille des sections et leurs offset peuvent dépasser les 4 octets donc comment on fait ?

[Invité]

...
Sinon, auriez vous les codes de définition du processeur dont on développe le logiciel ?
(Je n’ai vue que des exemples sur : .386, .486, .586)

Tu trouveras l'essentiel de l'info que tu souhaites dans l'ouvrage :

Intel® 64 and IA-32 Architectures
Software Developer’s Manual
Volume 2A:
Instruction Set Reference, A-L

Accessible en PDF (et gratuitement à l'adresse : https://software.intel.com/en-us/dow...-reference-a-l
Il faut que tu lises l'intégralité du chapitre 2 INSTRUCTION FORMAT
Le volume 2 est disponible en plusieurs tomes mais également en un seul fichier.

Regarde également tous les volumes de cette série. Lis notamment le volume 1 : Basic Architecture

Concernant les entêtes PE et PE+, il faut que tu passes par Google. Ne t'attends pas à des miracles car de nombreuses parties sont assez hermétiques.

[Invité]

Va également dans la page Tutoriels Assembleur de ce site.
Neitsa y propose un ouvrage complet en 2 parties intitulé : Décodage du jeu d'instructions x86 / x86-64 (x64)

[Kannagi]

Mais qui dit un regitre de 128, 512 bits, dit plus de tour d’horloge sur des processeurs 32, 64bit, donc il se dise de développer peut être les bus en premier.

Pas forcément , parce que ça peut être des "coprocesseurs" en interne qui le gère et donc assez indépendant du reste de l'architecture.

En général je remarque souvent l'inverse , les instructions SIMD sont en général bien plus rapide que le reste des instructions.

Je voudrais également être éclairé sur le fichier PE en mode 64bit. Dans la déclaration de table, comment on fait quand le fichier fait plus de 4Go ? En mode PE+, le codage de la taille des sections et leurs offset peuvent dépasser les 4 octets donc comment on fait ?

Après je pense pas que ça soit un cas très courant d'avoir un exécutable qui dépasse 4 Go
Il faut savoir que les exécutables sont chargé en RAM donc 4 Go pris pour un exécutable ça reste assez énorme (mon ordi à 8 Go , il souffrirait d'avoir la moitié pris ).

[matrob72]

C’est vrais que c’est pas courant mais certain logiciel comme des simulateurs peuvent les dépasser de loin.
Sinon, pour ce à qui ça intéresse, il y a un bon site qui explique le codage de l’opcode :
c-jump.com/CIS77/CPU/x86

[Kannagi]

C’est vrais que c’est pas courant mais certain logiciel comme des simulateurs peuvent les dépasser de loin.

Le dépasser de loin genre 8 Go ?

Il y'a aucune raison qu'un exécutable fasse autant , surtout pour un simulateur 3D ou 80% partira dans la VRAM , du coup ça reste des données stocké en RAM pour rien...