L'�quipe Visual C++ donne des d�tails sur certaines �tapes de la refonte du compilateur C/C++
L'�quipe Visual C++ donne des d�tails sur certaines �tapes de la refonte du compilateur C/C++,
et parle �galement de ses perspectives d'avenir
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
R�pondre avec citation
.
Partager