Pour corriger ce que dit l'auteru du journal, on ne peut pas vraiment dire que llvm soit encore vraiment expérimental. Il est relativement proche de ce que 'lon pourrait appeller un programme stable, et encore plus dans le cas de la 2.6 qui va bientot sortir, le freeze c'est produit il y a quelques jours.
Le code intermédiaire devrait être parfaitement compatible dans le sens ou un code actuel devrait rester executable par toutes les futures version de llvm, ce qui n'empeche pas à l'avenir d'ajouter de nouvelles instruction si celles-ci sont nécéssaire.
LLVM est même suffisament stable pour que Apple ait choisit de le mettre au coeur de son système, et contribu pas mal au passage. LLVM est une des brique éssentielle du fameux OpenCL.
Et si le développement de LLVM s'arrête? Ton idée est entièrement dépendante de ce produit. Tout autre gestionnaire de paquet marche avec n'importe quel compilateur.
Vu le projet il y a relativement peut de chance que le dévellopement s'arrete, mais même si c'était le cas, c'est du logiciel libre et il est possible de reprendre le dev.
Apparemment LLVM ne supporte vraiment que C et C++ pour l'instant
LLVM seul ne supporte absolument rien ;-)
C'est juste la spécification d'un code intermédiaire et tout un tas de bibliothèques et outils pour le manipuler et notament le copiler en code natif. Il y a pas mal de projet de compilateurs qui produisent ce code intermédiaire au lieu de produire directement du code natif.
C'est le cas par exemple de clang qui est un copilateur destiner à compiler du C ainsi que d'autre langage dérivés. Et pour CLang, en effet, il supporte actuellement très bien le C et produit du code très performant. L'objective-C est relativeent bien supporté, je sais pas le staus exacte mais là aussi c'est un truc ou apple contribue pas mal. Par contre pour le C++, pour l'instant c'est encore très expérimental et de nombreuse choses ne sont pas implémentée.
Par contre il existe aussi llvm-gcc qui est un bacend pour gcc. C'est-à-dire que c'est une modification de gcc qui lui permet de produire du code llvm au lieu de code pour un processeur. Donc ça permet d'avoir un copilateur qui supporte éxactement les même langages que gcc.
Et il y a différents autres compilos disponibles, même parfois pour des langages auquels on ne penserais as du style un compilateur pour lua.
Sinon une petite question: puisque LLVM est avant tout une VM, peut-être n'y aurait-il même pas besoin de compiler en langage machine les programmes chargés, non?
Comme tu le dis après, L'objectif de llvm c'est quand même de produire du code très performant, et les perfs du code interprété sont quand même pas térrible à côter de celle du binnaire. Et vu le coût du JIT autant ne pas s'en priver.
Et un dernier petit point pour l'auteur du journal. L'argument de ca prend moins de place est loin d'être pertinent, dans la grosse majoritée des pacquet, à mon avis, ce qui prend de la place c'est pas les binnaires mais les donnés. De plus les mesures sont à faire sur le code une foi compressé car à tous les formats de paquets que je connais compressent le tout.
Avant de penser à des optimisation sur la taille du code, il vaudrais mieux faire quelques stat pour savoir s'il y a quelque chose à gagner.
Voilà, j'éspère avoir clarifier quelques points sur llvm et le reste.
[^] # Re: Intéressant
Posté par beagf . En réponse au journal LLVM dans un gestionnaire de paquets ?. Évalué à 5.
Pour corriger ce que dit l'auteru du journal, on ne peut pas vraiment dire que llvm soit encore vraiment expérimental. Il est relativement proche de ce que 'lon pourrait appeller un programme stable, et encore plus dans le cas de la 2.6 qui va bientot sortir, le freeze c'est produit il y a quelques jours.
Le code intermédiaire devrait être parfaitement compatible dans le sens ou un code actuel devrait rester executable par toutes les futures version de llvm, ce qui n'empeche pas à l'avenir d'ajouter de nouvelles instruction si celles-ci sont nécéssaire.
LLVM est même suffisament stable pour que Apple ait choisit de le mettre au coeur de son système, et contribu pas mal au passage. LLVM est une des brique éssentielle du fameux OpenCL.
Et si le développement de LLVM s'arrête? Ton idée est entièrement dépendante de ce produit. Tout autre gestionnaire de paquet marche avec n'importe quel compilateur.
Vu le projet il y a relativement peut de chance que le dévellopement s'arrete, mais même si c'était le cas, c'est du logiciel libre et il est possible de reprendre le dev.
Apparemment LLVM ne supporte vraiment que C et C++ pour l'instant
LLVM seul ne supporte absolument rien ;-)
C'est juste la spécification d'un code intermédiaire et tout un tas de bibliothèques et outils pour le manipuler et notament le copiler en code natif. Il y a pas mal de projet de compilateurs qui produisent ce code intermédiaire au lieu de produire directement du code natif.
C'est le cas par exemple de clang qui est un copilateur destiner à compiler du C ainsi que d'autre langage dérivés. Et pour CLang, en effet, il supporte actuellement très bien le C et produit du code très performant. L'objective-C est relativeent bien supporté, je sais pas le staus exacte mais là aussi c'est un truc ou apple contribue pas mal. Par contre pour le C++, pour l'instant c'est encore très expérimental et de nombreuse choses ne sont pas implémentée.
Par contre il existe aussi llvm-gcc qui est un bacend pour gcc. C'est-à-dire que c'est une modification de gcc qui lui permet de produire du code llvm au lieu de code pour un processeur. Donc ça permet d'avoir un copilateur qui supporte éxactement les même langages que gcc.
Et il y a différents autres compilos disponibles, même parfois pour des langages auquels on ne penserais as du style un compilateur pour lua.
Sinon une petite question: puisque LLVM est avant tout une VM, peut-être n'y aurait-il même pas besoin de compiler en langage machine les programmes chargés, non?
Comme tu le dis après, L'objectif de llvm c'est quand même de produire du code très performant, et les perfs du code interprété sont quand même pas térrible à côter de celle du binnaire. Et vu le coût du JIT autant ne pas s'en priver.
Et un dernier petit point pour l'auteur du journal. L'argument de ca prend moins de place est loin d'être pertinent, dans la grosse majoritée des pacquet, à mon avis, ce qui prend de la place c'est pas les binnaires mais les donnés. De plus les mesures sont à faire sur le code une foi compressé car à tous les formats de paquets que je connais compressent le tout.
Avant de penser à des optimisation sur la taille du code, il vaudrais mieux faire quelques stat pour savoir s'il y a quelque chose à gagner.
Voilà, j'éspère avoir clarifier quelques points sur llvm et le reste.