My life with Ada 83

Ma vie avec Ada 83

Vincent MORIN

Maître de conférence
Université de Bretagne Occidentale (UBO)
Brest FRANCE

SYBILIN/CAVISO la capsule temporelle

Cette histoire commence vers 1985 alors que je commençais une thèse en électronique sous la direction du Pr. Pierre Jarry et la supervision de Mme Agnieska Konczykowska. Il s'agissait de travailler à l'amélioration d'un programme de simulation symbolique de circuits linéaires nommé SYBILIN et développé en FORTAN au CNET de Bagneux. Ce programme utilisait une méthode fort originale de calcul de la fonction de transfert d'un circuit à l'aide des graphes de Mason-Coates. Mais l'écriture en FORTRAN se montra un obstacle considérable à la compréhension et à la reprise du logiciel. Je fus ainsi confronté assez brutalement au problème de la reprise d'un logiciel écrit par quelqu'un d'autre dans un langage qui n'est pas célébré pour sa clarté.

Il se trouve que le service national venant couper ma thèse, je fis une année comme scientifique du contingent au Service Organisation et Méthodes Informatiques de la DCN Brest où parallèlement à la gestion des calculateurs DEC VAX je pris connaissance avec les nouveautés informatiques de la décennie 1980, dont le langage Ada original, celui que l'on appelle Ada 83 aujourd'hui pour le distinguer de ses évolutions Ada 95, Ada 2005, Ada 2012.

Au retour à ma thèse à en 1986, je proposai et obtins de travailler avec un compilateur Ada DEC sur un MicroVAX II pour développer une version beaucoup plus maintenable de SYBILIN. La thèse fut finalement passée en 1988 avec la réécriture de ce logiciel dont la version Ada 83 a une histoire peu commune.

L'ensemble du logiciel SYBILIN en Ada, que j'avais renommé CAVISO pour le distinguer de sa version FORTRAN, avait été imprimé sur l'imprimante laser du centre d'Issy les Moulineaux pour archivage et référence future éventuelle. Puis les occupations universitaires prenant le pas, le livre de listing tomba dans l'oubli.

Or vers 2024, faisant du rangement, je redécouvris dans une malette le dit listing, un livre agrafé relié et impeccablement conservé. Ayant entre temps acquis de l'expérience avec Ada et conservé une pratique du langage, je me demandai s'il serait possible de faire revivre CAVISO presque quarante ans après. Le listing laser étant de très belle qualité, le passage à l'OCR se fit sans problème et les fichiers Ada 83 de 1988 furent rétablis sous Linux. Ce fut une demi surprise, mais quarante années après, le code source Ada développé avec DEC Ada entre 1986 et 1988 se compila sans problème avec Gnat en 2024. A quatre décennies d'intervalle le logiciel Ada 83 avait conservé toute sa validité. Un beau témoignage de longévité.

L'aventure des OS KALINDA

Le système d'exploitation Mac OS du Macintosh Plus avait toujours suscité mon admiration, et la documentation papier complète des quatre volume Inside Macintosh m'était dans les années 1990-2000 quasiment un livre de chevet. Il me prit donc d'écrire un système très proche, nommé KALINDA, en Pascal Codewarrior sur LC III, puis sur PowerPC.

Cette version Pascal était fort avancée mais commença à devenir difficile à maintenir et à faire évoluer. Quand un jour Codewarrior Pascal s'éteignit le source Pascal non normalisé ne trouva plus de compilateur capable de traiter toutes les options et codes d'assemblage. Ainsi périt la première version de KALINDA.

Comme le langage C était en vogue, je me mis à rédiger une version C. Ca ne dura pas longtemps tant la maintenabilité était pire qu'avec Pascal. L'amorce de KALINDA C eut donc une vie très courte.

Enfin, je décidai d'utiliser Ada langage avec lequel j'avais gardé le contact et rédigé le système automatique de l'expérience DEVLUM pour la mise en évidence des déviations de lumière (second effet Allais). Mais dans au milieu des années 2000, Ada avait terriblement changé, il était devenu Ada 95. On pouvait faire beaucoup de nouvelles choses, mais la structure du logiciel avait de grandes possibilités de complication avec la programmation orientée objet, les types tagués, les child packages, etc.

J'entrepris donc la réécriture de KALINDA en Ada 95. Mais je m'aperçu progressivement qu'Ada 95 portait facilement à ce que je qualifierais de sorte de sur-conceptulisation. Le module MEMORY_MANAGER de KALINDA en particulier prit une forme trop compliquée, et la structure même de l'ensemble des modules de l'OS s'enchevêtra excessivement. Il y avait trop de possibilités trop compliquées. A l'évidence, Ada 95 apparaissait comme une déviation par rapport aux objectifs de Ada 83.

Tant et si bien que quelques années plus tard, je décidai de réécrire à nouveau KALINDA, en pur Ada 83 cette fois. Et les choses se passèrent en fait beaucoup mieux. Les contraintes de structure modulaire étant plus fortes dans leur simplicité, il fallut trouver des solutions qui s'avérèrent bien plus lisibles à long terme que ce qui avait été fait en Ada 95.

