Introduction à la compilation avec LLVM

a marqué ce sujet comme résolu.

Je suis en train d'essayer d'installer LLVM, mais je galère. Est ce que tu pourra détailler la partie "Installation" un peu plus ?

Ardakaniz

Tu n'as pas besoin de compiler LLVM pour l'utiliser, la seule chose à faire est d'installer la version pré-compiler (inclue dans clang) sous Pre-Built Binaries: (Pour Windows -> Clang for Windows) http://llvm.org/releases/download.html#3.7.0

Mes projets: Le Lnx, un tout nouveau langage de programmation simple, un moteur C++ de zéro, GZE - GroundZero Engine

+1 -0
Auteur du sujet

Je passe donner quelques nouvelles. La rédaction du tutoriel a fortement ralenti en raison de contraintes au niveau de mes études. Je réalise quelques modifications quand j'ai le temps, mais je ne pense pas pouvoir mettre quoi que ce soit en bêta avant Noël.

Mon Github | Pony : Un langage à acteurs sûr et performant

+0 -0

Je ne parlerai pas de théorie des langages ici. Le frontend sera basique et « empirique ». Il sera assez proche de celui du tutoriel LLVM, pour donner une idée.

Je vais revoir un peu l'introduction.

Praetonus

Je souhaiterais réagir à cela. En effet, je me demande s'il est intéressant de parler de compilation sans parler de théorie du langage. Je ne dis pas qu'il faille introduire le lecteur à cette théorie dans ce tutoriel, mais peut-être l'intégrer aux pré-requis.

"Bienheureux celui qui sait rire de lui-même, il n’a pas fini de s’amuser." Joseph Folliet

+0 -0
Auteur du sujet

Je me faisais la même réflexion dernièrement. Je suis certainement allé un peu loin dans ce message. Même si je compte aborder la chose de manière pratique, un passage sur les grammaires en général sera nécessaire. Je ne sais pas si ça vaut le coup d'aborder ça plus en profondeur (peut-être dans une partie « Pour aller plus loin »), vu qu'un des objectifs du tutoriel est de donner l'envie de s'intéresser aux aspects théoriques de la question, notamment au Dragon Book, où tout est expliqué en long, en large et en travers.

Mon Github | Pony : Un langage à acteurs sûr et performant

+0 -0
Auteur du sujet

Bonjour.

J'ai finalement décidé de changer légèrement l'orientation du tutoriel. La théorie des langages sera abordée de manière un peu plus sérieuse que prévue au départ, avec notamment la définition des grammaires et des concepts associés. J'intègre également au tutoriel une bibliothèque permettant de construire des analyseurs lexicaux et syntaxiques à partir d'une grammaire, Boost.Spirit.

La bêta a été mise à jour, avec quelques modifications dans l'introduction et une spécification plus nette des prérequis.

Merci d'avance pour vos commentaires.

Édité par Praetonus

Mon Github | Pony : Un langage à acteurs sûr et performant

+0 -0
Auteur du sujet

Bonjour.

J'ai commencé la partie « code » avec la présentation de l'analyse lexicale avec Boost.Spirit. J'aimerais particulièrement avoir vos avis sur la présentation alternée du code et des explications. Est-ce lisible et compréhensible de cette manière ? Si non, qu'est ce qui rend la lecture difficile ?

J'ai également fait quelques modifications sur les parties déjà rédigées, les commentaires sur le fond ou la forme sont toujours les bienvenus.

Merci d'avance pour vos commentaires.

Édité par Praetonus

Mon Github | Pony : Un langage à acteurs sûr et performant

+0 -0
Auteur du sujet

Bonjour.

J'ai achevé la rédaction de la partie sur la prise en main de Boost.Spirit. Vous y trouverez un code d'exemple et des explications pour l'analyse lexicale, l'analyse syntaxique et l'utilisation des deux ensemble.

J'attends toujours vos remarques. :)

Merci d'avance pour vos commentaires.

Édité par Praetonus

Mon Github | Pony : Un langage à acteurs sûr et performant

+0 -0
Auteur du sujet

Spirit dépend de plusieurs autres bibliothèques Boost. En général, c'est une mauvaise idée d'installer Boost par morceaux. Au passage, Spirit est header-only, donc il n'y a rien à compiler.

Quelle est la partie de l'installation qui te pose problème ? Je peux surement détailler plus dans la section correspondante.

Mon Github | Pony : Un langage à acteurs sûr et performant

+0 -0
Auteur du sujet

