Jim Springfield, architecte logiciel sur Visual C++ et employé chez Microsoft, a récemment reconnu dans un billet de blog que le compilateur C/C++ de Microsoft est maintenant vieux. Selon lui, il existe dans le code source de ce dernier des commentaires qui date de 1982, lorsque Microsoft commençait tout juste à travailler sur son propre projet de compilateur C. Les commentaires effectués par Ralph Ryan l'auraient conduit à lire un document publié par ce dernier en 1985 et intitulé « Le langage de programmation C et un compilateur C ». Pour Jim Springfield, cet ouvrage est très intéressant à lire et certaines choses qui y sont décrites se reflètent encore dans les codes d'aujourd'hui. En effet, l'ouvrage aurait mentionné qu'il est possible de compiler des programmes C avec deux disquettes et 192 K de RAM (bien qu'il recommande un disque dur et 256 K de RAM).
Pour Jim, être capable de fonctionner dans cet environnement signifie que vous ne pouviez pas garder beaucoup de travail dans la mémoire à la fois. Le compilateur a été conçu pour analyser les programmes et convertir les états et les expressions à l'IL (language intermediare) aussi rapidement que possible et de les écrire sur le disque, sans jamais garder une fonction entière en mémoire. En fait, le compilateur commencera à émettre l'IL pour une expression avant même de voir la fin de cette dernière. Cela signifie que vous pouvez compiler des programmes qui étaient assez grands sur une jolie petite machine.
Jim Springfield a également écrit ceci : « Notre compilateur se compose de deux pièces (un front-end et un back-end). Le front-end lit le code source, fait l'analyse sémantique et émet l'IL. Le back-end lit l'IL puis effectue la génération et l'optimisation du code. L'utilisation du terme « compilateur » dans le reste de cet article ne concerne que le front-end. »
Jim, poursuivant ses explications, affirme que pour le code C (surtout K&R C), cette approche a bien fonctionné. Rappelez-vous, vous n'avez même pas besoin d'avoir des prototypes pour les fonctions. Microsoft a ajouté le support pour C++ dans C 7.0 qui a été libéré en 1992 ; ce dernier a partagé une grande partie du même code avec le compilateur C et cela est encore vrai aujourd'hui. Bien que le compilateur ait deux binaires différends (C1.dll et C1xx.dll) pour C et C++, il y a beaucoup de codes sources qui sont partagés entre eux.
L'ingénieur informaticien souligne que cela fait maintenant environ trois ans, que Microsoft a lancé un projet pour finalement effectuer une révision majeure du code source de son compilateur. Cela afin de changer la façon dont le compilateur analyse les codes tout en résolvant également les problèmes rencontrés dans le passé. Il fallait également adopter une nouvelle approche pour les fonctionnalités telles que constexpr . Cela dit, nous avons rapidement décidé d'adopter quelques principes clés pour guider notre développement. Le principe le plus important est que tous les travaux de refonte que nous faisons seront intégrés dans la même branche de développement que les fonctionnalités.
La première phase de ce travail a finalement été effectuée dans Visual Studio 2015. Nous avons effectué plusieurs changements dans l'implémentation du compilateur, mais beaucoup d'entre eux ne sont pas directement visibles. Le changement le plus visible est que les binaires c1ast.dll et c1xxast.dll ne sont plus présents. Nous essayons maintenant de faire en sorte que toute compilation pour une analyse statique utilise le même binaire que celui que utilisé pour la génération de code. Tous les blocs 6000 + #if ont disparu, et il y a moins de 200 contrôles d'exécution pour l'analyse. Ces grands changements ont entraîné la désactivation de l'analyse du code dans une partie de la Release Candidate (RC) du compilateur C++.
Springfield précise que maintenant, un arbre complet est généré pour les fonctions. Il peut utiliser la même structure de données pour générer du code ou effectuer une analyse statique. « Ces mêmes arbres sont utilisés pour évaluer les fonctions de constexpr. Nous suivons également plein d'informations afin de pouvoir fournir de meilleurs diagnostics à l'avenir. »
Selon Jim Springfield, avec tous ces changements, l'équipe s'efforce d'assurer une grande compatibilité tout en fixant les bogues réels en intégrant de nouvelles fonctionnalités au compilateur. Il affirme l'existence d'un système automatisé appelé Gauntlet qui se compose de plus de 50 machines qui construisent toutes les versions du compilateur et exécutent de nombreux tests dans toutes les saveurs notamment 32 bits, 64 bits, et les architectures ARM. Toutes les modifications doivent passer par Gauntlet avant d'être vérifiées.
Pour finir, Jim Springfield déclare : « Pour l'avenir, nous continuons à investir dans l'amélioration de notre compilateur. Nous avons commencé à travailler sur l'analyse des modèles dans un AST (arbre de syntaxe abstraite) et cela donnera quelques améliorations immédiates. Nous allons continuer à investir dans l'amélioration de notre compilateur avec comme objectif de le rendre pleinement conforme aux normes. Cela dit, nous sommes également très intéressés à apporter notre soutien à Clang . En cela, il y a une présentation au CppCon sur l'utilisation du frontal Clang avec notre générateur de code et un optimiseur ».
Pour rappel, Clang est un compilateur pour les langages de programmation C, C++ et Objective-C.
Source : blog msdn
Et vous ?
Qu'en pensez-vous ?
Voir aussi :
Forum Microsoft Visual Studio Forum Microsoft Visual C++ (.net) Forum C++ 
.
