Re: disruptors of & inventory of Ada compilers and latest their era of ISO8652 compliance

["Dan'l Miller" <optikos@verizon.net>]

On Thursday, May 17, 2018 at 3:23:51 PM UTC-5, Dan'l Miller wrote:
> According to Figure 1 in the following reference, GIGI feeds fragments of the semantically-adorned tree
> to either GENERIC or GIMPLE. 
> 
> https://www2.adacore.com/gap-static/GNAT_Book/html/node5.htm#fig:frontal-gnat 

Does anyone know (or have a URL to) why GIGI was written in C instead of in Ada?  Obviously, it is calling much C code in the GCC backend world, so there is that.  Was it simply because GIGI predated the addition of so much of the unchecked_* feature-set in ISO standard Ada that permits interfacing with C APIs?

The reason that I ask is because I am perplexed by the opposing boundary:  the AST data structure that GIGI is traversing is an Ada data structure (i.e., instantiated & adorned by all the Ada-language code throughout the rest of the GNAT frontend), correct?  So wouldn't the impedance mismatch (to borrow a EE term) between AST-versus-C at the AST-versus-GIGIc boundary have been much more immense than any annoying unchecked_* layer between GIGIada-versus-GCCbackendWorld, where GIGIc is the extant one today, and where GIGIada is the hypothetical one that was never written in Ada, and where GCCbackendWorld is all C (and nowadays some C++ AIUI).

Perhaps the LLVM replacement for GIGI should be written in Ada instead of C.  Perhaps that means not LSP of the AdaFE-to-GIGI interface, where AdaFE is the rest of the frontend of GNAT written in Ada.  Conversely, keeping exactly today's extant AdaFE-to-GIGIc existing interface via LSPing GiggleVM instead of GIGIc as a drop-in replacement would permit an immense amount of insulating a fork of GNAT from a vast amount of evolutionary change in GNAT's AdaFE.

(I can imagine that perhaps FSF and/or AdaCore and/or LLVM.org could all refuse to merge any attempt at this GiggleVM LSPing of GIGIc and grafting on a 2nd backend within a single GPLv3ed GCC executable.  Maintaining an llvm-gnat fork outside of FSF and outside of LLVM.org might be completely unavoidable if GiggleVM LSPing of GIGIc is not embraced lovingly.  I can imagine that AdaFE's GIGIc interface is low-churn historically, likely modified once per blue moon when an ISO standard Ada feature begets a change in the backend of GCC that was not already needed by C++ or any of the other languages.  Having a relatively-historically-stable AdaFE-to-GIGIc interface that is low churn and thus low drama might be advantageous to long-term maintenance of an llvm-gnat fork of GCC.  Lowering the drama might be worth keeping the Ada-to-GiggleVM interface exactly the same via LSP as today's Ada-to-GIGIc interface, even if it is in C.)