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:a6b:f49:: with SMTP id x70-v6mr7026025ioi.107.1526699677842; Fri, 18 May 2018 20:14:37 -0700 (PDT) X-Received: by 2002:aca:48d2:: with SMTP id v201-v6mr247996oia.0.1526699677614; Fri, 18 May 2018 20:14:37 -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!border2.nntp.dca1.giganews.com!nntp.giganews.com!v8-v6no2229749itc.0!news-out.google.com!f20-v6ni2364itd.0!nntp.google.com!v8-v6no2229748itc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 18 May 2018 20:14:37 -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: 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 03:14:37 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:52462 Date: 2018-05-18T20:14:37-07:00 List-Id: 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. Ahh, are these .def files the pre-C++ hack of using multiply-included C hea= der files (without multiple-inclusion guard conditional compilation #if !de= fined NAME_OF_FILE) to emulate parameterized types? I guess I need to anal= yze the various points at which these .def files are #included to see if = =E2=80=9Dtemplate=E2=80=9D parameters are ginned up to be passed into the #= include. I would say that a human being author of a GiggleVM would only need a read-= only* knowledge of these trees to mimic them over in rear-of-Clang-speak to= feed LLVM the way that GIGI speaks rear-of-C/C++-GCC to feed GENERIC/GIMPL= E. But the more that I think about it, perhaps a mechanized transliteratio= n of GIGI's rear-of-GCC-C/C++-feeding-GENERIC/GIMPLE to GiggleVM's rear-of-= Clang-feeding-LLVM-IR might assure fewer bugs (or at least bug-for-bug comp= atibility). * Writing these GENERIC trees would require far deeper & broader full-grok = knowledge.