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.
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.
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?
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.
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 ?
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).
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.
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).
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
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.
Would this licence proposition for TLALOC Ada 83 be accepted by most of us :
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;
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.
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.
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.
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.
Very good ! you are the first to have said you have done it.
The fasmg executable is in the ADA__LIB directory, it is not ideal as organization, but it does the job for development.
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.
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.
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).
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 !
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.
