Bonjour, je sais en gros comment fonctionne les compilateurs, on fait une analyste syntaxique, grammaticale, etc pour transformer cela en assembleur, puis en code objet, puis en executable. En bref ce n'est que de la conversion de format de fichier en y ajoutant le nécessaire avec l'éditeur de liens.  
 
La ou je me pose des questions c'est pour les compilateurs assembleur, si je voudrais en écrire un, quelle est le format du code objet, est-ce qu'il y a un standard précis à respecter ? Ensuite comment savoir en quoi traduire les instructions asm en son équivalent binaire ?? Est-ce qu'il y a une liste quelque part ?  
 
Suite à cela, après avoir analysé le code source, transformé cela en une suite binaire, comment savoir quelle instruction doit aller ou dans le fichier objet ? (à moins qu'il y ait un format précis) Est-ce qu'on enregistre la conversion de façon séquentielle pour faire un gros fichier .o qui contient l'équivalent binaire du code source dans le même ordre que ça à été écrit ? Parce que ça revient au même, à moins bien sûr que par exemple l'instruction MOV sont équivalent binaire ne soit pas (4D4F56) soit 10011010100111101010110 mais autre chose. Dans mon exemple MOV == à '10011010100111101010110' selon le code ascii, est-ce que le cpu respecte la norme ascii ?  
 
merci de m'éclaire sur ces points  

recherche sur opcode, formats de fichiers PE ou ELF, ce sera un bon début

Ok merci

J'ai cherché sur Google, mais je n'ai rien trouvé de précis    
 
Tout ce que je trouves sur Google c'est des sites qui parlent des instructions: MOV, DIV, etc. mais sans parler de leur équivalent binaire ni de la façon de les écrire dans le fichier objet.

 
y'a un format la aussi, tu penses (et non le cpu lit pas de l'ascii
 
globalement, et pour simplifier, ca a la tronche :
 
[opcode d'instruction] [MODRM] [SIB] [DEPLACEMENT] [CONSTANTE]
 
le premier opcode indique l'instruction qu'on veut utiliser
l'octet modrm explicite les operandes. De mémoire, il est composé en 3 parties
 11 222 333  
 
la partie 1 indique la taille des operandes (8,16,32 bits)
la partie 2 indique l'operande de destination OU est parfois un modifieur de l'instruction (oué c'est le bordel)
la partie 3 indique la source
 
SIB : Scale Increment byte pour coder des trucs genre mov [eax + ebx * 4 +127]
 
DEPLACEMENT : le +127 de mon exemple d'au dessus
CONSTANT : bin une constante, genre dans mov [eax+2],5986
 
bref y'a pas de solution, faut se palucher l'encodage a la main a partir de la doc intel...
 
 
 
 
 
 
 
 
 
 
 

Ok Mais si je comprends bien, cette traduction du code on la place séquentiellement dans un fichier objet, enfin un fichier .o, un fichier txt ou peu importe et c'est la qu'intervient l'éditeur de liens ? Pour convertir ce fichier objet en un format d'un OS, PE, ELF, etc ?
 
Le fichier objet a un format précis ou si on écrit toute la traduction du code de façon séquentielle ?

bin ensuite au niveau des format d'executable, j'en ai aucune idée. Moi j'avais fait un truc a moi parce que je le pouvais, je suis pas allé plus loin. Je peux t'aider sur l'encodage d'opcode mais ca sera tout

Ok
 
À part la doc de intel qui est volumineuse, je voudrais pas me perdre dans ces documents Est-ce qu'il y a un simple fichier txt quelque part sur le net qui a une liste des opcodes avec leur équivalent binaire incluant SIB DEPLACEMENT, etc ?
 
J'aimerais faire un compilateur asm, je crois que c'est une bonne base à avoir, ça aide à comprendre bien des choses je crois Et j'aimerais bien faire ce compilateur en asm
 

le fichier objet a un format précis (notamment, tu as la définition des symboles dans l'objet avec une information pour savoir s'ils sont dans l'objet ou externes afin que l'éditeur de lien puisse s'y retrouver)
 
Et oui, c'est l'éditeur de lien qui sort le fichier au format PE (pour windows) ou ELF (pour linux, BSD ou autre)
 
Edit : je ne suis pas trop sur de moi dans ce domaine, donc je laisse d'autres personnes me corriger si je me trompe ... En tout cas, il me semble bien que le format des objets dépend du compilateur, même si tu peux faire des suppositions sur ce que tu devras trouver dedans

 
ouais, j'en avais de la bonne, mais C'etait sur un site nommé "webster"
 
ah bin j'avais fait un topic ici meme, fait une recherche sur mon pseudo en auteur (avec juste "titre de message" de choisi) et regarde dans les vieux topics (genre 2-3ans)

Hmm, je n'ai rien trouvé    
 
Il est écrit webster dans le titre du sujet ? Tu l'avais posté dans la section programmation ASM ?

http://forum.hardware.fr/hardwaref [...] 6264-1.htm

Merci  

Autre petite question
 
Je vais tenter de créer un petit OS, j'aime la programmation système et bas niveau et si je comprends bien c'est le créateur du OS qui décide de son format d'exécutable, pour Windows c'est PE par exemple. Mais le loader fonctionne comment lui exactement ? Car c'est le loader qui prend les instruction dans l'exe et place cela en mémoire puis envoie un Jmp au cpu pour qu'il exécute les instructions du exe n'est-ce pas ?
 
Comme le cpu ne comprend que ses instructions, il faut que le loader décortique l'exe et c'est aussi lui qui load par exemple une dll et la décortique à son tour, etc. ?

jcrois tu vas trop vite en besogne. Au besoin, fait toi deja ton format d'execute et ensuite code (en C ou autre) le loader qui chargera et executera le code. T'aurais le temps pour penser au reste plus tard)

Ok Mais c'est justement ce que je me demande, comment fonctionne un loader et un format d'exe, est-ce qu'un format d'exe doit contenir des trucs de base qui sont commun à tout les exe ? Mis à part de contenir les instructions Ensuite je supposes que le loader doit aller cibler le point d'entrée de l'exe, d'ou la nécessité des main() et winmain() dans les programmes Mais est-ce que le passage de la main au cpu se fait uniquement par un Jump ou si c'est plus complexe que ça ?
 
Je me suis toujours demandé pourquoi Microsoft avait décidé de changer le nom main() pour Winmain() à part l'esthétique.  

le prototype de winmain est different de main

Ah ? Différent en quoi ? il me semble qu'un point d'entrée c'est un point d'entrée

l'exe peut contenir pas mal de choses, des indications sur l'adresse à laquelle sera chargée le programme (pour le PE, et évidemment, l'adresse est exprimée dans l'espace d'adressage du processus qui sera créé) et des adresses pour les symboles à des fins de debug, par exemple. J'ai encore un souvenir assez amer des stabs du format ELF que j'ai pu découvrir il y a quelques mois ... heureusement que j'ai pas trop eu à bosser là-dessus ...
 
Normalement, tu dois pouvoir trouver une description de ces formats assez facilement sur google

 
 
le point d'entrée dans ton programme est rarement main ou même winmain.
 
Le vrai point d'entrée se chargera de faire des opérations préalables (notamment le préchargement de certaines DLL) avant de lancer ton main ou ton winmain, selon les cas

 
ouais, sauf que ton point d'entrée il accepte peut etre des parametres

Ah oui
 
Mais un main() aussi accepte des paramètres non ?
 
Je suis en train de lire le format PE, c'est très intéressant, ça dit entre autre que le fichier est complètement loadé en mémoire, mais que les sections ne sont pas nécessairement alignées les unes après les autres.
 
Je sens que je vais m'amuser
 
Mais dans l'en-tête il y a des signatures pour identifier par exemple sur quelle machine et OS le exe doit tourner. Ces différentes signatures, est-ce qu'il y en a une liste complète quelque part ? Est-ce qu'il y a une norme ISO derière ça ou si c'est Microsoft qui à décidé que ce serait ça ?

je sais que dans l'ELF, on peut savoir si l'exécutable est prévu pour tourner sur un hôte big endian ou little endian, donc j'imagine qu'on doit aussi pouvoir savoir si on doit s'attendre à un proc 64 bits ou non ou ce genre de subtilité ... Cependant, ce n'est pas limitatif à _1_ os ... on peut faire tourner des programmes linux sous BSD, par exemple (si, en activant l'émulation linux dans le kernel {edit : sous NetBSD, en tout cas } )
 
Edit : un acronyme te servira aussi peut-être bientôt : ABI

ABI ?
 
Qu'est-ce que c'est ?  

Helene et les garcons, le miel et les abeilles, tout ca

Application Binary Interface
ce sont les conventions d'appel de fonction

Ok Mais concrètement c'est quoi une "convention" d'appel ?  

jcrois tu veux griller les etapes la, c'est la base d'un appel de fonction ca

Non c'est juste que j'aime bien regarder un peu de tout en général, ça m'aide à faire les liens entre tout les éléments La base d'un appel de fonction ?
 
Des fonctions qu'on créé soi-même ou existance, sous C par exemple ??
 
Il y a une façon de les appeler ? je croyais qu'il suffisant de donner l'adresse de la fonction, prendre les paramètre dans la pile, exécuter les instructions, mettre le retour dans la pile, jump sur la fonction de retour, prendre la valeur dans la pile s'il y a lieu, etc.

 
oué, en gros, enfin, faut savori que IP est pushé sur lors d'un call et le pop+jmp est fait par ret
 
la question c'est  
1/ ou tu passes les parametres d'une fonction
2/ dans quel ordre
3/ que fais tu des registres ALU et de la pile FPU
 
 

en C++ tu peux modifier la convention d'appel. Genre sous VS t'as les mots clés
 
__cdecl, __stdcall __fastcall

Ah oui j'avais vu cela en C++ j'y ait lu quelques textes sur ça, si j'ai bien compris c'est la façon dont on passe les paramètres dans quel ordre et comment se traite le retour.
 
Ou on les passes, tu veux dire ou mettre les valeurs des variables ? Sur la pile j'imagine
 
Qu'est-ce les registres ALU et la pile FPU ? C'est une pile prédifini par le cpu ??
 
Mais tout cela est d'ordre d'un OS ou si c'est "général" dans le sens ou ça dépend du Loader ?

pour les conventions d'appels ( et le reste de l'assembleur )
http://www.mentaloverflow.de/robsi [...] ok-pdf.zip
pour le décodage d'opcode
http://pr0g.free.fr/fichiers/opcodedecodingp1.txt
la dedans aussi il doit y avoir des trucs
http://www.intel.com/design/pentiu [...] ex_new.htm
 
bon courage  

Merci