- De grandes optimisations de performances ont été ajoutées, et QBE 1.3 atteint plus de 63 % des performances d’un compilateur commercial sur le coremark vanilla, avec une amélioration de 33 % sur la suite de tests Hare par rapport à qbe-1.2
- QBE 1.3 est la plus grosse release depuis la 1.0, avec environ 7k lignes ajoutées et 1,5k lignes supprimées
- Les nouvelles optimisations incluent GVN/GCM, des optimisations de boucle, l’élimination de
if, la simplification du CFG, etc., mais seuls certains passes éprouvés ont été conservés - L’inlining a été exclu de cet ensemble d’optimisations, car il s’accorde mal avec le modèle de compilation en flux par fonction de QBE
- Sur une variante de coremark où
ee_isdigitest inline etcrcu8remplacé par une implémentation plus simple sans branchement, QBE atteint l’objectif visé de 70 % des performances degcc -O2 - Le nouvel outil OCaml
mgencompile des motifs d’IL de style lispy en code C de correspondance, ce qui permet de remplacer ou de simplifier la logique existante de sélection d’instructions écrite à la main mgenrepère les motifs d’IL dans des blocs de commentaires spéciaux et insère du code C juste en dessous ; un exemple d’utilisation actuel se trouve dansisel.c- La correspondance sur DAG d’instructions suit une approche de numérotation similaire à celle du compilateur C Plan9 de Ken Thompson, et génère aussi un matcher en bytecode simple interprété par
runmatch() - La prise en charge de l’ABI Windows a été ajoutée : en passant
-t amd64_win, il devient possible de compiler pour une cible Windows - L’assembleur généré par QBE reste en syntaxe AT&T, et il est indiqué qu’une compilation avec l’assembleur mingw est appropriée
- La prise en charge du code indépendant de la position a été améliorée, permettant sur la plupart des cibles un linkage plus fluide avec des objets partagés ainsi que la création d’objets partagés
- Un nouveau drapeau
externpour constantes dynamiques (DYNCONST) permet de représenter au niveau IL l’accès indirect à des symboles globaux, comme les variables de bibliothèques dynamiques
1 commentaires
Avis sur Lobste.rs
Je travaille depuis longtemps, comme projet de loisir, sur un petit OS de style TRIPOS/Amiga Exec
Il n’a pas de protection mémoire, utilise une carte mémoire plate, et le passage de messages revient essentiellement à se passer des pointeurs
Pour auto-héberger un tel système, il est bien plus pratique d’avoir un petit compilateur capable de produire du PIE/PIC. Les bibliothèques de style Amiga doivent naturellement être en PIC, et c’est aussi appréciable de ne pas avoir à faire beaucoup de patchs au chargement quand on place l’exécutable quelque part dans la carte mémoire partagée
GCC et Clang peuvent le faire, mais ils sont beaucoup trop gros. La dernière fois que j’ai vérifié, TCC ne savait pas faire de PIC, donc il faudrait que je regarde QBE de plus près
J’espère que ça ne sonne pas comme de l’auto-promo. J’adore vraiment le domaine des petits compilateurs, et il lui faut encore davantage de tests
C’est déjà assez avancé, et ça prend en charge plusieurs plateformes
En revanche, atteindre l’auto-hébergement bientôt semble difficile. Il me faut une génération de code Thumb-2, et en pratique la seule façon de l’obtenir est d’écrire moi-même un compilateur. Il y a aussi la contrainte de n’avoir que 8 Mo de RAM utilisables en dehors du code du noyau
J’utilise un format d’exécutable maison,
.ashex, produit par conversion de fichiers ELF. Dans ce processus, je consomme une section spéciale qui est en fait un unique saut absolu, puis le chargeur d’applications la réécrit avec l’adresse réelle de l’appel systèmeLa difficulté des systèmes à mémoire plate, c’est de prendre proprement en charge les objets partagés. Pour partager du code entre différentes applications, il faut le support du compilateur afin que tous les accès aux symboles dynamiques passent par des variables stockées dans des registres
Je suis vraiment ravi de voir le nouveau mot-clé
externCe n’est pas mentionné dans les notes de version, mais il fonctionne aussi avec
thread, ce qui permet l’initial-exec TLS. C’est nécessaire pour accéder à des variables globales locales au thread définies dans d’autres bibliothèques partagées, et c’est requis par lectype.hde FreeBSDexternest aussi nécessaire sur des plateformes comme macOS ou Haiku pour accéder aux variables globales ordinaires des bibliothèques partagées, par exemplestderr. Les compilateurs basés sur QBE peuvent désormais prendre en charge bien plus de systèmes d’exploitation et de cas d’usageUn grand merci aussi à Roland pour les améliorations de performances. C’est vraiment un excellent travail
Si j’ai bien lu, est-ce que cela signifie qu’il y a maintenant une prise en charge officielle de Windows ?
Ce n’était pas l’une des grandes limitations historiques de QBE, encore présente jusqu’à maintenant ? C’est vraiment agréable à voir
Est-ce que l’objectif de ce projet recoupe celui de Cranelift ? J’ai du mal à voir dans quels cas on utiliserait QBE
Ses concurrents sont en réalité Cranelift et LLVM
Malheureusement, par le passé, il a surtout été utilisé dans des langages ou implémentations de compilateurs de loisir. Par exemple, myrddin, qui ressemblait à un nouveau langage de la famille C, semble maintenant mort, et cproc reste une implémentation vivante de compilateur C de loisir
Cela dit, depuis que Hare a adopté QBE, il y a de quoi être optimiste. La réponse à la question se trouve ici : https://harelang.org/documentation/faq.html#why-qbe-instead-of-llvm
Je ne connais pas le sujet en détail, mais il existe beaucoup de comparatifs. De ce que j’en sais, QBE vise un backend beaucoup plus simple que les deux autres
J’aime beaucoup l’idée d’utiliser une petite DSL pour générer le sélecteur d’instructions