Bonjour,
 
J'ai besoin d'aide sur un point lié au processeur et au type de code exécutable généré par un compilateur.
Je suis intéressé si quelqu'un connaît un bon site Web sur le sujet.
 
Il y a plusieurs microprocesseur sur le marché, même si Intel se taille largement la part du Lion il est vrai.
Donc en théorie il y a plusieurs architectures de microprocesseurs possibles. Or il faut bien que le code exécutable fonctionne pour toutes les architectures de processeurs.
 
Après plusieurs étape d'analyse lexicale et grammaticale que je passe sous silence, un compilateur est censé généré du code exécutable. Mais comment fait-il ?
 
En effet les instructions du langage assembleur (move, add, etc...) ne sont que du texte sauf si on fait une correspondance entre ces instructions  (move, add, etc...) et les codes mnémoniques (spécifiques aux archi des CPUs) qui eux sont bien "claqués" en dur (car digérable par un CPU) et qui représentent bien une succession de 0 et de 1 exercant une certaine action sur le CPU. Est ce que la liste des 0 et des 1 est mise dans le compilateur ? Est ce que le CPU dit au BIOS je suis un CPU qui gère tel ensemble de mnémonique et pas un autre ?
 
Est ce une machine spéciale qui a injecté ces mnémoniques sous forme de 0 et 1. Cette machine est-elle à l' "extérieure" du compilateur et du CPU ? cela  voudrait dire qu'il y a une étape hardware avant tout développement de compilateur ?
 
Merci du coup de main

Salut,
 
Normalement ce dont tu dis dépend en réalité du type de jeu d'instruction. Or Intel et AMD exploite le même jeu (x86-x64) avec les même instructions (sauf pour AMD qui est en retard sur quelques points).
 
Mais pour moi c'est plus une histoire de jeu d'instruction qu'autre chose enfaîte (pour ça que les programme compilé pour ARM marche pas sur du x86-x64).

Les instructions assembleur sont du texte, au même titre qu'un langage compilé (C, C++ etc), ou interprété en temps réel (BASIC, JAVA) etc.
 
Au total, tout "finit" en langage machine = les mnémoniques donc, que le code soit compilé pour le processeur en question ou "traduit à la volée" pour les langages interprétés.
 
L'assembleur est ce qu'il y a de plus proche du "langage machine" dans la mesure où c'est spécifique à chaque CPU.
 
