Eurydice: a Rust to C compiler
jonathan.protzenko.fr
jonathan.protzenko.fr
- has designed the Mezzo programming language in his Ph.D. thesis and
- has worked on generating user-friendly C automatically. Most tools that generate C output pretty unreadable/unmaintainable code that you won't like to maintain, so this is a much under-researched topic.
For example, in the 37c3 talk "Breaking "DRM" in Polish trains" by the folks from Dragon Sector (I highly recommend watching it), they needed to reverse-engineer Tricore binaries, however they found the Ghidra implementation had bugs.
As for the PLCs, the IEC 61131-3 functional block diagrams transpile to C code which then compiles to Tricore binaries using an obscure GCC fork. Not saying that anyone would want to write Rust code for PLCs, but this is not uncommon in the world of embedded.
"Breaking "DRM" in Polish trains"
My understanding is pretty much all of them are extremely immature and not a drop in replacement.
Lower level representations also exist - since C has goto, you can pretty much turn any SSA IR to C, but the end result won't be readable.
and considering how long compiling LLVM takes... it's reasonable to go for other options
Most teams who write code for embedded devices (especially the weird devices at issue here) don't have the hardware knowledge, time, or contractual ability to write their own compiler backend. They're almost always stuck with the compiler the manufacturer decided to give them.
But ya, I believe this project exists for a meaningful purpose, I'm just surprised.
They aren't usually building a compiler from scratch; they modify their existing compiler[1] for their new hardware, which is fractions of effort required compared to building a new compiler or modifying the LLVM backend.
Unless it's a completely new ISA, they'll spend an hour or less just adding in the new emit code for only the changes in the ISA.
----------------------------------
[1] Usually just the previous gcc that they used, which is why in 2022 I was working on brand new devices that came with a customised gcc 4.something
Building a backend for LLVM to a single architecture, well, only provides access to that architecture.
rustc_codegen_clr is an experimental Rust compiler backend(plugin), which allows you to transpile Rust into .NET assemblies, or C source files.[0]
But in Zig's case it seems there's a pretty good chance that will change if they're able to drop LLVM in the future.
Hence why it should be a priority for WG14 to actually improve C's safety as well, unfortunately most members don't care, otherwise we would at least already have either fat pointers, or libraries like SDS on the standard by now.
The SysV ABI is still used to this day, although the specification itself has withered until only two chapters remain[1], and CPU vendors still publish "System V ABI appendix" documents for platforms that System V's authors could not have dreamed of[2].
C as an interface is going to be around for a very long time, like POSIX and OpenGL and the SysV ABI standard. C as an actual language might not - it might wind up as a set of variable types that other languages can map into and out of, like what happened to the rest of the SysV ABI specification.
[1]: https://www.sco.com/developers/gabi/latest/contents.html
Sorry should have been more clear. I'm talking specifically about C89, or maybe C99.
My reaction is kind of: "So what?" I really don't care about the relative lives of languages and don't really understand why anyone would. Unless I am wrong, there is still lots of COBOL we wish wasn't COBOL? And that reality doesn't sound like a celebration of COBOL?
IMHO it would be completely amazing if magically something 10x better than Rust came along tomorrow, and I'd bet most Rust people would agree. Death should be welcomed after a well lived life.
To me, the more interesting question is -- what if efforts like c2rust, Eurydice, TRACTOR and/or LLMs make translations more automatic and idiomatic? Maybe C will exist, but no one will be "writing" C in 20 years? Perhaps C persists like the COBOL zombie? Perhaps this zombification is a fate worse than death? Perhaps C becomes like Latin. Something students loath and are completely bored with, but are forced to learn simply as the ancient interface language for the next millennia.
Is that winning? I'd much rather people were excited about tech/a language/a business/vibrant community, than, whatever it is, simply persisted, and sometimes I wish certain C people could see that.
You'd be disappointed if something 10x better came along tomorrow? I suppose you would you also be disappointed if magically we had economical fusion power, because you own utility stocks? Or we invented 10x better new car, because you already own an old car?
Of course the world wouldn't immediately move to one thing or the other, etc., and we'd still have a 10x better thing?
> Obviously I want better languages to come out, but I'd either want a bit of warning or a slower pace
The purpose of this thought experiment is to say -- it's perfectly fine for things to live and die, if they must. We've had a second Cambrian period for PLs. It's perfectly alright if some don't live forever, including Rust, which I really like.
In my thought experiment, Rust and C could also accept this new paradigm, and adapt, and perhaps become 10x better themselves. Though this is something heretofore C/C++ haven't done very well. IMHO new things don't preclude old things, and there mustn't be only one winner.
> Thankfully languages need about 10 years to mature from 0.1 to production readiness, and industry happily ignores marginally (and moderately) better languages
Which my thought experiment did as well? Read: This is a 10x improvement!
I think it would take a while for that to happen, purely due to momentum' the same thing that makes some people think that Rust isn't being used will affect any younger language just as much, if not more.
I think that there's an easier language than Rust struggling to come out of it, but if Rust had been that easier language with different compromises, I doubt it would have gained critical mass that allowed it to get where it is today. Being fast and safe meant it carved a niche in a "free square" that drove it to have a clear differentiator that allowed it to gain an initial audience. I also suspect that it is easier toale a language fast and then evolve it to make it easier to use, than it is to make it easy to use first and then make it fast.
Obviously a 1.1x language will come out - we don't just jump directly to 10x - and that's fine, fantastic even, but a little bit annoying when you're a language enthusiast and you've personally spent lots of time advocating for the now next-best language.
https://www.rocketsoftware.com/en-us/products/cobol/visual-c...
[0] ISO COBOL 2023 - https://www.iso.org/standard/74527.html
I don't think you understand my point. I am explicitly saying "C will definitely survive (like COBOL)". I am asking is that the kind of life people want for C?
I am happy if people are excited about Rust, but I do not like it too much myself. Although I acknowledge that it contains good ideas, it also has many aspects I find problematic and which why I do not think we should all switch to it as a replacement for C.
Could you share those?
Not trying to argue, just curious on the perspective of a C veteran, as someone who’s just starting with lower level languages.
This is fantastic, if you're still excited about C. However, the question I am asking also has to do with the social relational aspects of programming. Here, significantly, when we are talking about the lives of programming languages/decades, I think we should ask whether other people, and, importantly, industry, will be equally jazzed about yours and others C code, in the future. Are people still going to be happy to deal with all of C's problems when, perhaps, alternatives exist, and if, say, memory safety becomes cheaper, etc.?
A while back I wrote some C code to do the "short-bread" problem (it's a bit of a tradition at work to give it to people as their first task, though in Python it's a lot easier). Implementing a deque using all of the modern guard rails and a single file unit test framework still took me a lot of attempts.
Nowadays, not so much. Computers are multiple orders of magnitude faster, have multiple orders of magnitude more memory and storage and do things multiple orders of magnitude more complex than they used to. Portable assembly still has its uses obviously, but safer/easier/faster alternatives exist in all its niches.
C is much closer to any other high level language than it is to assembly. 'Portable assembly' might have been true with trivial C compilers of the 70s and 80s, but not with compilers like gcc or clang.
And C is still the best way to talk to the hardware in a portable way.
C has never been a particularly good language, and is so good that finally (with tons of pushbacks!) there is an alternative that make the case so strong that is at least considered the possibility that will come the very happy day where C will be our past.
The only, true, real blocker is that C is the ABI. But if we consider the possibility that C can AND should be the past, then the C Abi can finally adds sophisticated things like Strings and such, and maybe dreaming, algebraic types (ie: the C will be improved with the required features so it can evolve the ABI, but not because will be a good language for write it (manually) on it).
And to reiterate: C should finally be a real assembly language, something we not need to worry about.
Assembly is used quite a lot and if you're a programmer Assembly is very valuable to know _at least_ how to understand it.
I disagree, also, that C should go away. Saying it was never a good language is a bit harsh. It's a great language. One that industries are built on. I'd rather read/write C code than, say, Rust.
Edit: There are, of course, languages coming up that can absolutely compete with C. Zig could be one when it's mature, for instance.
I bet you never wrote single program in Cobol...
Who said it was dead? I was clear that I thought it was very much undead, like a zombie.
The way I see it, the longer something is actively used, the greater the chance it’s going to stick around. I’m bullish on rust but I’m equally bullish that C will last a long, long time.
But it’s not an either-or here. Both are good at certain things and can coexist. Like they’re coexisting in the Linux kernel for example.
I wonder if this is it's killer feature - compatibility with the C ABI.
Almost all non-C language offer that feature. The additional thing of the Zig toolchain is that it can also compile C/C++/ObjC projects without requiring a separate compiler toolchain, e.g. the Zig compiler toolchain is also a complete C/C++ compiler toolchain.
Cryptography is already difficult to write in high level languages without introducing side channels via timing, branch predictor, caches etc.
Cryptography while going through two high level compilers, especially when the code was not designed and written to do so is an exercise fraught with peril.
Tbf, this is just nitpicking about the article, not the project itself
Ooof I remember when everything used to be like this. Cargo has really spoiled me.
In fact he turned king Polydectes and all of his followers into stone when he went back to Sephiros.
Perseus defeated Medusa by not looking at her in the eyes.
Rust in a sense, allow you to solve problems without having to look directly at memory unsafe behavior.
I would have called this project "Medusa".
By default, this is only in debug mode. I recently forgot to add it to release mode on a project, and was surprised when I broke the CI (tests run in debug, I only tested in release mode).
There's a Rust compiler in C++ in case that's any good to you
Seems like the kind of thing that happens before a language is natively supported by a compiler.
It's at least a less bad idea than I expected originally – I've mainly seen people try to use transpilers to sneakily start using the language they prefer as part of a larger code base, with all the obvious problems.
It's still not great as you now have an additional translation step to deal with. You will at some point need to look for bugs in the generated C layer, which will really suck. Users of the C library can't read your source to understand what it does internally without an extra step to figure out what rust code the thing they use corresponds to, etc.
If you want to provide a C library, write C. If rust isn't an option because it doesn't work for your customers who use C, don't use rust.
The Rust-to-C conversion would be done by the Rust library author (or more likely, some automated CI process) to create a C source code distribution of the Rust library.