No, as in replacing the entire back end.
Congratulations!
Since it is a DIANA-based system, I assume that you would just implement a DIANA → New-Target, or DIANA → other-IR → New-Target.
Ah… You have to write from scratch the expander procedure using idl.ads interface (in /src/ada_comp directory) and DIANA 86 documentation in /doc. You can get inspiration from my expander !
There’s no idl generator for creating the skeleton?
I’m working on an IDL generator.
Hi Lucretia !
Could you develop what you mean by IDL generator ? And OneWingedShark also.
IDL is a language for describing data-structures; the description file is used to generate the data-structure in the language(s) that the generator targets. So, by ‘generator’ I mean the thing that compiles an IDL file and produces the target language; I’m only planning on an Ada83 and Ada 2012 backend.
@charlie5 and I did an update to DIANA for Ada 2022; so once I get the generator up and running, we might be able to (with this compiler or AdaDoom3’s) do an Ada83 → Ada 2022 boostrap decently easily.
IDL = Interface Definition Language
You write API’s in IDL, run them through a generator and it generates all the framework code.
That’s the OMG IDL and, IIRC, CORBA.
The Wulf/Lamb/Nestor IDL is different; it’s only about the data-structures.
Example:
structure example root E1 is
A => a1: String;
B => b1: Integer, b2: Rational;
C => c1: Rational;
E1 ::= A | B; E2 ::= E1 | C ;
E1 => x : Integer; -- all members of E1 have x
E2 => y : Rational; -- all members of E2 have y
end
maps to
Type E2_Base is tagged abstract record
y : Rational;
end record;
Type E1 is tagged record
x : Integer;
end record;
Type E1_A is new E1 with record
a1: String;
end record;
Type E1_B is new E1 with record
b1: Integer;
b2: Rational;
end record;
Type E2_E1 is new E2 with record
Data : E1;
End record;
Type E2_C is new E2 with record
c1: Rational;
end record;
IIUC; there’s some interesting features in IDL, like the WITHOUT keyword, which eliminated a field from the derivation.
And L3/4 and AmigaOS FD files (very basic).
Hi.all
I returned on the AArch64 porting and synchronized the code_arm64.finc with the codi_x86_64.finc .
I cross assembled a TLALOC/T2arm targeted compiler on x86 then transferred it on Orange Pi 3b. On the arm Orange SBC TLALOC/T2arm compiled all predefined packages from source. Now I try to produce T3arm from TLALOC sources with T2arm on Orange Pi.
If everything works. I sync the riscv-64 codi also. and if I can make the Starfive function, I test the same process. So that I hope to have a self hosted compiler for 3 modern 64 bits processors under Linux.
After that I’ll try bare metal exe, for fun.
P.S. Update 
All TLALOC sources have been compiled by TLALOC/T2 in about 5 minutes on Orange Pi 3b. Thus I have a compiler for AArch…
BUT, because there is one : fasmg is written in x86 assembly ! there is no fasmg exec for arm. So I can compile all to FINC but I cannot assemble the FINCs on arm (except qemu solution perhaps). I can only assemble on x86. Wil I have to write a substitute to fasmg in Ada 83 ? 
There is an old Universal Assembler spec: IEEE Std 694-1985,
along with a Universal Object spec: IEEE Std 695-1990.
That said, there are some really interesting papers on “cheating”:
- Using a High Level Language as a Cross Assembler. ← Read This Paper!
- Lifting Assembly to Intermediate Representation: A Novel Approach Leveraging Compilers.
- No More Translation at Runtime: LLM-Empowered Static Binary Translation might be useful in conjunction with
- Toward a foundational typed assembly language.
With Paper #1, it shows exactly how you can leverage the compiler of a high-level language to essentially handle cross-assembler work; it’s not a completely seamless model for processing already-generated assembly, but it can be used to massively reduce what you have to do.
Hi !
Thank you for those references !
Hi.all
After some thought I decided to write a new phase TARGET_CODE in replacement of fasmg. It takes exactly the same syntax as fasmg and is intended to produce byte identical output, but just what is necessary for the backend of TLALOC. It will have no multi pass which is a costly and sometimes difficult to debug feature.
With TARGET_CODE I will have a totally independent compiler (I compile this last phase with TLALOC itself so that this new Ada 83 corpus enters the TLALOC exercise. It has already paid with some corrections of the expander as parts of TARGET_CODE are IA generated and the programming style is different from mine.
Hi.all
Some news :
The first exec DIS_BONJOUR obtained with TLALOC.TARGET_CODE for x86 has been obtained byte identical to the one produced by fasmg from .fas and .FINC fasmg files. Next step assembling the whole x86-64 compiler with TARGET_CODE ; then fasmg will become useless on x86. Later same objective for AArch and RISCV : eliminate fasmg.
The first executable DIS_BONJOUR for RISCV-64 obtained from famsg has been run with success. The next step is cross building and testing the whole compiler for the SBC Starfive 2 with processor RISCV-64.
The compiler has been bootstrapped on x86-64 (laptop) and AArch64 (SBC Orange Pi 3b) through fasmg. With RISCV-64 TLALOC will target the main three modern 64 bits processors.
Hi.all
Independence day on x86 : TLALOC.TARGET_CODE has swallowed the whole compiler’s fas and FINC includes (14 Mb of fasmg text ) and produced the 10 294 624 bytes T2 identical to fasmg.
$ ./TARGET_CODE
NOM FICHIER .fas (sans extension, simple ret faire les tests) : ADA_COMP
CARTO capacites :
elements 765721 / 1000000 differes 4519 / 200000
texte 14012708 / 50000000
symboles 200347 / 1048576 scopes 17149 / 65536
pool 2599348 / 16000000
octets 10294504 / 32000000
This wholly homemade exec has compiled T3 (of course, it is byte identical to the fasmg T2).
On x86, TLALOC now compiles itself to ELF64 with no external tool.
Now forcing on arm64 and riscv-64 independence.