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:94ce:: with SMTP id j197-v6mr4617989ite.37.1526694484364; Fri, 18 May 2018 18:48:04 -0700 (PDT) X-Received: by 2002:aca:ec90:: with SMTP id k138-v6mr209946oih.2.1526694484256; Fri, 18 May 2018 18:48:04 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.uzoreto.com!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!u74-v6no2145022itb.0!news-out.google.com!f20-v6ni2387itd.0!nntp.google.com!u74-v6no2145018itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 18 May 2018 18:48:03 -0700 (PDT) In-Reply-To: <9b5ee32b-0b12-48fe-b34f-135f3cd8cfb9@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> <3d3c1882-ae3d-42aa-8f13-80c550e50375@googlegroups.com> <144a041b-e870-464c-b16f-9adbd7523a92@googlegroups.com> <9b5ee32b-0b12-48fe-b34f-135f3cd8cfb9@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <17f9d1c5-7c66-4c19-a1d3-f0e7d30cb063@googlegroups.com> Subject: Re: disruptors of & inventory of Ada compilers and latest their era of ISO8652 compliance From: "Dan'l Miller" Injection-Date: Sat, 19 May 2018 01:48:04 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:52456 Date: 2018-05-18T18:48:03-07:00 List-Id: On Thursday, May 17, 2018 at 11:49:03 AM UTC-5, Dan'l Miller wrote: > Wait, GNAT has its own full-fledged IR stage prior to deriving either GEN= ERIC or GIMPLE from that GNAT IR? On Friday, May 18, 2018 at 6:48:22 AM UTC-5, Lucretia wrote: > The *tree* packages in GNAT are autogenerated from a *def file, these map= onto the C equivalent in the GCC backend so that GNAT can build the trees = properly. The following PowerPoint presentation concurs with you, Luke: https://www.slideserve.com/reed/the-structure-of-the-gnat-compiler It also presents a rewording of my =E2=80=9CWait, =E2=80=A6=E2=80=9D commen= t above: GNAT builds an entire Ada-oriented AST-adorned-with-semantics the= n builds another IR tree using GCC-C-language-compiler constructs. Effecti= vely GNAT works by effectively translating Ada IR to C IR internally, and t= hen generating machine code from C's IR. I will need to investigate 1) whether C++ likewise builds its own AST-adorned-with-semantics then buil= ds another IR tree using only C-language constructs or 2) whether the so-called C-IR tree is actually capable of full-fledged C++-= semantic adornment (i.e., whether the so-called C IR would be actually full= -fledged C++ IR not lowered to C-only constructs at all) and thus C++ would= build only one tree , not GNAT's two. The GiggleVM drop-in LSP alternative to GIGI in GNAT would have the ability= to translate Ada's AST-with-semantic-adornment to either C or C++ construc= ts in the interface-to-LLVM rear side of Clang. Occasionally, it might be = convenient for GiggleVM to map Ada to directly analogous C++ constructs ins= tead of to C to avoid reinventing the OO wheel from scratch, especially reg= arding Ada's tagged records vis a vis C++'s vtables. I need to investigate those def files. Specifically I'll need to learn: w= here is the script/code that reads def files and generates C code or C macr= os to manipulate the C IR tree? Perhaps running these def scripts is a maj= or portion of what you refer to as =E2=80=9CGCC is a bitch to build=E2=80= =9D on your GCC build script GitHub README.md.