Je te rejoins sur les temps de compilation (même si avec Clang le problème est assez réduit par rapport à d'autres compilateurs), mais moins sur le reste.

Les erreurs sont certes assez cryptiques au début, mais elles se réduisent à très peu de causes différentes. 90% du temps, c'est dû soit à une incohérence dans les attributs, soit à l'utilisation d'un truc non paresseux au mauvais endroit. Une fois ces deux choses comprises, la cause de l'erreur se repère très facilement. De plus, les erreurs classiques sont décrites aux endroits correspondants dans les fichiers de Boost.Spirit. Je compte également intégrer un « guide de survie » pour la bibliothèque au tutoriel.

Concernant la doc, c'est vrai qu'elle pourrait être plus étoffée, mais je pense qu'elle reste compréhensive et quasiment complète, il faut juste passer du temps dessus.

Mais je suis d'accord, Boost.Spirit n'est pas une bibliothèque simple, et n'est clairement pas destinée à des débutants éclairés armés seulement de la documentation officielle. Mais mon objectif à travers l'utilisation de cette bibliothèque pour le tutoriel, en plus de simplifier le frontend, est justement d'aider le lecteur à franchir le cap des premières utilisations, pour qu'il puisse par la suite l'utiliser de lui même dans des contextes non couverts par le tutoriel.

Mon Github | Pony : Un langage à acteurs sûr et performant

+1 -0

Concernant les grammaires, ne penses-tu pas qu'il serait préférable de les aborder dans un autre tutoriel et les mettre en pré-requis à celui-ci ? Là, non seulement on peut difficilement réutiliser ce que tu as écrit, mais j'ai peur que ça ne soit pas assez complet pour être exploitable.

"Bienheureux celui qui sait rire de lui-même, il n’a pas fini de s’amuser." Joseph Folliet

+1 -0
Auteur du sujet

@Ardakaniz : Je pense également que j'ai trop condensé les informations, notamment sur les différents opérateurs. Je vais reprendre pour distiller un peu plus.

@Vayel : En effet, il manque une explication un peu plus pratique sur la construction des grammaires. Même si un tutoriel complet est une bonne idée (et est sur ma liste de choses à faire), celui-ci devra parler, en plus de la construction, des différentes méthodes d'analyse et de dérivation, dont le lecteur n'a pas besoin de connaitre le fonctionnement pour utiliser Boost.Spirit. Je pense donc présenter une méthodologie générale pour construire une grammaire pour un langage de programmation dans le tutoriel, et peut-être faire par la suite un autre tutoriel rentrant dans les détails. Qu'en pensez vous ?

Mon Github | Pony : Un langage à acteurs sûr et performant

+1 -0

Ca me semble une bonne idée. Si j'ai bien compris donc, l'objectif de ton tutoriel est de faire découvrir au lecteur la compilation par la pratique, i.e. on bidouille avec les grammaires et LLVM pour se faire une idée du processus de compilation ?

Le cas échéant, il me paraît intéressant d'indiquer en introduction que le lecteur n'acquièrera pas rigoureusement les bases théoriques de la compilation, nécessaires, je crois, à tout projet de compilation digne de ce nom.

"Bienheureux celui qui sait rire de lui-même, il n’a pas fini de s’amuser." Joseph Folliet

+0 -0

Dans le premier chapitre :

Une grande famille de langages est celle des langages interprétés, comme Python, Ruby et Perl. Ces langages reposent sur un interprète, qui exécute le programme source instruction par instruction.

Les 3 langages choisis en exemple sont mal choisis.

  • Python compile les programmes en bytecode avant de les interpréter (le bytecode est d'ailleurs accessible au runtime en allant chercher l'attribut func.__code__.co_code de n'importe quelle fonction en pur python, et il est désassemblable au moyen du module standard dis). Il y a même un pinhole optimiser dans l'interpréteur standard, et certaines distributions (comme Pypy) poussent le vice avec un compilateur JIT ;
  • Perl 6 repose sur un principe équivalent, et va encore plus loin que Python en proposant un code à trois adresses ouvert pour sa VM, permettant ainsi aux utilisateurs de tirer parti de son moteur d'exécution avec d'autres langages de script dont il suffit d'écrire le frontend ;
  • Je suis quasiment certain que c'est pareil pour Ruby.

Édité par nohar

I was a llama before it was cool

+0 -0
Connectez-vous pour pouvoir poster un message.
Connexion

Pas encore membre ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte