Bonjour!
Vu qu’il y a pas mal de programmeurs dans le coin, j’ai une question pour vous:
Pour programmer, on écrit un code. Ce code est ensuite, selon les cas, interprété ou compilé. Sauf que, il a fallu coder cet interpréteur ou compilateur. Mais comment on a pu compiler le compilateur? Avec un autre compilateur d’un autre langage?.. Bref, je n’arrive pas à boucler la boucle. Ne me dite pas que au tout début, un compilateur a été écrit en binaire???
Des gens ont conçu le langage d’assemblage pour se facilité la programmation de circuits programmables. La traduction entre langage d’assemblage et assembleur se fait grâce à un programme appelé assembleur. Celui-ci fut écris dans la seule méthode qui existait jusqu’à lors pour programmer écriture du binaire.
Une fois qu’ils ont fini le développement de cet assembleur, il l’ont réécris en langage d’assemblage et assemblé avec leur premier assembleur. À partir de ce moment là ils n’avaient plus besoin d’écrire des programme en binaires.
Ce ce qui se passe pour tout les langages :
[ul]
[li]on écris le compilateur dans un langage existant[/li]
[li]on réécris le compilateur dans le nouveau langage[/li]
[li]le langage deviens auto suffisant[/li][/ul]
Pour les langages interprété ce n’est pas possible évidement (Pypython ça compte pas).
Salut,
[quote=“thuban”]Bonjour!
Vu qu’il y a pas mal de programmeurs dans le coin, j’ai une question pour vous:
Pour programmer, on écrit un code. Ce code est ensuite, selon les cas, interprété ou compilé. Sauf que, il a fallu coder cet interpréteur ou compilateur. Mais comment on a pu compiler le compilateur? Avec un autre compilateur d’un autre langage?.. Bref, je n’arrive pas à boucler la boucle. Ne me dite pas que au tout début, un compilateur a été écrit en binaire???[/quote]
Dans mon premier langage la division sur 24 chiffres se nommait 15 (en binaire) la multi 14 … 
et il fallait que le programme tienne sur 64 lignes 
Presque … sur les plateformes x86 le langage “de base” est l’assembleur. Celui çi se compose d’une foule d’instructions TRES simple, genre charge en mémoire vive tel donnée, additionne ces deux zones mémoire, etc …
Chacune de ces instructions sont retranscrites en binaire via une table de correspondance entre l’instruction et sont code binaire (voir ici en bas de page).
Et donc une fois une première version du compilateur d’un nouveau langage fait tu peut le réécrire dans ton langage …
Presque … sur les plateformes x86 le langage “de base” est l’assembleur. Celui çi se compose d’une foule d’instructions TRES simple, genre charge en mémoire vive tel donnée, additionne ces deux zones mémoire, etc …
Chacune de ces instructions sont retranscrites en binaire via une table de correspondance entre l’instruction et sont code binaire (voir ici en bas de page).
Et donc une fois une première version du compilateur d’un nouveau langage fait tu peut le réécrire dans ton langage …[/quote]
L’assembleur a d’abord était écris en binaire (et c’est le premier compilateur).
Merci pour vos réponses! C’est fou tout ça quand même! 
Les instruction d’assembleur ne sont qu’une traduction d’un code binaire, ex MOV AX, = A1 . A1 étant le code hexadécimal = 10100001 en banaire.
Donc si tu considère qu’une table de traduction des est un compilateur alors oui, le premier compilateur à été écris en binaire.
Les instruction d’assembleur ne sont qu’une traduction d’un code binaire, ex MOV AX, = A1 . A1 étant le code hexadécimal = 10100001 en binaire.
Donc si tu considère qu’une table de traduction des est un compilateur alors oui, le premier compilateur à été écris en binaire.[/quote]
Je sais très bien comment marche un assembleur j’ai eu à en coder un à la fac. Un compilateur est un traducteur, donc je pense qu’un assembleur est un compilateur.
Petite définition :
Un compilateur est un programme permettant de passer d’un langage source
à un langage cible.
On voit donc que c’est une notion très vaste…
Du temps de l’époque héroïque des Apple][ et plus, seul le code binaire était fourni avec un désassembleur. La première chose qu’on faisait était d’écrire assembleur et compilateur. Pour l’assembleur, j’avais écrit en binaire un noyau de base traduisant les code memo en code machine mais sans étiquettes en binaire, puis ce noyau m’avait servi à améliorer le dit assembleur en y rajoputant les étiquettes puis les macros (mais là j’avais un peu baclé le truc). Pour les compilateurs, le plus simple est de faire de la cross compilation. Ainsi, pour des commandes, j’avais écrit un compilateur pascal pour 6809 en pascal sur une grosse machine puis je lui avais donné lui même comme argument. Le fichier récupéré était directement exécutable sur le 6809. (C’était un sous pascal pour système réduit).
Le principe est assez général.
La compilation comporte 3 étapes, les deux premières (analyse lexical et syntaxique) sont automatisées par lex et yacc. La dernière est assez simple à la base mais devient très compliquée sur on veut obtenir un code très efficace. LOa compilation n 'est pas une simple traduction mais s’approche plus de la lecture/exécution d’une suite de lettres qu’on reconnait comme suite de mots clefs d’un langage (analyse lexicale), puis qu’on interprète comme des «opérateurs ou actions» (analyse syntaxique) et qu’on éxécute ou traduit (éxécution, compilation au sens usuel du terme, etc). C’est très général comme terme…
Ça me fait beaucoup penser à la création de logiciels de chiffrement (ou d’un format). Quand tu commence avec un algo qui ne possède pas d’implémentation tu es obligé de te taper l’algo à la main et d’utilser cette données et ce résultat pour valider ou non ton programme (bien sur il faut un ensemble de tests complet pas un seul).
C’est du second degré ou tu es vraiment en train de dire que quand tu veux un algo qui n’existe pas, tu es obligé de le coder (et accessoirement de le tester) ? 
Je pense aujourd’hui qu’on utilise à fond la cross-compilation.
Observes bien. Supposons que tu achètes une carte processeur ARM. Sur ta debian tu peux compiler pour ce processeur, il y a des extensions de GCC qui le permet.
Maintenant si tu veux transformer ta carte processeur en machine de développement, il te faudra un compilateur qui tourne dessus. Tu developperas ton compilateur sur ta debian (en C par exemple), tu transferas l’exécutable sur ton système cible et tu as compilateur qui tourne dessus.
Tu récupères le code source d’un éditeur de texte (ou tu le crées) et tu peux le compiler directement sur ta carte ARM. À ce stade tu as une machine de développement, tu peux même réécrire le compilateur directement dessus.
dmon, je cherche une carte avec ARM9 (ou +) pour faire de l’embarqué avec gnuarm.
carte à faire soit même ou à acheter, aurais tu des informations ?
merci.
wiki
Linux Embarqué pour tous !
Communication asynchrone et interface graphique portables sous Qt
Instrumentation scientifique reconfigurable
On dit aussi qu’il est auto-hébergé.
Un compilateur (au sens C -> ASM) est biiiiiieeeeeeen plus dur à faire qu’un simple assembleur
On dit aussi qu’il est auto-hébergé.
Un compilateur (au sens C -> ASM) est biiiiiieeeeeeen plus dur à faire qu’un simple assembleur[/quote]
Et un compilateur C++ c’est biiiiiiiiiiiiieeeeeeeeeeen plus dur à faire qu’un simple compilateur C.
Ouaip, j’aurai qu’une chose à ajouter, c’est que tout compte fait, en fin de chaîne, que ce soit avec un langage interprété ou compilé, on obtient un programme binaire exécutable sur un type de processeur donné. Ce programme binaire peut être observé en syntaxe assembleur du processeur correspondant (par exemple avec objdump) puisqu’une instruction assembleur = une instruction binaire.
Le truc, c’est que le compilateur transforme le programme textuel (C++, C, Java…) en un programme binaire pour un type de processeur. Donc une fois compilé, il ne fonctionnera pas sur un autre processeur car chaque processeur possède un jeu d’instructions différent et est matériellement différent (64 bits vers un 32 bit, Phenom II vers un PowerPC).
Pour Java, les javaistes purs et durs affirment que c’est le langage ultime car il est portable sur toutes les machines… en fait, ce n’est pas tout à fait exacte. Il faut installer au préalable une machine virtuelle java (JVM) sur la dite machine : un programme compilé pour le type de processeur de la machine (en clair, si t’as pas de JVM pour ton processeur, tu peux pas faire tourner java). Le programme Java pré-compilé (.class dans .jar) est alors appelé avec la JVM qui le transforme “automatiquement” en bouillie binaire pour le processeur (sans parler des différentes versions de Java, on obtient des bouillies de plus ou moins bonne qualité). Même procédé avec les langages interprétés (shell, python, perl et autres).
Au final on se retrouve avec du code binaire et l’on est jamais vraiment très loin de l’assembleur. Si on y regarde encore de plus près, on arrive au niveau électronique.
[quote=“cactus”]Au final on se retrouve avec du code binaire et l’on est jamais vraiment très loin de l’assembleur. Si on y regarde encore de plus près, on arrive au niveau électronique.
[/quote]
Je dirai même plus, on arrive directement toujours au code machine. Le tout c’est de le contourner et de rester le plus loin possible de lui. Car plus on est loin du code machine et plus on développe rapidement un programme (une application).