61–70 of 99 posts
Rewrite in C is the new Rewrite in Rust.
GTA VI out in Rust before C++?
> I put my left hand in a blender. The blender won. (Still have all my fingers, just some stitches). I will not elaborate further. What a shame. I would've read an article about this.
Earlier quoted context omitted.
This reminds me of https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...
The sole and entire purpose of Diverse Double-Compiling is addressing Thompson's Trusting Trust: https://dwheeler.com/trusting-trust/
> The primary goal of this is support for old/obscure hardware with no LLVM/GCC support Wouldn't it be easier to add old hardware support to LLVM/GCC instead? I adore the project scale and determination, but for this goal extending existing projects seems more logical than building a language translator.
Some architecture lacks documentation, if you have a working C compiler, it's easier to use it than working on a compiler to target it.
Edit: On second thought, that's only needed if you want to run rustc itself on the old hardware, which is probably not super useful given the main reason you would need to do this is if LLVM can't target that hardware.
For building code written in Rust for such old hardware, this would be sufficient.
> For the past 3 years, I have been working on compiling Rust to C. .. This is, by my count, the 14th attempt: cilly Gotta respect the dedication to a niche interest. > The primary goal of this is support for old/obscure hardware with no LLVM/GCC support. I remember reading about the bootstrapping question, how it typically requires a Rust compiler to build the Rust compiler from source. https://bootstrapping.mirahez…
If you're going to go to all this effort for an old target though, wouldn't the effort be better spent on making it an LLVM target? Then you'd get Rust and a bunch of other languages for free.
But maybe there are required parts of the LLVM IR that make this undesirable for certain targets, maybe requiring specific hardware features, I don't know. I guess also WASM-as-IR is a possible way to go. (Is that a thing?)
Edit: sorry I see that this point was already raised in this thread by ivanjermakov. Ignore.
> The primary goal of this is support for old/obscure hardware with no LLVM/GCC support Wouldn't it be easier to add old hardware support to LLVM/GCC instead? I adore the project scale and determination, but for this goal extending existing projects seems more logical than building a language translator.
on the other hand, porting llvm to an infinite number of platforms requires an infinite amount of work
so, it is less work this way
Have you tried Diverse Double-Compiling (DDC) to test if the official rust compiler has a backdoor? Use crustc to compile the rust source code, producing a new compiler. Then use this new compiler and the official rustc binary, both with deterministic flags, to compile the rust source code again. The two outputs should match bit for bit.
It's not diverse in that case - it's the same compiler source compiled to binaries twice - it's just that with one compiler you've gone via a C intermediate representation. For the purposes of diversity it's the same as compiling rustc with the cranelift/gcc backend.
The actual issue here is that the translation was done using a rustc backend, and therefore an existing rustc binary which could be compromised and inject a "if (user=="wmanley") {...}" that isn't present in the original Rust code. If cilly was completely standalone (like mrustc), or if you had a rustc+cilly build you trusted, there would be no issue.
Earlier quoted context omitted.
This approach is harder than you might imagine. LLVM can do a lot of things that don't map to C language constructs. You cannot generally roundtrip arbitrary LLVM IR through some C representation. You can emulate most things, but you won't necessarily get the same LLVM IR in the other end.
FWIW, Rust can also do a lot of things that do not easily map to C (at least standard C) constructs. For example: - You can compare any two pointers, while in C they must point to the same allocation. This is possible to solve by converting to integers first. - Signed integer overflow is UB in C, defined to wrap/panic in Rust. - Type-based alias analysis is a big one, does not exist in Rust.
Indeed specifically Rust defines that pointer comparisons are done by address, whereas C doesn't specify what the rules are exactly. This gets sticky if the pointer was invalidated (e.g. you free'd the memory it was pointing at). Rust says - as you might expect - that you can still compare this invalid pointer to another pointer (which may or may not still be valid and indeed might be a valid pointer to the same address!) because we're only comparing the address - but C++ says you mustn't do that and I believe C has the same rule.
> Signed integer overflow is UB in C, defined to wrap/panic in Rust.
This doesn't feel like an interesting difference. C made a weird choice, which was maybe convenient for the usual Worse Is Better reasons 50+ years ago. LLVM doesn't care about that choice, LLVM can cheerfully simulate this behaviour in C if you want that.
> Type-based alias analysis is a big one, does not exist in Rust.
This also doesn't feel relevant but I guess I'm interested in why you think it would make "a big" difference?
Edited: I confirmed C11 has "pointer zap" which is the behaviour I described above, and I believe C23 also still has pointer zap although paulmck and co. are trying to get rid of it or do something on this topic in C2y.