Cwerg looks interesting indeed. I had it on my radar for some time. Especially its focus on simplicity and independence (e.g. that it can directly generate ELF executables) are attractive. From my humble point of view, both Python 3 and C++17 are a bit unfortunate as implementation languages. I can understand that the author didn't want to use C, but C++98 would have resolved this issue with less build and dependency complexity than C++17. Last year, I intensively evaluated backends and eventually settled on https://github.com/EigenCompilerSuite/, which supports a large number of targets, has a very powerful IR code generator and also comes with its own linkers. Also Eigen is unfortunately written in C++17, but I managed to port all relevant parts to a very moderate C++11 subset (even C++98 seems feasible in future).
Am I wrong to assume that Cwerg doesn't support x86, or is this just assumed by "X86-64"?
Well, for all applications which don't require to addres more than 4 GB memory, a 64 bit machine is overkill. This especially applies to embedded systems (which make up the majority of all systems). This is unlikely to change for the next fifty years.
Well, if the consumer market thinks that 64 bit architectures are a core benefit (for whatever irrational reason) and are willing to pay for it, industry will/does deliver. It's still overkill for all but a few applications. But I never saw in my more than thrity years in embedded systems that a company did well on a long term when wasting money for non-essential capabilities.
Ultimately, the plan for Cwerg is to be self-hosting, so C++ is just another stepping stone.
I am curious about the issues with C++17 (vs say C++11) though.
About using C++:
Cwerg is NOT going "all in" on C++ and tries to use as little STL as possible.
There are some warts here and there that C++17 fixes and those are used by Cwerg - nothing major. There is also a lightweight C wrapper for Cwerg Backend.
About not using C:
I do not get the fetishizing of C. String handling is just atrocious, no concept of a span, no namespaces, poorer type system, etc.
Cwerg is actually trying to fix these.
If Cwerg was written in C instead of C++, a lot of the constructs would become MACRO-magic.
About Backends:
Currently supported are: 64 bit ARM, 32 bit ARM (no thumb), 64 bit x86
There are no plans to support 32 bit x86
> I am curious about the issues with C++17 (vs say C++11) though.
It's about dependability and bootstrapping. GCC 4.7 was the last version implemented in C, and it supports C++98/03 and a subset of C++11.
> There are some warts here and there that C++17 fixes [..] nothing major
But it's C++17 and thus requires many more bootstrap cycles until we have a compiler. I think a backend which only supports a subset of the features of a C++17 compiler should not depend on C++17, otherwise its usefulness is restricted by the availability of such a compiler.
> I do not get the fetishizing of C. String handling is just atrocious...
C is just a pretty primitive high-level language (with a very strange syntax) a compiler of which exists on almost any system. The next complexity step is C++98 (or the subset supported by cfront), which solves your issues and is even good enough to build something as complex as Qt and KDE.
> There are no plans to support 32 bit x86
Ok, thanks. The support for ARM32 already enables many use cases.
I can commiserate. I did some bootstrapping of gcc 10 years ago and it was the most miserable experience ever. You make a change somewhere. Kick off "make" and 20 min later you get some bizarre error in some artifact that is hard to find, generated by a build system that is impossible to trace.
A self-hosting Cwerg will hopefully be much easier to bootstrap because of its size.
But until then, why do you need the (continuous) bootstrapping. You can use a cached version of the bootstrapped C++ compiler or cross compile.
Am I wrong to assume that Cwerg doesn't support x86, or is this just assumed by "X86-64"?