My Life with Ada 83
The Origins of the Ada 83 / TLALOC Compiler
Associate Professor
University of Western Brittany (UBO)
Brest, FRANCE
SYBILIN/CAVISO: The Time Capsule
This story begins around 1985, when I was starting a thesis in electronics under the direction of Prof. Pierre Jarry and the supervision of Ms. Agnieska Konczykowska. The goal was to work on improving a symbolic simulation program for linear circuits called SYBILIN, which had been developed in FORTRAN at the CNET in Bagneux. This program used a highly original method for calculating a circuit’s transfer function using Mason-Coates graphs. However, the fact that it was written in FORTRAN proved to be a considerable obstacle to understanding and taking over the software. I was thus confronted rather abruptly with the problem of taking over software written by someone else in a language not known for its clarity.
As it happened, my thesis was interrupted by mandatory military service, so I spent a year as a conscripted scientist in the Computer Organization and Methods Department at DCN Brest, where—in addition to managing DEC VAX computers—I became familiar with the new developments in computing during the 1980s, including the original Ada language, which is now called Ada 83 to distinguish it from its later versions, Ada 95, Ada 2005, and Ada 2012.
When I returned to my thesis in 1986, I proposed—and was granted permission—to work with a DEC Ada compiler on a MicroVAX II to develop a much more maintainable version of SYBILIN. I finally defended my thesis in 1988 with the rewrite of this software, whose Ada 83 version has an unusual history.
The entire SYBILIN software suite in Ada—which I had renamed CAVISO to distinguish it from its FORTRAN version—had been printed on the laser printer at the Issy-les-Moulineaux center for archiving and possible future reference. Then, as my academic commitments took precedence, the book of listings fell into oblivion.
However, around 2024, while tidying up, I rediscovered the aforementioned listing in a briefcase—a stapled, bound book in impeccable condition. Having since gained experience with Ada and remained proficient in the language, I wondered if it would be possible to revive CAVISO nearly forty years later. Since the laser-printed listing was of very high quality, the OCR process went smoothly, and the 1988 Ada 83 files were restored on Linux. It was somewhat of a surprise, but forty years later, the Ada source code developed with DEC Ada between 1986 and 1988 compiled without any issues using Gnat in 2024.
Four decades later, the Ada 83 software had retained all its validity. A fine testament to its longevity.
The KALINDA OS Adventure
I had always admired the Mac OS on the Macintosh Plus, and the comprehensive four-volume print series *Inside Macintosh* was practically my bedside book during the 1990s and 2000s. So I set out to write a very similar system, named KALINDA, in Codewarrior Pascal on the LC III, and later on PowerPC.
This Pascal version was quite advanced but began to become difficult to maintain and develop further. When Codewarrior Pascal was eventually discontinued, the non-standard Pascal source code could no longer find a compiler capable of handling all its options and assembly codes. Thus, the first version of KALINDA came to an end.
Since the C language was all the rage, I set out to write a C version. It didn’t last long, as maintainability was even worse than with Pascal. The initial KALINDA C project thus had a very short lifespan.
Finally, I decided to use Ada, a language I had stayed in touch with and used to write the automated system for the DEVLUM experiment to detect light deviations (the second Allais effect). But by the mid-2000s, Ada had changed dramatically; it had become Ada 95. You could do a lot of new things, but the software structure had the potential to become very complicated with object-oriented programming, tagged types, child packages, and so on.
So I set out to rewrite KALINDA in Ada 95. But I gradually realized that Ada 95 easily led to what I would call a kind of over-conceptualization. KALINDA’s MEMORY_MANAGER module, in particular, became too complicated, and the very structure of all the OS modules became excessively tangled. There were too many overly complicated possibilities. Clearly, Ada 95 seemed to be a departure from the goals of Ada 83.
So much so that a few years later, I decided to rewrite KALINDA once again, this time in pure Ada 83. And things actually went much better. Since the constraints of modular structure were stronger in their simplicity, I had to find solutions that proved to be much more readable in the long run than what had been done in Ada 95.
Specialists in high-reliability and real-time systems have certainly gained certain features with Ada 9X and later versions, but I maintain that, based on my experience, something very specific to Ada 83 has been lost: a constraint on implementation that I had already keenly felt while programming CAVISO with DEC Ada. This is a feature of Ada 83 that is somewhat difficult to articulate clearly; it sometimes makes it challenging to find the right solution to the problem at hand, but once found, it yields a solution that lends itself to revisiting and reengaging with the software after spending a considerable amount of time away from the program’s logic.
In fact, the Ada 83 version of KALINDA is the only one to which I can return after months away without any difficulty reintegrating myself into the program’s system logic.
A Plea for Ada 83
Based on my own experience as an Ada user, it seems to me beyond dispute that even forty-three years after its standardization, Ada 83 will still be of interest to certain programmers in 2026.
I therefore thought it would be desirable for a compiler written in Ada 83 for Ada 83—one that strictly adheres to the MIL-STD-1815A standard of the time, which, as we have seen, was the key to CAVISO’s survival over four decades—to continue to exist, at the very least as a form of living computer archaeology.
But, beyond a mere concern for preservation, I remain convinced that, among all computer languages, Ada 83 retains real practical value in our time, and I would even say that, in my opinion, certain capabilities of Ada 83 tasking have never truly been exploited to the full extent of their potential.
The Crazy Adventure of Ada 83 / TLALOC
Starting around 2008, I had resumed work on the ASR’s DIANA translator—which I found on an old Pine Creek CD-ROM—and had largely rewritten it around a new TREE type, while also revamping the PAR_PHASE, LIB_PHASE, SEM_PHASE, and other modules. A project led by Bill Easton of Peregrine Systems had implemented, piece by piece—and likely with some limitations of the time—a DIANA tree management system on virtual pages, an LALR1 parser, and a semantic analyzer that validated the DIANA tree.
To create a complete compiler by reassembling these components, a “backend” was needed to generate executable code from the semantically verified and completed DIANA tree. Since I had to embark on this adventure alone, a solution that was as simple as possible yet sophisticated enough to produce the desired result had to be found.
The solution came from using FASMG, a truly remarkable generic macro-assembler equipped with “namespace” structuring capabilities. With FASMG, it was possible to directly generate binary code into a static ELF executable from macros describing the operations of a stack-based machine—similar to the one attempted by Przemyslav Szmal’s Polish IIPS/ADA project in Gliwice with A-Code, or the type used by Ada-Ed.
In fact, very quickly—even though I was the only programmer—we were able to generate a “dis_bonjour” executable, the classic “hello world,” using a TEXT_IO initializer and a stack-based machine implemented in macros with Linux system calls.
But that was just the beginning of the adventure. It soon became clear that this adventure was a bit of a wild ride, given the sheer scope of Ada 83’s features. That’s when AI came in handy. Starting by generating and compiling the predefined packages, a basic structure could be set up “manually.” But verifying and expanding this structure could not be done alone. So I enlisted the help of Claude and ChatGPT, with whom—piece by piece—we wrote, compiled, and tested first the predefined units (especially TEXT_IO, which is essential for debugging and testing), then increasingly complex test programs, and finally the entire TLALOC compiler itself. As of today, although fully compiled, the compiler is not yet operational and is undergoing systematic, logged debugging with the help of LLM agents; however, I retain control over and a full understanding of the written software, as there was no question of having the AI write a system whose inner workings I would not understand.
Today, TLALOC is a comprehensive Ada 83 compiler front-end capable of handling programs that are already quite complex. I hope to be able to take it all the way to the bootstrap goal, which is to generate a working compiler executable from the Ada 83 source code using the compiler previously built from the source code with Gnat.
The stack machine approach, which executes instructions generated in binary form by FASMG macros, has shown that porting to a processor comparable to x86-64 is fairly straightforward. In fact, all that is required is to translate each LLIR instruction of the stack machine into specific machine instructions. System calls remain the same as long as we stay within the Linux environment. This translation can now be largely automated.
In fact, a test was conducted on an Orange Pi 3B running Linux, and although it is no longer up to date (development is now being done on Intel x86-64), it demonstrated at the time that porting to aarch-64 was feasible without major difficulties. A port that has not yet been tested on RISC-V-64 (Starfive target) has already been written, and I am confident that it will work as well.
BREST, August 2, 2026.
Ma vie avec Ada 83
l'origine du compilateur Ada 83 / TLALOC
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-conceptualisation. 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 Ada 83 capable de traiter des programmes déjà assez complexes. J'espère pouvoir le mener jusqu'à l'objectif du bootstrap qui consiste à obtenir d'après les sources Ada 83 un exécutable de compilateur viable à l'aide du compilateur préalablement obtenu sur les sources 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écifiques chaque instruction LLIR de la machine à pile. Les appels systèmes sont les mêmes tant que l'on reste sous Linux. Cette traduction peut aujourd'hui être largement automatisée.
Un test a d'ailleurs été fait sur un Orange Pi 3B sous Linux et bien qu'il ne soit plus à jour (la version de développement se fait sur Intel x86-64), il a à l'époque 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.