Combining GNAT with LLVM | Hacker News Reader

Combining GNAT with LLVM

blog.adacore.com

64 pointssamuell29 comments

> a natural question would be "why are you starting a GNAT LLVM project from scratch instead of building on top of DragonEgg?". If you want to know the answer, check the file README.dragonegg in the repository!

Correct me if I'm wrong, but from the README [1], the answer appears to be:

> The dragonegg plugin works with gcc 4.5, 4.6, 4.7 or 4.8

But a little more digging reveals that there are patches so[2]

> DragonEgg works for for GCC v8.x

Lack of Google-fu or am I missing something? If they believed dragonegg is flawed, why not just lay it out? I prefer that over a goose chase that doesn't fully check out.

[1] http://llvm.org/svn/llvm-project/dragonegg/trunk/README

[2] https://lists.llvm.org/pipermail/llvm-dev/2017-August/116705...

Arguments against DragonEgg are laid out in the gnat-llvm repo here: https://github.com/AdaCore/gnat-llvm/blob/master/README.drag...

Dragonegg was never a particularly well-maintained project. You're building a bridge between GCC's and LLVM's IR, which means you're highly susceptible to changes in one or the other, and the conversion tends to drop annotations (such as debugging info!). Most people only really cared about Dragonegg as a way to get Fortran code compiled to LLVM IR. Now that Flang exists, the Fortran motivation isn't there.

Essentially, Dragonegg was only ever a last-resort way to get LLVM IR. If you're trying to build a LLVM backend, you might as well emit LLVM IR directly from your frontend rather than trying to deal with a GIMPLE backend and then a GIMPLE-to-LLVM converter.

GPLv3 license, so the flexibility of how you can include clang in your own tools won't be available for Ada.

No runtime license exception?

It's complicated, I believe the way it works is that the Community Edition you can download from the Adacore website doesn't have the runtime exception but, if it's built from the code in the FSF's repo, it does. This is Adacore's scheme to make sure that people making money off Ada buy a license.

That approach worked so well for the Lisp and Smalltalk vendors.

It might work if the US Department of Defense, NASA, and Boeing are customers (my assumption) and they keep their company small.

I think that is exactly what OP meant, as in, no new projects or further Ada marketshare. I think the same can be said for Lisp and Smalltalk.

Many seem to think GNAT is the only game in town, when actually there are 6 commercial compilers still available.

Just like Lisp and Smalltalk still have their commercial offerings available.

Naturally communities that want to be payed for their work, while refusing to pay for their tools aren't aware of such offerings.

I'd like to know how big adoption is for the other commercial Ada compiler companies.

I imagine Adacore has a larger share, but have no data to back that up.

Big enough for those companies to stay in business.

Yea, but Lisp and Smalltalk machines were tied to hardware that couldn't keep up and most of the government AI projects died during the 80s AI winter.

Adacore is (I'm guessing) the main vendor for lots of aerospace projects with deep pockets that aren't going away soon and it runs on mostly anything GCC runs on. They're also expanding their business into areas where cyber security is a concern.

My experience with Ada is you have legacy code bases and yes, forking these will continue for the next 30 years for similar products. But would anyone in 2019 really choose Ada for a design start in a DoD/aerospace realtime embedded system or cybersecurity application? I doubt it. It's hard enough to find developers in "common" languages.

I think its very telling that real-world JOVIAL code bases are being converted to C, not Ada. Ada was supposed to replace JOVIAL. http://www.semdesigns.com/Products/MigrationTools/JOVIAL2C.h...

There are also tools to convert Ada to C/C++/Java: https://www.mapusoft.com/ada-to-c-changer/

I'd start any new embedded system in C or C++ with an appropriate coding standard, static analysis checks, and perhaps run-time ones. No way I would consider Ada. Maybe someday Rust will penetrate more, but it has a ways to go.

Doesn't say: We have just published the GNAT LLVM tool sources licensed under GPLv3 on GitHub for hobbyists and researchers to experiment with it and give us their feedback.

It pulls runtime from FSF, which has GCC Runtime Library Exception.

There are many advantages of porting GNAT to an LLVM-based backend:

1) Clean-up of backend interface code to make it more robust and less GCC-specific

2) Allow for GNAT to target more platforms such as modern Apple devices (where GCC support is waning and LLVM is preferred) and WebAssembly

Right now they are stating that it is not production-ready, but I would not be surprised if the LLVM-based GNAT gains peer status with the GCC-based GNAT or even overtakes it.

They already have 5 others, according to the article. There's nothing gcc specific about it.

The main GNAT compiler that people actually use is based on GCC

I'm very interested in seeing where this leads. I've had so many problems creating Ada capable GCC cross-compilers from the FSF source, and it looks like I'm not alone in this area. This might open up new and better possibilities for platform support. Great work!

In theory would the performance be better or machine code smaller?

No.

I wouldn't be so sure. Given that this is a new backend for GNAT and the first one is close to 25 years old I assume it will have more modern optimizations and experience behind it - presumably leading to something faster.

The 'old' backend is modern gcc, which is on par with or beats llvm.

I would say gcc and llvm are competitive - asserting gcc is faster at its current state is quite a claim.

Also, I was referring to AdaCore's implementation of the compiler backend. GNAT's architecture is structured like so:

GNAT Frontend (parsing, analysis, expansion) -> GNAT Backend (translation of frontend tree to something GNU or LLVM can understand) -> LLVM or GCC

This backend is quite complex and has a large role in how LLVM can optimize. My argument is that GNAT's GCC backend is 25 years old and a new backend written for LLVM probably generates better/cleaner code.

Also of note is that the GCC backend is written and C and the LLVM is actually written in Ada meaning its more uniform with the GNAT frontend.

On the other hand, the GCC implementation has 25 years performance optimizations across the whole battery of programs they run.

It would be interesting to see comparisons, since afaik it's the only compiler front end that has llvm and gcc back end.

Ada-C++ LTO?

Green Hills Ada does it.

https://www.ghs.com/products/AdaMULTI_IDE.html

Reply on news.ycombinator.com