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

91–100 of 224 posts

Re: A possible new back end for Rust

#91

Post by pjmlp »

jfkebwjsbx wrote: post #21
bregma wrote: post #17

Earlier quoted context omitted.

Modern compilers generally have a language-specific front and that generates an intermediate representation of the program logic, which is then transformed into an abstract representation (such as a single static analysis tree) for optimization. That is then transformed into an abstract machine description language, which gets further transformed by the back end into concrete machine instructions or assembly code. Ou…

> There is no technical advantage to transforming Rust into C There is a key one: the ability to use any C compiler out there (including proprietary ones). This allows you to target all platforms out there.

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.

Re: A possible new back end for Rust

#92

Post by swagonomixxx »

pizlonator wrote: post #2

This is really great. The world needs more diverse compiler tech. The llvm monoculture is constraining what kind of compiler research folks do to just the things that are practical to do in llvm. I particularly suspect that if something like Cranelift gets evolved more then it will eventually reach throughput parity with llvm, likely without actually implementing all of the optimizations that llvm has. It shouldn’t b…

Devil's advocate: more diverse compiler tech will mean a more fragmented community and a larger probability of divergence across implementations.

People think the C compiler community is dominated by GCC and Clang, and it is, but there are literally 1000s of implementations out there in the wild. Most are necessary, because we need code generated for some obscure processor architecture that's completely proprietary, but you can create that "backend" in LLVM itself - it's a new target architecture instead of e.g x86.

The great thing about LLVM is that it's effectively the quickest (and probably the best) way to generate machine code without putting in too much effort, for a language. Whether that language be a research language or an existing industry language (say, C), that kind of establishment is hugely valuable.

A great example of a good monoculture is the Go monoculture. Sure, there's gccgo, but the proportion of people using that vs. the reference implementation is minimal, and that reduced fragmentation is actually a good thing for practitioners (which most engineers are, not PL researchers).

Re: A possible new back end for Rust

#93

Post by cfv »

pizlonator wrote: post #2

This is really great. The world needs more diverse compiler tech. The llvm monoculture is constraining what kind of compiler research folks do to just the things that are practical to do in llvm. I particularly suspect that if something like Cranelift gets evolved more then it will eventually reach throughput parity with llvm, likely without actually implementing all of the optimizations that llvm has. It shouldn’t b…

I still remember when Clang bringing LLVM along was seen as SO OUT THERE and I'm just mentioning it because I find it weird to be old enough to see fads in system languages come and start to go.

Just curious, do you have any examples of this "limitations" you speak of? Sounds like a very interesting read.

Re: A possible new back end for Rust

#94

Post by steveklabnik »

pjmlp wrote: post #91
jfkebwjsbx wrote: post #21

Earlier quoted context omitted.

> There is no technical advantage to transforming Rust into C There is a key one: the ability to use any C compiler out there (including proprietary ones). This allows you to target all platforms out there.

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.

Re: A possible new back end for Rust

#95

Post by andrewprock »

pjmlp wrote: post #89
andrewprock wrote: post #81

The thing that struck me most about the article was this quote from the Rust Survey (2019): “Compiling development builds at least as fast as Go would be table stakes for us to consider Rust“ Go was designed from the ground up to have super fast compile times. In fact, there are some significant language issues related to that design decision. Using one of the primary design goals that impacted language structure as…

If you mean generics, D, Delphi, Ada and plenty of other languages prove you can have them and still be pretty fast.

I mean interface{}

https://golang.org/doc/effective_go.html#interfaces_and_type...

Re: A possible new back end for Rust

#96

Post by StreamBright »

jcranmer wrote: post #76
StreamBright wrote: post #51

Earlier quoted context omitted.

Just out of curiosity, what would be a great intermediate language to transpile to (as of intermediate language)?

Of ones I'm a familiar with, LLVM IR is probably the best, although it has other issues of its own (in particular, floating point is done even worse than C). I'm not aware of any language which is going to beat a retargeting compiler's processor-agnostic IR. But even the "better C" languages tend to not really attempt to expand C structurally. The changes amount to fixing the egregious semantics (fixed-size types, no…

Interesting. I need to look into LLVM IR a bit more to understand this subject better.

>> I've been trying to design a portable assembly language.

Couldn't something like Forth fulfill this role?

Re: A possible new back end for Rust

#97

Post by j88439h84 »

steveklabnik wrote: post #66
Waterluvian wrote: post #57

When writing a language like Rust, is the biggest challenge simply deciding what Rust's features and behaviors should be? And implementing the syntax and Rust -> LLVM compiler is really just a chore for the individuals who are super familiar with the implementation of these languages? Or is the technical implementation also genuinely challenging and non-obvious?

First of all, deciding features and behaviors is not simple. :) There are a number of technical implementation challenges in the compiler. It is a large project, and Rust's got a really intense stability policy. The compiler was bootstrapped very early, when the rate of change of the language itself was still "multiple things per day." This introduced significant architectural debt. There have been multiple projects…

> Rust's got a really intense stability policy.

I know the code won't stop running, but I wonder how soon it stops being idiomatic. If it's not idiomatic, it's harder to maintain due to unfamiliar style and structure. Does Rust have measures to deal with this issue?

Re: A possible new back end for Rust

#98

Post by raphlinus »

stephencanon wrote: post #36
Koshkin wrote: post #5

I've been wondering lately if the modern compilers should all be using C as the intermediate language (or some language-specific code optimization opportunities could be lost if they do that).

If you're trying to implement a language with substantially different semantics from C (e.g. a substantially different memory model, or without UB) the semantics of C make it really unsuitable as an IR. You can't use C's casts (undef for out of range float -> int conversions, for example), arithmetic (undef for signed overflow), or shift operators (implementation-defined behavior for signed right shifts, undefined be…

I agree 99.44%.

The behavior of shift operations on signed integers will be fixed in C++20 and C2x, as part of the effort to require twos complement representation. It is a massive potential source of UB in currently standardized C and C++.

All the other problems listed remain.

[1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p090...

[2]: http://eel.is/c++draft/expr.shift#2

Re: A possible new back end for Rust

#99

Post by edflsafoiewq »

steveklabnik wrote: post #88
edflsafoiewq wrote: post #78

Earlier quoted context omitted.

I believe that is the IR after the optimizer has chewed through it.

Oh duh. Should be obvious that you can drop the -O flags, at least.

Yes, which gives about 40 lines of IR for C, and about 1300 for Rust (Godbolt truncates it at 500).

Re: A possible new back end for Rust

#100

Post by aw1621107 »

jcranmer wrote: post #76
StreamBright wrote: post #51

Earlier quoted context omitted.

Just out of curiosity, what would be a great intermediate language to transpile to (as of intermediate language)?

Of ones I'm a familiar with, LLVM IR is probably the best, although it has other issues of its own (in particular, floating point is done even worse than C). I'm not aware of any language which is going to beat a retargeting compiler's processor-agnostic IR. But even the "better C" languages tend to not really attempt to expand C structurally. The changes amount to fixing the egregious semantics (fixed-size types, no…

> in particular, floating point is done even worse than C

Do you mind expanding on this or pointing me to places where I can read more?

Post reply on HN