Discussion :

[mchk0123]

Bonjour, j'ai développé un petit langage interprété.
Maintenant j'aimerais qu'il puisse générer du code natif compilé, j'y suis presque arrivé sauf que la phase de compilation est plutôt longue et le code généré loin d'être optimal ...

Donc je suis à la recherche de tout type d'informations sur le sujet.
En particulier et en vrac :
- algorithmes optimisés de compilation pour une compilation plus rapide
- algorithmes et heuristiques d'optimisation de code compilé
- site internet sur les algorithmes spécialisés en compilation
- pointeurs (FAQ, livres, initiation, ...) aux théories de la compilation
- petits langages compilés en licences code libre (source d'inspiration) ...

Pour les sites Web, il y a bien Tony's Brook Algorithms repository, mais les algorithmes ne sont pas adaptés à mon pb.

[pseudocode]

Je pense que LLVM est fait pour toi

[mchk0123]

Waou, m'a l'air pas mal du tout ... avec plein d'articles.

Je ne pensais pas que l'on pouvait faire autant chose sur du mid-code.

Passer de l'interprété au compilé c'est un vrai projet en soit.

[millie]

Je pense que LLVM est fait pour toi

J'avais déjà réalisé un petit compilateur, qui compilait vers un langage 3 adresses (une sorte de langage universelle, assez proche de l'assembleur). Mais je me suis souvent dit que si je le refaisais, j'aurais tendance à compiler vers un langage de plus haut niveau, genre C, ou C++. Je limiterai ainsi le développement, et ce serait à gcc de faire pas mal d'optimisation, et à gcc de faire le code machine. Ce qui fait que d'un coup, le langage deviendrait multiplateforme en plus.

[mchk0123]

Merci millie , cela m'éclaire grandement sur la façon dont je vais m'y prendre.
A vrai dire je n'y avais pas pensé, mais avec le recul ça me semble trés naturel.
D'ailleurs gcc ne fait-il pas la même chose (au niveau en dessous) en s'appuyant sur l'assembleur gas ?

[millie]

De ce qu'il me reste de mes cours de compilations, on nous avait dit qu'une stratégie intéressante pour faire un compilateur était de faire ça en plusieurs étapes.

Une étapes où l'on compile dans un langage "universel", et une étape où l'on compile le langage universel vers un langage assembleur (et puis l'assembleur fait le reste).

Souvent (mais alors, je ne sais pas avec quel langage ils le font), il compile vers un langage 3 adresses (assez proche de l'assembleur, mais assez différent pour qu'il puisse être traduit dans n'importe quel langage assembleur).

Maintenant, on peut aussi penser qu'on dispose de langage intérmediaire de plus haut niveau et bien plus pratique, donc, on peut aisément se demander pourquoi on se priverait pas de compiler vers un langage comme le C (ce qui permet d'emblée de supprimer la deuxième étape)

Il me semble par exemple (ce n'est pas une certitude, mais les souvenirs que j'ai) que le langage Ocaml réalise ce genre de chose. Il y a une étape où il transforme le code camL en code C. J'espère ne pas dire de bêtise

EDIT : J'ai dit le C car c'est le langage que je connais le mieux, mais évidemment, il est possible de compiler vers un autre langage

[Jean-Marc.Bourguet]

J'avais déjà réalisé un petit compilateur, qui compilait vers un langage 3 adresses (une sorte de langage universelle, assez proche de l'assembleur). Mais je me suis souvent dit que si je le refaisais, j'aurais tendance à compiler vers un langage de plus haut niveau, genre C, ou C++. Je limiterai ainsi le développement, et ce serait à gcc de faire pas mal d'optimisation, et à gcc de faire le code machine. Ce qui fait que d'un coup, le langage deviendrait multiplateforme en plus.

C'est une technique classique qui permet d'avoir un code raisonnablement efficace tout en se concentrant sur le front-end, qui contient normalement la partie la plus intéressante pour un nouveau langage. Mais on a facilement des dépendances sur la taille des types, la boutitude, le format des pointeurs, etc.

[pseudocode]

Ah ben c'est sur que si tu peux ecrire un traducteur de ton langage vers le C, ca va beaucoup te simpifier la vie ! Une simple regle a ajouter dans ton makefile, et hop... compilation par gcc avec toutes les optims.

