From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a24:1458:: with SMTP id 85-v6mr2370834itg.55.1526604971021; Thu, 17 May 2018 17:56:11 -0700 (PDT) X-Received: by 2002:a9d:703:: with SMTP id 3-v6mr41335ote.11.1526604970795; Thu, 17 May 2018 17:56:10 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!paganini.bofh.team!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!v8-v6no1170549itc.0!news-out.google.com!f20-v6ni1216itd.0!nntp.google.com!v8-v6no1170547itc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 17 May 2018 17:56:10 -0700 (PDT) In-Reply-To: <2f4dd5ae-a481-4eb4-93ff-2c1cc3cb10bb@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.233.194; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.233.194 References: <9169bb0d-626f-4f6d-82c9-8a9b7543a084@googlegroups.com> <92b78739-e2c5-4e45-bbd8-f80ec4918691@googlegroups.com> <6dc39990-16eb-4717-8b8a-1d41c2767530@googlegroups.com> <1103700103.548265160.819002.laguest-archeia.com@nntp.aioe.org> <4a2e4dc5-aec6-4e59-91cd-9476abdbac7c@googlegroups.com> <1193667974.548270050.319144.laguest-archeia.com@nntp.aioe.org> <2f4dd5ae-a481-4eb4-93ff-2c1cc3cb10bb@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <3d3c1882-ae3d-42aa-8f13-80c550e50375@googlegroups.com> Subject: Re: disruptors of & inventory of Ada compilers and latest their era of ISO8652 compliance From: "Dan'l Miller" Injection-Date: Fri, 18 May 2018 00:56:11 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:52414 Date: 2018-05-17T17:56:10-07:00 List-Id: 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.=20 >=20 > https://www2.adacore.com/gap-static/GNAT_Book/html/node5.htm#fig:frontal-= gnat=20 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 th= ere is that. Was it simply because GIGI predated the addition of so much o= f 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 bo= rrow 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 GIGI= ada is the hypothetical one that was never written in Ada, and where GCCbac= kendWorld 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 i= s the rest of the frontend of GNAT written in Ada. Conversely, keeping exa= ctly today's extant AdaFE-to-GIGIc existing interface via LSPing GiggleVM i= nstead 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 re= fuse 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 unavoi= dable if GiggleVM LSPing of GIGIc is not embraced lovingly. I can imagine = that AdaFE's GIGIc interface is low-churn historically, likely modified onc= e per blue moon when an ISO standard Ada feature begets a change in the bac= kend of GCC that was not already needed by C++ or any of the other language= s. Having a relatively-historically-stable AdaFE-to-GIGIc interface that i= s low churn and thus low drama might be advantageous to long-term maintenan= ce 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-GI= GIc interface, even if it is in C.)