A possible new back end for Rust • Hacker News Board

Re: A possible new back end for Rust

#221

Post by ruds » Fri, Apr 24, 2020, 7:05 PM UTC

MauranKilom wrote: post #217

bluGill wrote: post #196

Earlier quoted context omitted.

Edg is writing a good front end. With good error handling and all of the other things that make a commercial program a few hundred times harder than a quick prototype. I'd be writing a brute force front end that is slow, and goes straight to assembly. If there is a syntax error I'll handle it by crashing. When you create a variable is used twice in a row I'll store the intermediate value back into memory and reload i…

I'm still awfully skeptical that you can get even close to understanding all the template, lookup, lifetime, lambda, exception and initialization rules in a semester (I assume that CS students are almost never this deep into C++ at that point). Not to speak of actually implementing all of it. I'd be curious where these classes draw the line. Do you happen to have a syllabus or so? I don't doubt you can implement a me…

http://www.cppgm.org/ was a sort of experiment called "C++ Grand Master Certification." It seems to have died out, but the goal was to produce a self-hosted C++-11 compiler and standard library implementation. It took about a year to go from nothing to code generation in 9 programming assignments (I think I completed the first 6 before I got too busy to continue).

Re: A possible new back end for Rust

#222

Post by ethelward » Sat, Apr 25, 2020, 11:09 PM UTC

pizlonator wrote: post #182

ethelward wrote: post #181

Earlier quoted context omitted.

Except for _e.g._ memory alignment, or types of a given width (until C99).

For lots of us the extensions that gcc and clang support are part of C. So, a backend that emits C would get access to those things if it wanted.

Until you want to write code that works on platforms not supported by these compilers.

Re: A possible new back end for Rust

#223

Post by wtetzner » Mon, Apr 27, 2020, 7:01 PM UTC

ethelward wrote: post #222

pizlonator wrote: post #182

Earlier quoted context omitted.

For lots of us the extensions that gcc and clang support are part of C. So, a backend that emits C would get access to those things if it wanted.

Until you want to write code that works on platforms not supported by these compilers.

How many platforms does LLVM support that Clang does not?

Re: A possible new back end for Rust

#224

Post by wtetzner » Mon, Apr 27, 2020, 7:07 PM UTC

bluGill wrote: post #130

sambe wrote: post #40

Earlier quoted context omitted.

Why phrase it as "other than to prove it can be done" if you already know there are good answers? I think the following obviously do apply: 1) much easier for Rust community to contribute to the compiler from end-to-end. 2) lower coordination cost with LLVM giving complete, Rust-focussed control over code generation/optimisation. Think about e.g. fixing noalias. 3) lower maintenance cost for LLVM integration/fork. It…

Because I don't think the possible good answers apply. Sure it is harder to contribute to the backend, but does it matter? I've been doing c++ for years and never looked at the backend. I'll grant lower coordination costs. However I believe they are not outweighed by the advantages of the other llvm contributions. If they need to fork llvm that is a problem. Either merge it back in and be done (with some tests so wha…

One advantage is that you don't need a C++ compiler to build the Rust compiler. Dealing with building C++ projects can be a major headache.