Recently [John Spicer] of the EDG C++ compiler front-end project announced that the project will be made open source, from now on managed by the non-profit C++ Alliance. Related source code can be found on the GitHub account.
The Edison Design Group (EDG) is a US company which has made compiler front-ends since 1988, previously also for Java and Fortran. They are used in the Intel C++ compiler, Microsoft’s VC++, NVIDIA’s CUDA compiler, as well as many other commercial products. Last year the decision was made to shutdown the company in 2026 and transition to an open source model, with the details outlined on the EDGCPP site.
Although far from the only C++ front-end, EDGCPP will be very interesting still for supporting bleeding-edge features and having been used in such wide-ranging, demanding applications by a host of commercial customers. For most of us C++ developers our contact with it will have been via the MSVC and Intel Compiler Collection tooling, but of course it’s just one part of the entire toolset.
We’re looking forward to seeing what this means for the wider open source C++ ecosystem, especially as it pertains to GCC and LLVM’s Clang.
Will be interesting to see a third open source implementation, being as parsing C/C++ correctly is a famously impossible problem if you aren’t already one of the big two. Rust has had problems even with just the C ABI, and has uncovered issues like GCC and clang disagreeing on the layout of 128-bit integers.
I wish there was gcc port for PIC16. IMO they are one of the best MCUs. Cheap and much better datasheets compared to AVRs or STM32.
I often read here about chips that have no or limited information data sheets yet the chips are being sold. I wonder why that is. Maybe someone could explain….
Sometimes you get access to better data sheets when you commit to buying larger quantities and sign NDA.
heh PIC16 is extremely un-powerful from the perspective of a C compiler. i just imagine filling out the code generator for PIC16 and all your most basic operations turn into big idioms with multiple instructions and a lot of caveats. it’s very much “harvard architecture”, things like a different pointer size for pointers to code than pointers to data isn’t impossible in C but always feels like a poor fit. by comparison, when i read the PIC18 instruction set, it seemed like they had gone out of their way to add things a C compiler might assume (like a stack). but even PIC18 seems like a poor fit to C. it’s not impossible, and surely it would be useful for a lot of things…
personally i love PIC, but in my life, all of its elegance is in the world of hand-coded assembler.
stm32 (ARM) by comparison is an extremely natural target for a C compiler, even if your resources are constrained. i don’t know the history or line-up of AVR but the atmega chips are much more C-friendly than even PIC18.
I have worked extensively with the 16 bit PIC24 family of MCUs, which are IMHO truly great products given the vast array of onboard hardware.
The compiler that Microchip provide for these, ARE a fork of GCC, and very good too. However I still prefer the older C30 compiler the the newer XC16, on the grounds that the free variant is less nobbled compared to the newer XC16 compiler.
Talking of compilers and front-ends: I’m commenting in general when I say that all the development stuff is really getting out of hand in terms of size I noticed.
Perhaps they should sit down and get a grip a bit before continuing.
If the compilers and development utilities are many gigabyte how are you going to write code that isn’t inflated too one wonders.
Soon even MCU’s will need 200GB for their code too, and they will be delivered by a separate truck, and they need to run at 5GHz to handle all the inflated nonsense.
And of course they will start at $2999.99 a piece. That is for the starter version that can blink a LED.