Ayant bricolé des ordis depuis l'époque du Z80, avec quelques milliers d'heure de bonheur adolescent (erf') à coder en assembleur sur un éditeur ligne par ligne, je comprends qu'il y ait quelque chose de nébuleux à appréhender la chose.
 
Il faut juste comprendre qu'un compilateur compile POUR un processeur/une architecture.
 
Tu peux très bien utiliser sur PC un compilateur qui va produire du code pour un processeur ARM embarqué, ou un assembleur Z80 pour du code qui sera exécuté au final sur un Amstrad CPC.
 
Pour rester plus simple : ton compilateur sur PC peut produire du code qui sera "optimisé Intel", ou "optimisé AMD", en intégrant bien que ça dépend de la génération de processeur : on peut demander du "386" pour les vieux processeurs AMD/Intel type Pentium IV ou Athlon XP, ou du x64 pour les processeurs modernes ; On peut aussi spécifiquement choisir d'utiliser certaines instructions ou pas, dans la mesure où tous les processeurs même modernes/actuels n'ont pas les mêmes jeux d'instruction.
 
Et pour finir, je dirais qu'un bon compilateur doit pouvoir gérer la taille des cache du processeur "ciblé" = tout faire pour que les routines "tiennent" dans le cache ce qui accélérera grandement le traitement du code.
 
Un compilateur peut produire à partir de la même source "texte" du code qui tournera d'un coté sur un Pentium IV, de l'autre sur un AMD Ryzen, mais le code final sera différent voire très différent sur certaines portions en tout cas (instructions différentes, manquantes, optimisées etc)
 
Je te réponds de manière théorique parce que je n'ai jamais touché un compilateur C ou autre sur PC, ceux qui en font un usage quotidien pourront te renseigner plus finement.

oui zonka merci pour ta réponse.
En effet je savais que l'on pouvait spécifier le type de processeur directement dans le compilateur mais la génération des "0" et des "1" des mnémoniques restent un mystère. Ma question pose indirectement la question du premier compilateur...comment on l'a codé (et là encore il a bien fallu mettre des mnémoniques via une machine hardware je pense qui savait gérer les entrées sorties du clavier et je pense de fil en aiguille on a pu se débarasser de cette machine hardware qui claquait le code pour le remplacer par un soft, le compilateur. Mais à confirmer par un expert !! Je n'en sais rien en fait)

La génération des mnémoniques n'est pas un mystère : à un moment donné, le compilateur qui est un programme va tout simplement fabriquer le code final (langage machine) , en traduisant le texte source et en écrivant des données dans la mémoire de l'ordi = le code final, que tu vas sauvegarder dans un fichier. Ca c'est normalement la partie la plus compréhensible ; alors il ne va pas écrire des "0" et des "1" , il va écrire des octets (8 bits), des mots (16 bits), des longs mots (32 bits)...
 
Le "1er compilateur" a très clairement été programmé en assembleur.
 
La dernière version du dernier compilateur C a été compilée (pour chaque machine/plate-forme, PC Windows, PC Linux etc) avec l'avant-dernière version du compilateur en question.  
 
Le 1er assembleur a du être programmé avec des cartes perforées, sur une autre machine etc.
 
Il faut bien imaginer que depuis le temps que l'informatique existe, on est loin du "1er programme", et qu'on peut compiler un programme pour une AUTRE PLATE-FORME qui n'a rien à voir au niveau hardware ou software.
 
L'assembleur Devpac ou SEKA que j'utilisais sur Amiga ont clairement été programmés sur une autre machine (un PC, un VAX à carte perforées, que sais-je...). Le compilateur C sur Amiga a soit été programmé en assembleur sur Amiga, soit été généré lui aussi sur un PC ou autre grosse machine n'ayant rien à voir au niveau hardware/software.
 
Sur le plan ludique, je te propose d'essayer un jeu fort sympathique : Human Resource Machine : c'est ni plus ni moins que de la programmation en assembleur sous forme graphique, et ça aide à mieux comprendre comment on gère des données de manière très "basique" (= au niveau CPU) même si c'est extrêmement simplifié.
 
http://www.jeuxvideo.com/test/4472 [...] achine.htm

Pas grand chose à rajouter...
Pas tous les compilateurs permettent de faire du cross-compiling. Avec GCC, il faut une version spécifique pour compiler du code ARM par exemple.
Par contre, on peut définir le type d'architecture visé avec le même compilateur: ARMv7, ARMv8 par exemple...

Pour ce qui est du mapping assembleur vers binaire, là encore rien de sorcier... il y a des tables. Ici pour le x86:
http://ref.x86asm.net/geek.html#x80

Le compilateur faisant simplement la traduction...
Après vient le "linking" de toutes les librairies compilées avec le placement correct des adresses mémoire pour chaque partie du code.

Pour ce qui est de la gestion des caches et autres, je suis d'accord, le compilateur peut aider, mais c'est surtout la personne qui code qui est responsable de faire les choses correctement pour éviter des pertes monumentales de performance ou des fuites mémoire (le fameux "free" oublié une fois le contenu utilisé ). Le meilleur compilateur au monde ne fera jamais de miracle si le code de départ est écrit n'importe comment...

merci cool pour la table ah oui....ca fait pas mal de ligne !!!
Je garde ça en mémoire...neuronale !!
 
Donc on est d'accord qu'il n'y avait pas de compilo au moment d'écrire le premier compilateur...du coup...pas de code exe pour dire va chercher l'opcode x dans la mémoire Y dès que tu voies le mot Add (de l'assembleur quoi)  
 
Du coup si qqn parmi vous deux à trouver un livre technique qui explique comment ils ont fait pour le premier compilo ?
 
Merci à tous les 2

Si tu as quelques aspirines et une bonne motivation

https://www.bell-labs.com/usr/dmr/www/chist.html

https://www.quora.com/What-language [...] written-in

En gros, tu verras que c'est l'éternel débat de la poule et de l'oeuf : pour faire le 1er compilateur "C", il y avait le BCPL, le Fortran etc.

Mais vraiment, pour le côté fun , teste Human Resource Machine, perso j'ai pris grand plaisir à bricoler des routines avec,en retrouvant des reflexes du genre "raaah, ras le bol, bon, je code 'sale', on optimisera après" (oui je sais, c'pas bien)

Et juste pour te donner un mal de tête supplémentaire, tu peux te pencher sur:

- la virtualisation

- les émulateurs

Les tous premiers codes étaient en assembleur, c'est certain.
Visiblement, les premiers "assembler" utilisaient la méthode du bootstrapping.
En gros, une toute petite partie était écrite en langage machine qui donne la version 0, puis avec celle-ci il est possible de créer un code plus complet (version 01), avec la 01 on peut utiliser un code encore plus complet et ainsi de suite, jusqu'à avoir quelque chose d'utilisable.

Une personne détaille la méthode ici:
https://softwareengineering.stackex [...] chine-code

Le temps de génération est long par contre