# Ada 83 TLALOC on arm AARCH64 v8
**URL:** https://forum.ada-lang.io/t/ada-83-tlaloc-on-arm-aarch64-v8/4387
**Category:** TLALOC
**Created:** [May 3, 2026, 11:08am UTC](https://forum.ada-lang.io/t/ada-83-tlaloc-on-arm-aarch64-v8/4387 "2026-05-03T11:08:19Z")
**Posts on this page:** 18
**Page:** 1
### Author:  [@VMo](https://forum.ada-lang.io/u/VMo)
#### Post date: [May 3, 2026, 11:08am UTC](https://forum.ada-lang.io/t/ada-83-tlaloc-on-arm-aarch64-v8/4387/1 "2026-05-03T11:08:20Z")
Hello to all !
Pleased to inform interested Ada 83 fans that the TLALOC/Ada 83 compiler compiles for AARCH64 !
To test the validity of the TLALOC pure Ada 83 compiler backend architecture, I ported the codi\_x86\_64.finc macros to arm on Orange Pi3/Armbian. With the codi\_arm64.finc file replacing the intel/linux version all present tests work. Only one day work with Claude AI. Only the binary emission of the same macros, so that nothing changes in the compiler, even LLIR finc files compiled for x86 can be reused for arm64.
As soon as possible I test bare metal porting on RISV-V. This will be more complicated.
Commits on Github ( [GitHub - ViMoBr/Ada-83-TLALOC · GitHub](https://github.com/ViMoBr/Ada83_TLALOC) ) and Framagit, see the codi\_arm64.finc file in src/expander/fasmg
---
### Author:  [@BojanBozovic](https://forum.ada-lang.io/u/BojanBozovic)
#### Post date: [May 3, 2026, 2:01pm UTC](https://forum.ada-lang.io/t/ada-83-tlaloc-on-arm-aarch64-v8/4387/2 "2026-05-03T14:01:32Z")
That’s great! But please consider runtime library to be under GPL3 licence with Runtime exception (or GMGPL if you prefer GPL2), so that the compiler can be used for a commercial project. Compiler itself can be GPL. That’s license of FSF GNAT compiler.
Best regards!
---
### Author:  [@Lucretia](https://forum.ada-lang.io/u/Lucretia)
#### Post date: [May 3, 2026, 3:03pm UTC](https://forum.ada-lang.io/t/ada-83-tlaloc-on-arm-aarch64-v8/4387/3 "2026-05-03T15:03:25Z")
Yeah, doesn’t mean it should go under the GPL. The GPL is a good way to stop people using it.
---
### Author:  [@ZenitDS](https://forum.ada-lang.io/u/ZenitDS)
#### Post date: [May 3, 2026, 6:10pm UTC](https://forum.ada-lang.io/t/ada-83-tlaloc-on-arm-aarch64-v8/4387/4 "2026-05-03T18:10:21Z")
Hello Victor,
If I am not mistaken, your repo does not provide a `LICENSE` or similar.
In that case @VMo maybe you would like to consider adding a license so that people can contribute to your project. I don’t know, maybe there are some issues with licensing from the original work?
Cheers
– zen
---
### Author:  [@BojanBozovic](https://forum.ada-lang.io/u/BojanBozovic)
#### Post date: [May 3, 2026, 6:32pm UTC](https://forum.ada-lang.io/t/ada-83-tlaloc-on-arm-aarch64-v8/4387/5 "2026-05-03T18:32:12Z")
I have taken look at the source files, license is GPL
---
### Author:  [@joakim-strandberg](https://forum.ada-lang.io/u/joakim-strandberg)
#### Post date: [May 3, 2026, 8:44pm UTC](https://forum.ada-lang.io/t/ada-83-tlaloc-on-arm-aarch64-v8/4387/6 "2026-05-03T20:44:03Z")
Hi,
Nice work on the Ada83 compiler.
I have followed the instructions:
Clone the repository
git clone [GitHub - ViMoBr/Ada83\_TLALOC · GitHub](https://github.com/ViMoBr/Ada83_TLALOC.git)
cd Ada83\_TLALOC
Recompile the compiler
make\_ada\_comp.sh
Before being able to execute make\_ada\_comp.sh I had to create the build directory “mkdir build”. Something to add to the documentation?
The time to build the compiler was very quick, 1 or 2 seconds.
When using the a83.sh script for making FASM source code out of Ada code, the second input parameter is the path to the Ada source file relative to the directory pointed out in the first input parameter. I thought both were absolute paths and it took me a while to figure out that the second path is relative to the first. Perhaps also something to improve in the documentation?
It says on the compiler README.TXT that generics are supported. Both of these generic declarations fail to compile:
generic
type Element\_Type is limited private;
type Index\_Type is range \<\>;
type Element\_Array is array (Index\_Type range \<\>) of Element\_Type;
with procedure Use\_Element (Element : in out Element\_Array);
procedure Cca\_Allocate\_Array (Last : Index\_Type);
and
generic
type Element\_Type is limited private;
with procedure Use\_Element (Element : in out Element\_Type);
procedure Cca\_Allocate\_Single\_Item;
The error message is: raised PROGRAM\_ERROR : idl.adb:351 explicit raise
I hope this initial feedback on using the compiler is useful.
---
### Author:  [@VMo](https://forum.ada-lang.io/u/VMo)
#### Post date: [May 4, 2026, 5:47pm UTC](https://forum.ada-lang.io/t/ada-83-tlaloc-on-arm-aarch64-v8/4387/7 "2026-05-04T17:47:38Z")
Thank you for looking at the thing. What would be the most appropriate choice of licence to encourage participation, also taking into account that it is desirable that further developments should remain accessible to the community as a teaching and historical research tool ?
---
### Author:  [@VMo](https://forum.ada-lang.io/u/VMo)
#### Post date: [May 4, 2026, 6:17pm UTC](https://forum.ada-lang.io/t/ada-83-tlaloc-on-arm-aarch64-v8/4387/8 "2026-05-04T18:17:14Z")
Thank you for your return, it is very valuable because such details have gone out of my sight being used to my established environment and procedures. I’ll try to improve.The error you mentioned was from the expander(option C or W) and is corrected. Generally the .finc file contains the reason of the program\_error (the DN\_PROCEDURE\_SPEC was treated as DN\_PACKAGE\_SPEC). There is still a lot of work to obtain a decent expander, but the whole front end works gives satisfaction and the LLIR machine is retargetable with reasonable simplicity. Now your two specifications pass through the expander (but they produce no code).
---
### Author:  [@ZenitDS](https://forum.ada-lang.io/u/ZenitDS)
#### Post date: [May 5, 2026, 10:42am UTC](https://forum.ada-lang.io/t/ada-83-tlaloc-on-arm-aarch64-v8/4387/9 "2026-05-05T10:42:21Z")
Hi, it is on you what license you want to apply to your work. Your choice should depend on your preference more than anything else.
> Of course you must respect in all moments the terms posed by the original license. However, this may get a bit tricky if the original code had no license attached, in which case it is probably technically proprietary.
Rather than give you my take on this matter, I recommend that you check the following page, which summarizes most points.
> **[Choose an open source license](https://choosealicense.com/)**
>
> Non-judgmental guidance on choosing a license for your open source project
Here you have an explanation of the problem with **not** offering a license. (In spite of what it says that you may not license your work and accept contributions, probably nobody will contribute to the project, as it is close to working without getting paid).
> **[No License](https://choosealicense.com/no-permission/)**
>
> You’re under no obligation to choose a license and it’s your right not to include one with your code or project. But please note that opting out of open source licenses doesn’t mean you’re opting out of copyright law.
As I sidenote, I will mention that the whole copyright world is a universe of madness in which we must live given how things are, so dont get discouraged if you get a bit confused at first.
You may also look at the OSI (Open Source Initiative) webpage to get even more confused 😃
> **[Open Source Initiative - Open Source Initiative](https://opensource.org/)**
>
> Growing the impact of Open Source around the world The Open Source Initiative is the global nonprofit building the future powered by open collaboration, transparency and innovation. Supported by the...
---
### Author:  [@Britt](https://forum.ada-lang.io/u/Britt)
#### Post date: [May 5, 2026, 4:25pm UTC](https://forum.ada-lang.io/t/ada-83-tlaloc-on-arm-aarch64-v8/4387/10 "2026-05-05T16:25:22Z")
I also prefer that compilers be licensed like GCC (including GNAT): GPL with the GCC Runtime exception: [https://www.gnu.org/licenses/gpl-3.0.en.html](https://www.gnu.org/licenses/gpl-3.0.en.html) & [https://www.gnu.org/licenses/gcc-exception-3.1.en.html](https://www.gnu.org/licenses/gcc-exception-3.1.en.html)
The runtime exception is critical. Some potential users may avoid because of GPL but I think that is because they misunderstand it.
---
### Author:  [@ZenitDS](https://forum.ada-lang.io/u/ZenitDS)
#### Post date: [May 5, 2026, 7:19pm UTC](https://forum.ada-lang.io/t/ada-83-tlaloc-on-arm-aarch64-v8/4387/11 "2026-05-05T19:19:50Z")
Could you expand on the misunderstanding?
Mi reasoning goes as follows: if I want to release some piece of software to the public domain or even with the MIT license, if I use GPL-licensed code, my code cannot be used however someone sees fit without removing the GPL code. If the GPL code was removed, it would make the software not work until a replacement is coded.
---
### Author:  [@VMo](https://forum.ada-lang.io/u/VMo)
#### Post date: [May 6, 2026, 6:56am UTC](https://forum.ada-lang.io/t/ada-83-tlaloc-on-arm-aarch64-v8/4387/12 "2026-05-06T06:56:28Z")
Would this licence proposition for TLALOC Ada 83 be accepted by most of us :
```ada
TLALOC/Ada 83 is distributed under GPL-3.0-or-later.
Using the compiler to compile Ada 83 programs does not impose any particular
license on the compiled programs.
The runtime libraries, support units, generated files, or fragments that may be
incorporated into the produced programs are distributed under GPL-3.0-or-later
with the GCC Runtime Library Exception 3.1, or under an explicitly compatible
weak copyleft license suitable for this use.
```
I give great importance to possible verification of code output and compilation chain trust. Compiler Ada 83 source code entirely visible, fasmg text also open to examination and verification. The only binary produced is by db or dd fasmg directives from fasmg macros in .finc and .fas LLIR text. The last weak link is fasmg itself whose executable must be assured to only insert db or dd data and nothing else.
- reproducible builds;
- documented bootstrap chain;
- public regression tests;
- no non-regenerable binary blobs;
- mandatory review process for changes affecting the code generator;
- SPDX markings in every file;
- a LICENSES/ directory compliant with REUSE.
---
### Author:  [@BojanBozovic](https://forum.ada-lang.io/u/BojanBozovic)
#### Post date: [May 6, 2026, 12:33pm UTC](https://forum.ada-lang.io/t/ada-83-tlaloc-on-arm-aarch64-v8/4387/13 "2026-05-06T12:33:43Z")
In my humble opinion, it’s a good license for a compiler that doesn’t impose license on compiled programs. And there are some compilers that tried to impose license on compiled programs (such as OpenWatcom) but they practically died out.
Best regards.
---
### Author:  [@VMo](https://forum.ada-lang.io/u/VMo)
#### Post date: [May 6, 2026, 1:50pm UTC](https://forum.ada-lang.io/t/ada-83-tlaloc-on-arm-aarch64-v8/4387/14 "2026-05-06T13:50:33Z")
Of course, users of the TLALOC Ada 83 compiler program can write their own Ada 83 programs and do whatever they want with those programs. It is only the compiler which is protected against source hiding and captation, the idea being that the compiler itself it is a common and open asset whose open improvements benefit everyone.
---
### Author:  [@VMo](https://forum.ada-lang.io/u/VMo)
#### Post date: [May 6, 2026, 3:47pm UTC](https://forum.ada-lang.io/t/ada-83-tlaloc-on-arm-aarch64-v8/4387/15 "2026-05-06T15:47:55Z")
Hi Joakim !
Just for information, did you compile the DIS\_BONJOUR test ?
You mentioned you tried “complicated” generics, but did you try with success a simple procedure ?
I try to progress in the development by solving implementation problems for TEXT\_IO, DIRECT\_IO and so on step by step. So generic support is in a very early stage just enough for the simple predefined generics ; even this posed at first some serious problems. If somebody else successfully produces an ELF, this will at least validate a simple compilation process outside of my environment. Now, with the option letter lower ‘w’ or stopping at semantic analysis with ‘M’ letter option, complicated Ada 83 constructs are translated to DIANA (provided the compilation order is manually managed though), it is the EXPANDER which is in development is incomplete and throws errors which are visible in the .finc file and can be debugged with GDB on ada\_comp executable. Also, debugging the fasmg macro text produced by the expander is “relatively” easy because a db 0xCC interrupt can be text inserted in the finc file which is assembled into ELF by famsg, the binary being then observed at stop point with GDB (lay asm, lay reg, run, x/, watch…). What is interesting with TLALOC/Ada 83 is that everything can be scrutinized, and the compiler structure is very clean compared with most other compilers. For example, I tried to have a look at Free Pascal ; I found it has a complicated and intricate structure. The main complicated element in TLALOC is the DIANA representation. I had some hard time with DIANA.
---
### Author:  [@joakim-strandberg](https://forum.ada-lang.io/u/joakim-strandberg)
#### Post date: [May 6, 2026, 7:53pm UTC](https://forum.ada-lang.io/t/ada-83-tlaloc-on-arm-aarch64-v8/4387/16 "2026-05-06T19:53:20Z")
Hi Vincent!
Yes, I successfully compile dis\_bonjour.adb file and used fasmg in the ADA\_\_LIB directory to create an x86 64-bit elf linux executable.
Where does fasmg come from in the ADA\_\_LIB directory?
Among other reflections I can see in the source code for the Ada83 TLALOC compiler code is consistent with the naming convention in the Ada83 RM. One detail which seems less Ada83 like is the convention of the compiler to expect only one compilation unit in each file. This is the convention of the GNAT compiler. The Meridian Ada compiler, Janus / Ada compiler and ObjectAda compilers accept multiple compilation units in one file. Or maybe I misunderstood how the compiler is intended to work? I tried to compile a file with two compilation units and the Ada83 TLALOC compiler reported an error message.
What is the coding convention used for the Ada compiler code? I can see tabs being used in the code. Should one set number of spaces used for a tab in the editor one uses to view the source code files in the right way? I have tried codium, notepad++ and vim, and I am still not sure I see the code as it should be viewed. Is the coding convention used the Ada 83 Quality and Style guide? If some special coding convention is used, it would be good to document it. Is the usage of tabs inheritance from older code? In the projects I have worked with, only space symbols have been allowed, no tab symbols. If I remember correctly, the tradition in GNAT Studio is to “format code” when pressing tab. Perhaps tabs where more popular during the 1980’s and the source code honors this convention?
Something that is modern in the code is the usage of UTF-8 for the source code files. I guess the Ada code itself is ASCII but the language used in the comments – is where UTF-8 is used?
There is lots of interesting documentation related to the compiler design to be found in the /doc directory.
I understand the generic support is in early stages but you have made good progress on TEXT\_IO and DIRECT\_IO.
> What is interesting with TLALOC/Ada 83 is that everything can be scrutinized, and the compiler structure is very clean compared with most other compilers.
Sounds good! Looking forward to study the code more.
> The main complicated element in TLALOC is the DIANA representation.
Ok, I still haven’t looked into DIANA yet.
---
### Author:  [@VMo](https://forum.ada-lang.io/u/VMo)
#### Post date: [May 7, 2026, 7:26am UTC](https://forum.ada-lang.io/t/ada-83-tlaloc-on-arm-aarch64-v8/4387/17 "2026-05-07T07:26:25Z")
1.
> [@joakim-strandberg](#):
>
> Yes, I successfully compile dis\_bonjour.adb file and used fasmg in the ADA\_\_LIB directory to create an x86 64-bit elf linux executable.
Very good ! you are the first to have said you have done it.
> [@joakim-strandberg](#):
>
> Where does fasmg come from in the ADA\_\_LIB directory?
1. The fasmg executable is in the ADA\_\_LIB directory, it is not ideal as organization, but it does the job for development.
2. The compiler does take multiple units in the same text file provided they are in a consistent partial compilation order. There was an init bug I corrected yesterday on DN\_NBR\_PAGES “not integer” this is when an attribute field has no initialization (in IDL.PAR\_PHASE.SET\_DLFT or IDL.SEM\_PHASE.MAKE\_NOD). There is a small example I tested yesterday evening (multi\_units.ada which produces PACK\_1.DCL, PACK\_1.BDY, PACK\_1.finc, MAIN\_PROG.DCL and MAIN\_PROG.finc). I did not even remember it was the case because the whole file approach is only useful for distribution and so not often used, for development one unit per text file is more logical and practical.
3. The style I adopted tries to reduce text file bytesize (crucial for the long term saving utility in directory ./src/tools), while allowing airy writing and programmer layout style freedom. I thus use extensively 10 characters size tabs. I use Kate editor, and sometimes JGrasp with size 10 tabs in preferences. 8 characters tabs are more common but not so practical for counting. Indentation is 2 white spaces.
4. Source code characters are supposed to be one byte only. This also is important for long term saving where TLALOC source code compacity it at a premium (long term graphic block saving utility in Tools can print the whole ~2Mb source code on 5 A4 paper sides. The idea is inspired from Rosetta project). In Ada 83, 7 bits characters are enough, but the current technology adopted universally 8 bits bytes. So the basic character set in TLALOC source code is pure ASCII and possible one byte set is for example Latin-1 8859 for extra accented characters. I do not want to use multi bytes characters in the compiler, because the simplicity and compacity is desired. I even try to forget french accents when writing (to minimize the necessary number of graphic symbols used in letter block printing, a first long term archival alternative not so compact as the second bit printing of quadwords).
5. For DIANA, ./doc/DIANA\_NODE.odt lists all nodes with attribute fields. In .bin/idl\_tools there are diana\_CLASS.txt, diana\_NODE\_.txt and diana\_NODES.txt. All of which are extracted from the reference text file ./idl/diana.idl . Sub-programs for using the DIANA structure are in IDL package (idl.ads) . The expander only uses it and DIANA\_NODE\_ATTR\_CLASS\_NAMES. Sub-programs use is not complicated, but the DIANA data structure is relatively complex. If you compile a simple program with M or C option (stop after semantic or coding without library write) then “recompile” with P, U ou A option and then finally take a look at the $$$\_TREE.TXT in ./bin where test example and ada\_comp executable are. The $$$\_TREE.TXT is a text dump of the DIANA TREE contained in the ./ADA\_\_LIB/$$$.TMP work file containing page blocs of the current compilation DIANA tree.
Note on the archival tool. The TLALOC source code must be as small as possible because I want to have a long term archival possibility for the compiler source code on perennial media (non acid paper and endurant ink or metal laser engraving). In the Tools directory there is a block optimizer for source code compaction and a pdf printer of square quadwords bit drawings which can be read with a simple magnifier or with a recognition software through high resolution scanner. It is possible to put some 300kb+ per A4 page side, roughly a disquette of the 1970ies ; so the whole compiler source has been printed on 5 A4 pages (see ./src/tools/Archivage\_Encode/TLALOC\_grid). Have a look it is funny !
---
### Author:  [@joakim-strandberg](https://forum.ada-lang.io/u/joakim-strandberg)
#### Post date: [May 7, 2026, 8:24pm UTC](https://forum.ada-lang.io/t/ada-83-tlaloc-on-arm-aarch64-v8/4387/18 "2026-05-07T20:24:40Z")
> The compiler does take multiple units in the same text file provided they are in a consistent partial compilation order. There was an init bug I corrected yesterday on DN\_NBR\_PAGES “not integer” this is when an attribute field has no initialization (in IDL.PAR\_PHASE.SET\_DLFT or IDL.SEM\_PHASE.MAKE\_NOD). There is a small example I tested yesterday evening (multi\_units.ada which produces PACK\_1.DCL, PACK\_1.BDY, PACK\_1.finc, MAIN\_PROG.DCL and MAIN\_PROG.finc). I did not even remember it was the case because the whole file approach is only useful for distribution and so not often used, for development one unit per text file is more logical and practical.
Thanks for fixing the bug stopping the compiler from accepting several compilation units in one file. I tried compiling multiple compilation units in one file and it works well using the Ada 83 TLALOC compiler.
There is actually an argument for putting several compilation units in one file. It may be useful when developing Ada source code to be compiled by several different Ada compilers. Each of the Ada compilers Meridian Ada, Janus / Ada, ObjectAda and GNAT come with their own build systems. Having all the Ada code in one file is convenient because you can write a small build script yourself where you invoke the compiler with suitable compiler flags and point out the file with all the Ada code. When using the GNAT compiler one can first use gnatchop before compilation. So, by putting all the Ada source code in one file it is possible to avoid the complexity of a plethoria of build systems with their own configuration files.