OK, let’s take enumeration. To test there are syntax, attributes, representation clause of (and in combination with 'Pred and other attributes), subtypes of, usage in array types, as discriminants including variant records, in loops, case statements. That is just from the top. ACATS covers probably, I guess, 1-2% of the total? So, I wondered if the framework you use were capable of more.
P.S. Character tests are quite interesting since there are subtle differences between Ada 83 and later standards. E.g. character literals.
You’re right : Ada 83 LRM 8.5(9) . Because an enumeration literal is equivalent to a function 3.5.1(3) renaming of an enumeration literal is possible under the title of subprogram renaming 8.5(2) (and not object renaming, an enumeration literal not being an object declared by object_declaration 3.2(2), 3.2(9)). So Ada 83/TLALOC sem_phase is ok when accepting this.
No, my “framework” is much more rudimentary and pragmatic. But your vision is interesting being tied to proving that the compiler compiles every possibility correctly and denies usage of forbidden constructs. I am not there but the question interests me also.
Nice step : all acvc a2 tests have been compiled by TLALOC, executed and passed (excepted the two TST using macrosub).
But bad news, fasmg will probably be unable to assemble the whole compiler (around 100 includes is too much for a multipass assembler, fasmg abdicates). It does not prevent developping the EXEC(1) compiler on “small” test programs though.
After some hard work, 16 tests of a8 acvc series have passed along with all tests of a2, a3, a5, a6, a7. All compiler modules itself are compiled also and a number of custom tests.
I am now confronted with a problem of development complexity. Taking acvc tests to guide the expander development is getting too expensive because it involves correction point by point as some languages services are not yet implemented. At first, the development was driven by implementing the predefined packages, but now they can be used and adding missing functionnalities is both less rewarding and more complicated.
I am thinking about the right method to efficiently progress in the expander development.
Hi !
I set up a methodology for the expander development with LRM centered “pillars” to implement. The acvc tests are no longer a development guide, only a control tool. A nice progress has been done on sections 3.6 and 3.7 .
Today I begin implementing the exceptions.
15th of July 2026 : the gnat compiled Ada 83/TLALOC compiler compiles all its own sources to fasmg macros LLIR in 17 seconds. Then fasmg assembles the 8.7 Mb ADA_COMP bootstrapped compiler in 148 seconds 19 passes,
The Ada 83/TLALOC loop is in place
Now debugging the new executable to produce the “dis_bonjour” with entirely TLALOC compiled TLALOC from Ada 83 source.
Alas… no, producing the compiler exec is not enough, it has to compile effectively and itself produce the next generation exec. Debugging ahead, but it is a very significant step, with a great amount of work below.
Hi.all !
just a few words of update. A great battle to bootstrap TLALOC. A small null_prog passes through PAR_PHASE in the TLALOC compiled TLALOC. In parallel with LRM pillars implementation, the bootstrap is debugged with a “fill the shouting holes” policy. That is every unimplemented feature is making noise through messaging and raise PROGRAM_ERROR. A listing mode allows for holes finding, and an update journal tracks every hole category to fill it with AI help. Reduction is in progress.
Fasmg does the job, in 18 passes but 2-3 minutes. Manageable.
@VMo you might want to get in contact with Justin Squarek (sp?) — the guy who has AdaDoom3 · GitHub — he’s working on an Ada83 compiler as well, and has gotten it to the point it’s passing some of the ACATS tests.
This is pretty interesting; it seems to be a single generated C file and RTS written in Ada that target LLVM 20. I’m not sure how much overlap they can have, since AdaDoom’s is pretty dense whereas @VMo’s is pretty readable, but useful in benchmarks and comparisons for sure.
Hi OneWingedShark !
63550 lines of C in a single 2.6Mb file How did he do that ? And add llvm behind.
I have so much pain with my ~100 Ada 83 files to insure it does what it is intended to do. And to have something maintainable which can be scrutinized…
Well I’ll try to have a look at it.
From what I understand, the development method of AdaDoom3/Ada83 is completely different from mine for TLALOC. The code seems entirely AI generated (repo changes very often) and maintenance of a single giant file without AI agents will be problematic. When I started TLALOC I wanted to have a human readable and maintainable compiler. I use AI modifications under my control with step by step copy/paste source blocs. So that I read what is done. Of course, I want to have an Ada 83 written compiler, and a mastered backend even if for now performance is not at a premium.
Indeed, and I appreciate this.
However, if the backend consumes DIANA, you should be able to swap out backends fairly easily. If you need to, that is.
And, another issue is that of bootstrapping: you don’t necessarily have to keep your backend as assembler. (There are pros and cons to ASM, as there are to other codegen techniques.)
How did he do that ? And add llvm behind.