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:b503:: with SMTP id e3-v6mr11712711iof.18.1526915192490; Mon, 21 May 2018 08:06:32 -0700 (PDT) X-Received: by 2002:a9d:6210:: with SMTP id g16-v6mr60503otj.4.1526915192337; Mon, 21 May 2018 08:06:32 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!feeder.erje.net!2.eu.feeder.erje.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!v8-v6no4694221itc.0!news-out.google.com!b185-v6ni4242itb.0!nntp.google.com!u74-v6no4645842itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 21 May 2018 08:06:32 -0700 (PDT) In-Reply-To: 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: <65d93062-f55d-435f-a099-3c8ee75f2705@googlegroups.com> <76f63959-e26a-407e-a029-b13fd12540d3@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <1cafad54-b559-4536-9ddc-d6a26d84a2a6@googlegroups.com> Subject: Re: Is this Forum Moderated? From: "Dan'l Miller" Injection-Date: Mon, 21 May 2018 15:06:32 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:52542 Date: 2018-05-21T08:06:32-07:00 List-Id: On Monday, May 21, 2018 at 6:40:14 AM UTC-5, Brian Drummond wrote: > On Sun, 20 May 2018 09:18:15 -0700, Dan'l Miller wrote: >=20 >=20 > >=20 > > There is a fair chance that LLVM already has all the primitives needed > > to express every conceivable Ada construct and semantics. (GNAT didn'= t > > have to extend GCC's C IR very much over all these years; there have > > been 10 tree types added to GCC's C IR for Ada topics, and even 6 of > > those have varying degrees of =E2=80=98it never actually shows up in th= e tree > > downstream from GIGI=E2=80=99.) >=20 > One it doesn't have : support for nested subprograms. It's too heavily=20 > modelled on C. Well, Clang supports C++11, C++14, C++17. C++11 has lambdas that can be = assigned to a named local variable, which is substantially the same feature= , not in the language per se, but as an idiom nowadays. http://clang-developers.42468.n3.nabble.com/Nested-functions-in-Clang-tp404= 7603p4047605.html auto const local_function =3D [&](int parameter) { // Do something }; ... local_function(1); so GELI (GIGI-alternative Emits LLVM IR, the LLVM-based alternative to GIGI= in GNAT) would emit the LLVM bitcode IR that Clang today already emits the= re. Steps on the road to GNAT's GELI as an alternative to GIGI: 0) To design and author GELI, the LLVM-facing rear of the Clang front-end w= ould be borrowed in general. 1) On a per tree-node type in GNAT's Ada-IR tree (i.e., whatever snippet of= work that the iterator/cursor traversing GNAT's fully-semantically-adorned= Ada-IR tree bites off for GIGI to chew on), GELI would first borrow the co= rresponding C++ language feature's LLVM-bitcode-IR generation code=E2=80=A6 2) =E2=80=A6 then compare that starting point to what GIGI transduces into = the C-IR tree for GNAT to find semantic adornments in the Ada-IR tree that = were not covered =E2=80=A6 3) =E2=80=A6 then ponder whether C++ or any non-C language has any addition= al delta of semantics not already covered by GELI's LLVM-bitcode-IR generat= ion for that snippet =E2=80=A6 3.1) if yes, 3.1.1) then borrow from that language's corresponding LLVM-bitcode-IR gener= ation code; 3.1.2) then compare GELI's evermore-evolved LLVM-bitcode-IR generation for = that snippet with what GIGI transduces into the C-IR tree for GNAT; go to s= tep 3. 3.2) if no, then author fresh LLVM-bitcode-IR generation code from scratch;= go to step 3. 4) If more snippets of GNAT's fully-semantically-adorned Ada-IR tree remain= without LLVM-bitcode-IR generation in GELI, go to step 1. 5) Release GELI-based/LLVM-backended GNAT corresponding to a major.minor FS= F GCC release. 6) If new language features or bug-fixes were released into FSF GNAT for th= e next GCC release, go to step 1. 7) Maintain this GELI fork of GNAT indefinitely until accepted* into GCC or= until something like GELI is released into FSF GNAT by AdaCore**. * which could conceivably be never, given that GELI requires the entirety o= f LLVM to be wholesale imported into GCC to comply with the Target Code cla= uses of GPLv3 and the Eligible Compilation Process of its Runtime Exception ** which, post-Dewar, might or might not have enough sway with RMS himself = to pull off the idea of importing*** the entirety of LLVM into GCC merely f= or GNAT's needs. *** or AdaCore could conceivably opt (in the publicly-released-to-FSF GNAT = source code) to emit IR from GCC for downstream processing by a separate no= nGPL-licensed LLVM executable, thus triggering the =E2=80=A2=E2=80=A2=E2=80= =A2=E2=80=A2LLVM-produced machine code downstream to strictly be full-fledg= ed GPLv3-licensed=E2=80=A2=E2=80=A2=E2=80=A2=E2=80=A2 due to not satisfying= GPLv3's Target Code clause and likely not satisfying Runtime Exception's E= ligible Compilation Process clause either. And then customers who pay for = GNAT Pro would not rely on that every-LLVM-target-must-be-GPLv3ed version; = they could conceivably get & rely on something more resembling GELI('s sati= sfaction of the Target Code and Eligible Compilation Process clauses), so t= hat AdaCore's customers would not need GPLv3-license all their LLVM-target = executables and libraries. If past track record predicts future regarding = post-3.15p GNAT, then this third *** variant might be the most likely, unle= ss RMS himself is displeased with even emitting LLVM IR at all from GCC. (If RMS would be displeased by even the slightest whiff of LLVM & LLVM's bi= tcode IR anywhere near GCC [which =E2=80=A2seems=E2=80=A2 to be the read-th= e-tea-leaves current vibe], then the current status quo is the most likely:= no LLVM machine-code generation from FSF GNAT whatsoever, other than the = one-off DragonEgg experiment.) > I believe this was one of the problems Dragonegg was facing. Looking through DragonEgg's source code reveals that borrowing the LLVM bit= code IR for C++11's assigning a lambda to a named local variable is the lea= st of the problems that DragonEgg's stick-fingers-into-far-too-many-pies de= sign was facing. > The GHDL project already faced this, when translating its own IR=20 > ("ortho") to the LLVM backend, and overcame it successfully, so it's not= =20 > a total showstopper Clang also already faced this for C++11, as shown above. > I haven't dived into src/ortho/llvm in the ghdl source tree to find out= =20 > how Tristan did it. The authoring of GELI will require looking at the LLVM-backended open-sourc= e compilers for Clang, Flang, Haskell's GHC, Rust, GHDL, and so forth to ha= rvest GPLv3-compatible-licensed source code inspiration from which to borro= w, wherever analogous language features or analogous higher-order-usage idi= oms of lower-language features can be found in other languages.