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.
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.
> 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.
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.
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.
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.
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'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.
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!
29 comments
[ 2.9 ms ] story [ 78.4 ms ] threadAlso, 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.
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...
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.
https://www.ghs.com/products/AdaMULTI_IDE.html
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.
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 imagine Adacore has a larger share, but have no data to back that up.
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.
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.