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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no 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!feeder.eternal-september.org!news.glorb.com!peer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post02.iad.highwinds-media.com!fx18.iad.POSTED!not-for-mail From: Shark8 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:36.0) Gecko/20100101 Thunderbird/36.0a1 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: community-based compiler (was Re: What exactly is the licensing situation with GNAT?) References: <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> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID: X-Complaints-To: abuse@teranews.com NNTP-Posting-Date: Sat, 15 Nov 2014 22:47:41 UTC Organization: TeraNews.com Date: Sat, 15 Nov 2014 15:47:41 -0700 X-Received-Bytes: 4138 X-Received-Body-CRC: 837731028 Xref: news.eternal-september.org comp.lang.ada:23395 Date: 2014-11-15T15:47:41-07:00 List-Id: On 15-Nov-14 05:44, Brian Drummond wrote: >> 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. Agreed. I do hope, however, that we don't get "watered-down" or "spread too thin" by having too many paths. > 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. An interesting approach. I do wonder about VHDL though: since it's a hardware-description language, could it be feasible to base a compiler backend on it so that targeting a new system is merely a matter of feeding it the description of that hardware? -- Or am I completely misinterpreting what its purpose is? > 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. I can see it both ways; the ASIS, having been updated through Ada-95, would have a lot of the Ada 2005 stuff in-place -- on the other hand, updating DIANA for Ada 2012 could allow for a bit of regularizing the IR to handle things in a more uniform manner, as well as [possibly] redefining the interface in terms of GENERICs and/or INTERFACEs.* ASIS <-> DIANA translation you mention might be possible via a Translation-grammar; I came across them in a paper [I think on DIANA] and they sound pretty interesting even if I've not heard of them before. * Another thing that might be interesting is an [portable] IR-executor, this would have much of the benefit of bytecode w/o [directly] depending on DOTNET or JVM... heck, if that translation-grammar module works very well we could, in theory, make it so that adding a new target is simply writing a new translation-grammar.