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: backlog1.nntp.dca.giganews.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!goblin2!goblin.stu.neva.ru!cyclone03.ams2.highwinds-media.com!news.highwinds-media.com!voer-me.highwinds-media.com!peer03.am1!peering.am1!npeersf04.am4!fx20.fr7.POSTED!not-for-mail From: Brian Drummond Subject: Re: Augusta: An open source Ada 2012 compiler (someday?) Newsgroups: comp.lang.ada References: <2_2dnSTeev2DurfO4p2dnAA@giganews.com> User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Message-ID: NNTP-Posting-Host: 62.49.20.82 X-Complaints-To: abuse@demon.net X-Trace: 1395273616 62.49.20.82 (Thu, 20 Mar 2014 00:00:16 UTC) NNTP-Posting-Date: Thu, 20 Mar 2014 00:00:16 UTC Date: Thu, 20 Mar 2014 00:00:16 GMT X-Received-Body-CRC: 1551365210 X-Received-Bytes: 3386 Xref: number.nntp.dca.giganews.com comp.lang.ada:185212 Date: 2014-03-20T00:00:16+00:00 List-Id: On Wed, 19 Mar 2014 19:24:13 -0400, Peter Chapin wrote: > On 2014-03-19 19:04, Brian Drummond wrote: > >> LLVM appears to have problems supporting nested (locally declared) >> subprograms. This appears to be behind slow progress on the Dragonlace >> project, to use Gnat as an LLVM front end. > > Thanks for the heads up... I'll have to keep that in mind. One advantage > of having a project that is 99% talk and only 1% action is that I'm not > deeply committed to a particular back-end technology yet. I do know that > I don't want to deal with all the low level code generation stuff, > however. GHDL has a level called "ortho", pretty much an intermediate language representing the syntax tree, with three backend translators : to gcc (gimple) code, whence gcc provides all the optimisation passes, and the low level code generation to (potentially) any of its backend targets; to llvm (experimentally in the current trunk) - I haven't tried this yet. to "mcode" - ghdl's own JIT compiler (x386 only so far). Astonishingly (to me anyway) I benchmarked this JIT version - which is tiny as compilers go, under 0.8MB source - the executable was only 20% slower than gcc -O2. Now I might just have been lucky (or unlucky!) on the testcase I picked, but I was expecting a naive translator to be quite a bit slower than gcc... The interfaces from "ortho" to gcc and llvm are 100kbytes and 250kbytes of source; mostly Ada, naturally. (the gcc interface includes ONE C file. Guess where most of the problems are... :-) I see the LLVM interface also has one C++ file; and it is much smaller... https://sourceforge.net/projects/ghdl-updates/ May be worth some investigation as an approach to retain portability between back-ends. (There is also a mode where "ortho" can be saved, inspected, and later passed to the gcc backend, to simplify working on the compiler). My own dreams of an independent Ada compiler involve using this intermediate level as a proven piece of the puzzle. >> (I strongly believe Ada and VHDL users should >> talk to each other more than they do!) and he also ran into this. > > I tend to agree about the VHDL/Ada connection. Even just because of VHDL's relative popularity in the FPGA world; there are 2 StackExchange questions tagged "vhdl" for every question tagged "ada". And yet not many VHDL users realise there's an equally good or better language for the software aspects of their design. -- Brian