Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A possible new back end for Rust

jason-williams.co.uk

Post reply on HN
Print view View original

151–160 of 224 posts

Re: A possible new back end for Rust

#151

Post by msla »

pizlonator wrote: post #141
bluGill wrote: post #134

Earlier quoted context omitted.

Depends on your goals. Writing a front end, optimizer and backend quickly gets to more work. I can write a c++ compiler in a few months. It won't be good and to make it good would be many many years of work. If I write a llvm backend it might take a little longer (I doubt it), but I automatically get all the optimizations llvm has plus a good front end that doesn't have bugs in obscure corner cases. (not claiming llv…

Still not as good as emitting C code in most cases? C code gets optimized using either llvm or any other optimizer so it’s a more portable compile target.

When you emit C, you're limited by C, at least if you want to emit C as opposed to inline assembly wrapped in C. For example, it's harder to have a function return more than one value in C than it is in most architectures, you can't do things with processor flags (on architectures which have them), you're at the mercy of the C compiler's optimizer as to vectorization and loop unrolling, you can't always preserve semantic information in the source code even when a "reasonable" compiler would be able to use it to improve the machine code...

LLVM was created to replace emitting C, by providing programmers a way to turn source code into a representation that is lower-level than C without having to write the whole optimization and assembly code generation pipeline.

Re: A possible new back end for Rust

#152

Post by pitaj »

gbrown_ wrote: post #119
dwheeler wrote: post #110

One cool advantage of having multiple compilers for a language is that you can use one as a check on the other. For example, if you're worried that one of the compilers might be malicious, you can use the other compiler to check on it: https://dwheeler.com/trusting-trust Even if you're not worried about malicious compilers, you can generate code, compiled it against multiple compilers, and sending inputs and see when…

> For example, if you're worried that one of the compilers might be malicious, you can use the other compiler to check on it: https://dwheeler.com/trusting-trust This still requires the use of a use of trusted compiler though. Comparing two compilers arbitrarily shows if there is consensus , it does not give guarantees about correctness . From the link. In the DDC technique, source code is compiled twice: once with a…

Please don't quote with code blocks. Makes reading on mobile very difficult.

The quote reformatted:

> In the DDC technique, source code is compiled twice: once with a second (trusted) compiler (using the source code of the compiler’s parent), and then the compiler source code is compiled using the result of the first compilation. If the result is bit-for-bit identical with the untrusted executable, then the source code accurately represents the executable.

Re: A possible new back end for Rust

#153

Post by WalterBright »

The D programming language has 3 compilers, one with LLVM (LDC) one with GCC (GDC) and one with the Digital Mars back end (DMC).

It's great to have all three, as they each have different characteristics in terms of speed, generated code, debug support, platform support, etc. Supporting these three also helps maintain proper semantic separation of code gen from front end.

Re: A possible new back end for Rust

#154

Post by aseipp »

cpeterso wrote: post #140
pizlonator wrote: post #126

Earlier quoted context omitted.

Historically writing a compiler in the language that you’re promoting is a good way to really understand the limitations of your language. I think this works so well because language designers tend to understand compilers better than they understand other software.

I heard Niklaus Wirth would only allow new compiler optimizations (in his compilers for Pascal, Oberson, Modula-2) that proved themselves by speeding up the compiler itself.

This is the mandatory rule for Chez Scheme which was only broken once when their entire backend was rewritten, and also (from what I have heard) a large guiding principle for the C# compiler at Microsoft.

It's extreme but it's a good idea because it treats compilation time like an actual budget, which it is. You can't just add things endlessly. But it's not easy to achieve in practice.

Re: A possible new back end for Rust

#155

Post by dwheeler »

et2o wrote: post #142
dwheeler wrote: post #138

Earlier quoted context omitted.

First, I forgot to disclose: I am the author of https://dwheeler.com/trusting-trust . As discussed in detail in that dissertation, if you are using diverse double compiling to look for malicious compilers, the trusted compiler does not have to be perfect or even non-malicious. The trusted compiler could be malicious itself. The only thing you're trusting is that the trusted compiler does not have the same triggers or…

Sounds fascinating. Are there real-world examples of malicious compilers?

Yes, there was a malicious compiler system for Apple iOS that was released in China a few years back and subverted a large number of mobile applications, including apps used in the US and Europe. There was also a subverted Delphi compiler a number of years back, though I don't think the subversion was dangerous it was more like a test case. And of course, Ken Thompson demonstrated the attack in the 1980s. There may be others, but I remember those offhand.

Re: A possible new back end for Rust

#156

Post by dwheeler »

411111111111111 wrote: post #145
et2o wrote: post #142

Earlier quoted context omitted.

Sounds fascinating. Are there real-world examples of malicious compilers?

i read a story about a compiler adding malware to the compiled binary once. they kept getting owned until they supposedly found a pretty dump hack which just appended the backdoor to the final compilation on the build server... no clue if it was just a story though, as i personally havent experienced anything like that before.

Yes, that's right, that's another story about a subverted compiler. I don't have any way to verify it, but I have no reason to doubt the story. It is quite possible, and not even that difficult to do if you want to be that malicious. I don't have a URL for it, maybe someone else can provide that.

Re: A possible new back end for Rust

#157

Post by runevault »

Leherenn wrote: post #150
Myrmornis wrote: post #131

There wouldn't be any surprises, or cognitive dissonance, from using very different paths for debug versus release builds? On a small project, personally I use --release sometimes during development because the compile time doesn't matter that much and the resulting executable is much faster: if I don't use --release I can get a misleading sense of UX during development.

It's funny, because I do the exact opposite. As a developer I usually have a pretty powerful machine, and I've found that debug mode is a good way to approximate slow computers, and something that is unbearably slow in debug will bother some users later on.

This is an interesting idea, but I guess my one question is how much does the slowness of debug relate to HOW it will be slow in release? Since release optimizations can do pretty radical things to the assembly generated it feels like it wouldn't really be apples to apples.

Re: A possible new back end for Rust

#158

Post by pjmlp »

steveklabnik wrote: post #94
pjmlp wrote: post #91

Earlier quoted context omitted.

A dumb interpreter for the IR as bootstraping stage is a better alternative. Plus very few platforms have only support for C and nothing else, unless we are speaking about esoteric embedded CPUs.

We have an interpreter for MIR. It isn't fast enough.

I clearly mentioned "as bootstraping stage", for nothing else.

Re: A possible new back end for Rust

#159

Post by philsnow »

dwheeler wrote: post #155
et2o wrote: post #142

Earlier quoted context omitted.

Sounds fascinating. Are there real-world examples of malicious compilers?

Yes, there was a malicious compiler system for Apple iOS that was released in China a few years back and subverted a large number of mobile applications, including apps used in the US and Europe. There was also a subverted Delphi compiler a number of years back, though I don't think the subversion was dangerous it was more like a test case. And of course, Ken Thompson demonstrated the attack in the 1980s. There may b…

IIRC this was feasible because people in China are behind the GFW which throttles/blocks the mac app store, so most people download from in-country caches, which circumvents a lot / all of the app signing that Apple uses.
Post reply on HN