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:8d8e:: with SMTP id p136-v6mr480699iod.32.1527040732631; Tue, 22 May 2018 18:58:52 -0700 (PDT) X-Received: by 2002:a9d:5608:: with SMTP id e8-v6mr293196oti.5.1527040732474; Tue, 22 May 2018 18:58:52 -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-v6no385105itb.0!news-out.google.com!b185-v6ni289itb.0!nntp.google.com!u74-v6no385102itb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 22 May 2018 18:58:52 -0700 (PDT) In-Reply-To: <60d3b0f0-b740-4200-ae80-47226f47ea2c@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: <5c2523c1-9ea5-453c-b80e-9cb0dcd16de0@googlegroups.com> <9381c59b-311f-4265-8d52-fd6386ccc1db@googlegroups.com> <57d6ccf6-23da-445c-89d6-b18143913018@googlegroups.com> <60d3b0f0-b740-4200-ae80-47226f47ea2c@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <218e6b4e-66ba-4ff0-8d5d-7f643b1e108b@googlegroups.com> Subject: Re: DragonEgg has been revived From: "Dan'l Miller" Injection-Date: Wed, 23 May 2018 01:58:52 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:52606 Date: 2018-05-22T18:58:52-07:00 List-Id: On Tuesday, May 22, 2018 at 5:33:29 PM UTC-5, Shark8 wrote: > On Tuesday, May 22, 2018 at 2:17:11 PM UTC-6, Dan'l Miller wrote: > > On Tuesday, May 22, 2018 at 2:40:24 PM UTC-5, Shark8 wrote: > > > On Tuesday, May 22, 2018 at 6:29:10 AM UTC-6, Simon Clubley wrote: > > > >=20 > > > > What I would like to see is an Ada compiler that can generate code > > > > for a wide range of targets without any GPL restrictions on the > > > > generated code. > > >=20 > > > I'm getting ready to restart work on Byron. I figure that perhaps an = Implementation Manual/Design Document would help explain the design underne= ath it and welcome new contributors.=20 > > >=20 > > > >=20 > > > > I'm not really bothered how that happens but LLVM seems like an > > > > interesting option. > > >=20 > > > I have mixed feelings on LLVM -- it would be nice to grab all the tar= gets for it, but I also think it's a stupid > > > idea to build the compiler specifically for it. > >=20 > > Writing a compiler =E2=80=9Cspecifically for=E2=80=9D LLVM? I thought = that the whole premise of Byron was to write an Ada compiler for multiple b= ack-ends: > > 1) libFirm: https://pp.ipd.kit.edu/firm > > 2) LLVM > > 3) GCC > > 4) Graal for JVM: http://www.graalvm.org > > 5) CLR for .NET & Mono > > and so forth. >=20 > Byron certainly is about multiple backends -- but there's been a lot of t= alk about an "LLVM Ada compiler" here in the past, to the point where the i= mplications really were designing a compiler specifically to it. >=20 > >=20 > > Compared to Byron's laudable long-term clean-room-design goals, my GELI= proposal* for an LLVM-backended GNAT is an interim stop-gap, focusing only= on likely-not-clean-room generation of LLVM bitcode IR within a single GPL= v3 GNAT executable, causing only ISAs' machine-code (not the IR) to be gene= rated by LLVM-embedded-within-GNAT. >=20 > Hm interesting.=20 >=20 > >=20 > > > Yeah; that's one of the big problems Byron [Ada 2012 in Ada 2012] is = intended to address; the other big > > > one is to escape the stupid morass of licensing issues. > >=20 > > What is so bad about GPLv3 with Runtime Exception =E2=80=A6 >=20 > In itself, not so much -- the biggest problem with anything GCC [meaning = GNAT in the context of Ada] is that there's all the morass of licensing sur= rounding it: FSF GNAT vs PGL GNAT vs AdaCore Pro GNAT -- all have different= restrictions and capabilities and it's just a big mess -- especially for a= ny small to medium business to sort out. >=20 > I want a clean break from ALL of that. As do we all. If GELI project is clever, mods & extensions to LLVM-world c= an be accomplished outside of GCC-world (e.g., with UofIllinois/NCSA licens= e) if they are not derivative works of anything in GCC. These value-adds t= o LLVM-world could occasionally be useful to Byron. The only things that c= ome to mind are: 1) the no-files always-in-DRAM way of avoiding writing LLVM bitcode IR* to = files between LLVM-world's stages (but I am not entirely unsure so far that= this might already exist in LLVM-world); 2) chaining Polly stages flexibly amongst LLVM stages by =E2=80=A2not=E2=80= =A2 executing Polly executable multiple** times; 3) command-line parsing for LLVM-world topics, 3.1) e.g., command-line parsing for =E2=80=9Cllvm-=E2=80=9D-prefixed target= s 3.2) e.g., command-line parsing for chaining Polly amongst LLVM-world stage= s; 4) fresh new test suite. * regardless of whatever the content of that LLVM bitcode IR is ** see page 8 of https://polly.llvm.org/publications/grosser-diploma-thesis= .pdf Conversely, I haven't been clever enough to yet figure out a way that GELI = could be clean-room in the =E2=80=9Csouthbound=E2=80=9D LLVM-bitcode-IR dir= ection (for Byron's usage) while actually being clean-room in input-to-GELI= direction on the =E2=80=9Cnorth=E2=80=9D side of GELI. So far I haven't b= een clever enough for GELI's north-side awareness of GNAT's fully-semantica= lly-adorned Ada IR snippets to not make =E2=80=A2all=E2=80=A2 of GELI downs= tream-southbound a derivative work of GNAT (and thus licensed by GPLv3-with= -Runtime-Exception), including the generated LLVM bitcode IR being effectiv= ely tainted transitively by awareness of the content & boundary of the snip= pet from GNAT's Ada-IR tree. That taint ruins any attempt to keep the LLVM= bitcode IR clean room. If all roads in GELI lead to being a tainted deriv= ative work of GNAT's Ada-IR tree then why attempt the immense hassle of cle= an-room designing the LLVM bitcode IR at all (other than to help out Byron)= ? I am open to ideas there though. > The viral nature of GPL is also a turn-off for a lot of companies, regard= less of runtime exception. I agree wholeheartedly. That is why we need Byron (or for one of the close= d-source Ada compilers to get aggressively super-competitive with GNAT).