Les spécialistes des systèmes de haute fiabilité et temps réels ont certainement gagné sur certaines fonctionnalités avec Ada 9X et suivants, mais je maintiens que par expérience quelque chose a été perdu qui était très spécifique d'Ada 83 : une contrainte à l'implémentation que j'avais déjà bien ressentie en programmant CAVISO avec DEC Ada. C'est une caractéristique d'Ada 83 un peu difficile à exprimer clairement, qui se manifeste par certaines difficultés à trouver parfois la bonne solution au problème qu'on se propose de résoudre, mais qui fournit une fois trouvée une réalisation propre à une relecture et à une réappropriation du logiciel après des temps assez longs hors de la logique du programme.

De fait, la version Ada 83 de KALINDA est la seule dans laquelle je peux revenir après des mois sans difficulté à réintégrer la logique système du programme.

Une plaidoirie pour Ada 83

Au vu de ma propre expérience d'utilisateur d'Ada, il m'apparaît peu contestable que même quarante trois ans après sa normalisation, Ada 83 présente encore en 2026 un intérêt pour certains programmeurs.

J'ai pensé qu'il serait donc souhaitable que persiste, au minimum à titre d'archéologie informatique vivante un compilateur écrit en Ada 83 pour Ada 83 et respectant rigoureusement la norme MIL-STD-1815A de l'époque, dont on a vu qu'elle avait été pour CAVISO la condition de sa survie par delà quatre décennies.

Mais, plus que par simple souci de préservation, je reste convaincu que parmi tous les langages informatique, Ada 83 conserve un réel intérêt pratique à notre époque, et je dirais même qu'à mon avis certaines possibilités du tasking Ada 83 n'ont jamais vraiement été exploitées à la mesure de ce qu'elles offraient.

La folle aventure d'Ada 83 / TLALOC

Depuis environ 2008, j'avais repris, réécrit en bonne partie autour d'un nouveau type TREE, reconditionné les modules PAR_PHASE, LIB_PHASE, SEM_PHASE, etc. du traducteur DIANA de l'ASR trouvé sur un vieux CD-ROM de Pine Creek. Un projet dirigé par Bill Easton de Peregrine Systems avait implanté par pièces avec probablement quelques limitations de l'époque un système de gestion d'arbre DIANA sur pages virtuelles, un analyseur LALR1, une analyse sémantique validant l'arbre DIANA.

Pour avoir un compilateur complet à partir du reconditionnement des pièces, il fallait un "backend" pour produire du code exécutable à partir de l'arbre DIANA sémantiquement vérifié et complété. Comme il fallait se lancer seul dans l'aventure, une solution des plus simples mais assez sophistiquée pour produire une solution devait être trouvée.

La solution vint de l'utilisation de FASMG, un macro-assembleur générique tout à fait remarquable pourvu de possibilités de structuration par "namespace". Avec FASMG il était possible de générer directement du binaire dans un exécutable ELF statique à partir de macros décrivant les opérations d'une machine à pile comme celle que le projet polonais IIPS/ADA de Przemyslav Szmal à Gliwice avait tenté avec le A-Code, ou du genre utilisé par Ada-Ed. De fait très rapidement, malgré ma seule présence comme programmeur, il fut possible de générer un exécutable "dis_bonjour", l'incontournable "hello world", avec une amorce de TEXT_IO et une machine à pile en macros avec appels système Linux.

Mais ce n'était que le seuil de l'aventure. Il apparut vite que la dite aventure avait un caractère fou par l'étendue des caractéristiques de Ada 83. C'est là que l'IA apparut opportunément. En commençant par produire et compiler les packages prédéfinis, une structure de base put être posée "manuellement". Mais vérifier et étendre cette structure ne pouvait se faire seul. Je m'associai donc l'aide de Claude et ChatGPT avec lesquels pièce par pièce furent écrits, compilés et testés, d'abord les unités prédéfinies (spécialement le TEXT_IO indispensable au débogage et au test), puis des programmes de test de plus en plus compliqués et enfin tout le compilateur TLALOC lui même. Au jour d'aujourd'hui, bien que complètement compilé, le compilateur n'est pas opérationnel et fait l'objet d'un débogage systématique journalisé avec l'aide des agents LLM ; tout en gardant cependant la main et la compréhension du logiciel écrit, car il n'était pas question non plus de faire écrire par l'IA un système dont je ne comprendrais pas les ressorts.

Aujourd'hui TLALOC est une large amorce de compilateur capable de traiter des programmes déjà assez complexes. J'espère pouvoir le mener jusqu'à l'objectif du boostrap qui consiste à obtenir d'apès les sources un exécutable de compilateur viable à l'aide du compilateur obtenu sur les sources avec avec Gnat.

L'approche de la machine à pile avec exécution d'instructions générées en binaire par macros FASMG a montré que le portage sur un processeur de même tenue que le x86-64 était assez directe. Il suffit en effet de traduire en instructions machine spécifique chaque instruction LLIR de la machine à pile. Un test a été fait sur un Orange Pi 3B sous Linux et montré que le portage sur aarch-64 était faisable sans difficulté majeure. Un portage non encore testé sur RiscV-64 (cible Starfive) a déjà été écrit et j'ai bonne confiance dans le fait qu'il fonctionnera également.

BREST, le 2 août 2026.