Hier soir, Basile Starynkevitch (j'arrive à écrire son nom d'une seule traite maintenant ! :)  ) nous a présenté GCC, ou du moins sa partie propre à la compilation (nous n'avons donc pas abordé (ld, objcopy ou gdb, par exemple : nous n'avions qu'une heure trente !), dans le cadre d'une conférence libre pour Parinux (et l'APRIL aussi, si l'on veut). L'organisation, tant sociale que technique du projet, a été au coeur de cette descente dans les entrailles du compilateur libre le plus célèbre. Et ce qui tombe bien, c'est que Basile est passionné par la même chose que nous : l'embarqué !

J'insiste souvent dans mes slides de cours ou de conférence sur le fait que GCC est le pendant sous-estimé de "Linux Embarqué" : non seulement ce logiciel libre sous copyright de la FSF et de facto sous GPLv3 est utilisé dans tous les projets Linux existant (je ne vois pas quel projet ne le ferait pas, on peut supposer que ça existe, mais j'attends de voir...), mais en plus il fait partie intégrante depuis des années des SDK d'OS temps réels bien propriétaires, tel celui de VxWorks ! De fait, GCC n'étant soumis à aucune licence restrictive, on l'utilise partout au moins pour faire des tests. Aussi, si l'on a un compilateur propriétaire sur un projet (RVDS, ObjectAda, Intel Compiler, etc), la licence étant restrictive à un certain nombre d'utilisateurs, on voit les développeurs utiliser GCC en temps de développement, et n'utiliser que le compilateur propriétaire pour le logiciel à réellement embarqué.

Et encore : le compilateur propriétaire est une espèce en voie d'extinction. Qui a entendu récemment parler des compilos de Thomson ou de ST ? Avant, la mode était de créer un CPU et son compilateur associé ; avec le resserrement de l'offre des architectures (certaines puces Thomson ont disparu depuis quelques années, et le CNES fait appel à ses réserves pour équiper ses satellites !), et l'omni-présence de GCC grâce à son organisation permettant d'attaquer toutes sortes de matériels, il n'est plus rentable d'investir dans des compilateurs fermés. Pis encore : il est absolument évident qu'un "méta"-compilateur tel que GCC, capable d'avaler bien des langages, de compiler ou cross-compiler pour bien des architectures, avec une modularité, des options et des extensions de langage à un niveau jamais atteint ne sera jamais plus dépassé. Microsoft est encore le seul à lutter (et pourquoi pas Borland ?), mais il n'y a qu'à compiler du C++ un peu complexe pour se rendre compte que l'on est loin du niveau de GCC.

De fait, les équipes d'Intel ou AMD sont investies dans le projet, à présent. La collaboration de ces entreprises pourtant  concurrentes par nature est même exemplaire. Mais le succès de GCC serait encore bien supérieur à ce que j'imaginais. On m'a parlé de versions certifiées, en DO-178B, que ça, et un membre du public (ingénieur en informatique embarquée dans une grande société concernée) m'a même assuré que du code sur la ligne 13 était compilé par GCC (cependant, est-ce le navigateur ou les freins, ou est-ce l'éclairage clignotant de la loupiotte à l'approche d'une station ? Ce n'est pas pareil ! Dans l'absolu, il y a du code compilé par GCC dans les avions, il y a même du Linux dans les derniers, mais c'est pour du multimédia : quid du navigateur de bord ? Je doute toujours). J'essaierai de faire parler des contacts, mais ce n'est pas facile : la complexité des solutions actuelles, de leur organisation logistique, et le mutisme du milieu industriel, empêchent d'avoir une visibilité fiable et globale des utilisations des logiciels libres en général, et la question du compilateur employé reste définitivement délicate.

J'espère que les slides seront bientôt disponibles, la conférence était très intéressantes, et il semblerait qu'elle peut-être eu plus de succès que la mienne (cependant, je doute un peu, on va dire ex-aequo :)   ). Le sujet était pourtant fortement technique a priori, et les digressions dans les HIR et MIR internes à GCC en ont perdu quelques uns, qui ont tout de même été ravis d'en apprendre autant. Pour ma part, j'étais ravi de retrouver une application de mes vieux cours de compil (on sait qu'à l'EPITA le sujet majeur de première année est la conception d'un compilateur Tiger). A ce propos, j'ai partagé ma consternation avec Basile d'apprendre que les 4 millions de lignes de code de GCC sont écrites en C majoritairement (un peu de C++, ou de langages qui en génère comme celui de notre conférencier), et pas en Caml, ce qui aurait pu au moins diviser le nombre de lignes nécessaires par 100, sans compter la visibilité ; s'il est vrai que l'auto-compilation de GCC par lui-même est l'un des meilleurs tests qui soit, se serait en réalité une question de culture américaine de formation universitaire à la base de ce (non-)choix technique : dommage.

Terminons sur un mot très positif : GDB dans sa prochaine version aura la possibilité d'intégrer des scripts Python, de telle sorte que ce ne sera plus la peine de lutter avec des copies de lignes de commande pour mettre en place des registres, ou de mettre ses breaks à la main avant de les retirer pour les décaler etc (on se rappelle qu'avec un J-TAG, on n'a droit qu'à deux breakpoints/watchpoints hardware !), ou encore d'arrêter le code, dumper les registres et la pile, faire un step, etc, à la main, ce qui est très fastidieux pour le moment. On peut même rêver dès à présent à un équivalent de Time Machine de Greenhills, c'est-à-dire d'avoir la possibilité de jouer un retour en arrière dans l'exécution du code. Et ça, se serait une très grande nouvelle ! (qui ferait économiser 20.000€, hum... Mais il va falloir du temps)

Remercions encore une fois Basile Starynkevitch pour sa fort bonne prestation, et sa bonne humeur naturelle.