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 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Brian Drummond Newsgroups: comp.lang.ada Subject: Re: community-based compiler (was Re: What exactly is the licensing situation with GNAT?) Date: Sat, 15 Nov 2014 12:44:53 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <87fvdr2vdv.fsf@adaheads.sparre-andersen.dk> <54609F34.4080201@spam.spam> <35f01472-3510-4f67-8765-006fa8591c35@googlegroups.com> <9tc8w.73007$ZT5.37595@fx07.iad> <22a3816a-4e89-48f0-a126-dce581781beb@googlegroups.com> <084b1934-9641-425e-85ec-293e0334413e@googlegroups.com> <86bf69c8-eb08-4696-b6c9-3784f5c42213@googlegroups.com> <87389olqie.fsf@ixod.org> <3516753b-5304-408d-99c8-67f544fdc185@googlegroups.com> <20141114085046.4cb00404@atmarama.ddns.net> <8392b6bd-61ab-43f9-aa6d-92a4b3f17f0d@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Sat, 15 Nov 2014 12:44:53 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="da745e888d4a5182b5fda6212bbb0a63"; logging-data="19791"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX185AqfpuVWklhHyOlrRpLgsj6x0hU9U50k=" User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2) Cancel-Lock: sha1:MzyCY9qvsQsnwrKPEJH1/HmzRtA= Xref: news.eternal-september.org comp.lang.ada:23370 Date: 2014-11-15T12:44:53+00:00 List-Id: On Fri, 14 Nov 2014 13:53:33 -0700, Shark8 wrote: > On 14-Nov-14 11:55, David Botton wrote: >>> I agree with you that there ought to be another open-source >>> >freely-available Ada compiler >> What resources are needed to make it happen? > > Hm, I think there are several things that are needed, and which would > have different emphasis at different points in development. -- For > example, a good, clear plan for the overall architecture and underlying > tech* would be essential. -- Another thing that might be useful is, from > the ground up, employing formal methods (ie Ada/SPARK and proofs) for > correctness.** > > After the initial stages,*** the "clear path to submit patches and bug > reports" becomes much more important after getting to an operable state. > > * e.g. if it used DIANA for its interface between the front-end and > back-end (and tools) that should be (a) shown and (b) well documented. > OR if it uses a SCID [ http://mindprod.com/project/scid.html ] approach > documentation of the underlying DB and interfacing to it. Having just bought the book (DIANA : An intermediate language for Ada) it appears to me that DIANA was effectively obsoleted by ASIS (though perhaps a simple ASIS <-> DIANA translation might be feasible, assuming compatible Ada versions). I don't believe DIANA was ever updated for Ada-95 for one thing, so at this point ASIS looks like a better starting point. And there is an ASIS implementation independent of Adacore, which builds quite easily. This would seem to be a good starting point for a future compiler (it was originally targeted at the TENDra project which seem so be ... drifting. There is still some work being done on it, but without reference to Ada, and the GELA-Tendra interface seems to eb unavailable in any reasonably complete form) Updating Gela-ASIS for Ada-2012 could be useful in its own right, and done approximately independently of using Gela-ASIS to supply an intermediate representation to an existing back-end (gcc,llvm,etc) I am (very tentatively) looking at ghdl's intermediate representation. which currently interfaces to three compiler backends - gcc, (experimentally) LLVM, and its own 32-bit x86 JIT compiler. A translation between ASIS and this IR would (based on the equivalent translation layer in ghdl) be something like a 30,000 line project in itself. Big, but more manageable than an entire compiler. > I haven't found a good path, but then I'm more interested in a whole new > project rather than tying ourselves down to a single implementation. At this stage, I'm happy to see several paths followed, some will inevitably turn out to be dead ends. -- Brian