Mais bon, je ne faisais que répondre a ton 1er post qui parlait de techniques de compilation et optimisation. D'une maniere générale, on compile toujours le langage de départ vers un langage intermediaire. C'est sur ce langage intermédiaire qu'on applique les optimisations. Ensuite vient la génération du code machine spécifique (jeu d'instruction).

Ce découpage permet de faire evoluer indépendamment les langages de départ supportés (front-end), les techniques d'optimisation (mid-level) et les architecture matérielles supportées (back-end).

[mchk0123]

Merci encore pour tous ces conseils.
Je vais effectivement dans un premier temps généré du C|C++
tant que ca reste un projet perso.

Si jamais un jour le langage devient publique je suivrait
tes conseils "pseudocode".

Pour ce qui est du bootstrap est-ce que c'es un pb. spécifique aux
compilateurs ?
Parce que en interprété soit j'en ai fait sans le savoir, soit je suis un
lol

[Jean-Marc.Bourguet]

Pour ce qui est du bootstrap est-ce que c'es un pb. spécifique aux compilateurs ?

Non, c'est un problème spécifique aux langages implémentés en eux-mêmes

[mchk0123]

Mouais... donc j'en ai fait un peu.
Beurk, il va se digérer lui-même ...

Un rapport entre la boutitude et le bootstrap ? (J'ai peut-être mal compris).

[pseudocode]

Non, c'est un problème spécifique aux langages implémentés en eux-mêmes

ca peut même etre étendu aux Operating System... quel est le process qui lance le 1er process ? sur quel OS tourne le noyau ?

[Jean-Marc.Bourguet]

ca peut même etre étendu aux Operating System... quel est le process qui lance le 1er process ? sur quel OS tourne le noyau ?

Un micro noyau tournant dans une machine virtuelle contrôlée par un superviseur tournant sur un émulateur compilé pour une machine virtuelle ayant un compilateur JIT pour une ISA implémentée par traduction dynamique vers un jeu d'instruction interne interprété par un micro-programme.

[pseudocode]

Un micro noyau tournant dans une machine virtuelle contrôlée par un superviseur tournant sur un émulateur compilé pour une machine virtuelle ayant un compilateur JIT pour une ISA implémentée par traduction dynamique vers un jeu d'instruction interne interprété par un micro-programme.

le micro-programme il tourne sur un FPGA ?

[Jean-Marc.Bourguet]

le micro-programme il tourne sur un FPGA ?

Non. On n'a qu'une description VHDL qui est exécutée sur un simulateur hard

[pseudocode]

Non. On n'a qu'une description VHDL qui est exécutée sur un simulateur hard

Ah ok. Alors, on n'a pas de probleme de bootstrap...

[Jean-Marc.Bourguet]

Ah ok. Alors, on n'a pas de probleme de bootstrap...

Si. Ce système de simulation a été conçu avec une chaîne d'outils d'EDA tournant sous l'OS en question.

[pseudocode]

Si. Ce système de simulation a été conçu avec une chaîne d'outils d'EDA tournant sous l'OS en question.

Ah mince... Et y a pas une version windows ? Non parceque la j'ai un linux mais je peux toujours installer Qemu... enfin dès que je l'aurais cross-compilé dans ma scratchbox. Ou alors je compile gcc en canadian-build depuis cygwin, et puis je recompile Qemu en natif, c'est peut-etre plus simple.

Edit: si vous prenez cette conversation en cours, ne vous inquietez pas. C'est normaaaaaaaaaaaaal

[millie]

Je crois qu'on s'écarte légerement du problème de départ

[pseudocode]

Je crois qu'on s'écarte légerement du problème de départ

Hum... oui peut-etre un poil hors sujet.

Bon alors, le "bootstrap" c'est la technique qui permet de compiler le compilateur, etant donné que le compilateur est écrit dans le langage qu'il est censé compiler. (on dirait du Perceval dans Kaamelott)

Je n'ai pas de definition exacte de la "boutitude". C'est un terme un peu fourre-tout qui melange la représentation des données et le moyen de connaitre cette représentation.