5 ms·

There was a thread posted on the rust forum a while back that laid out the goals of this project [0]: > A friend of mine (Luke) has been talking about the need

There was a thread posted on the rust forum a while back that laid out the goals of this project [0]: > A friend of mine (Luke) has been talking about the need for a Rust frontend for GCC to allow Rust to replace C in more places, such as system software. To allow some types of safety-critical software to be written in Rust, the GCC frontend would need to be an independent implementation of Rust, since the relevant specs require multiple independent implementations (so just attaching GCC as a new backend for rustc wouldn't work). Luke: > The goal is for the GNU Compiler Collection to have a peer level front end to the gfortran frontend, gcc frontend, g++ frontend and all other frontends. > The goal is definitely not to have a compiler written in rust that compiles rust code [edit: unless there is an acceptable bootstrap process, and the final compiler produces GNU assembly output that compiles with GNU gas] > The goal is definitely not to have a hard critical dependence on LLVM. > The goal is to have code added, written in c, to the GNU Compiler Collection, which may be found here https://gcc.gnu.org https://gcc.gnu.org 20 such that developers who are used to gcc may compile rust programs and link them against object files using binutils ld. > The primary reason why I raised this topic is because of an experiment permitting rust modules to be added to the linux kernel: https://lwn.net/Articles/797828 https://lwn.net/Articles/797828 > What that effectively means if that takes off is that the GNU Compiler Collection, which would be incapable of compiling that code, would be relegated to a second class citizen for the purposes of compiling the largest software project on the planet: the linux kernel. > Thus it is absolutely critical that GCC be capable not just of having rust capability but of having up to date rust capability. 0: https://users.rust-lang.org/t/call-for-help-implementing-an-independent-rust-frontend-for-gcc/32163 https://users.rust-lang.org/t/call-for-help-implementing-an-...

deleted 6y ago
[deleted]
ncmncm 6y ago
It would be a grave error to have coded the Rust frontend to Gcc in C (or, as written above, "in c"). Gcc is now a C++ codebase, and new components should be coded in modern C++, for better productivity, performance, safety, and maintainability. (You might prefer not to consider modern C++ more productive, performant, safe, and maintainable than C (and reflexively downvote), but the statement remains true: Gcc did transition to C++, for reasons. And, all the improvements that have kept Gcc competitive with Clang were done, since. And, Clang and LLVM are also coded in C++, also for reasons.)
- djur 6y ago
  gccrs is written in C++, so no worries there.
- anfilt 6y ago
  I disagree with the idea of using C++. Even with some of its more modern features. If I was choosing a compiled language for system development right now I would choose C or Rust. For starters C++ does not have a stable ABI. Rust plans too have a stable ABI. In either case right now both fall back to the C ABI, but at least its a goal of the rust devs. C++ is going to be harder to boot strap than either Rust core or C when trying to build a compiler for a new system/platform. C probably is the easiest bootstrap of the 3. Rust and C are generally more performant than C++ code. Also in the realm of low end micro controllers C code tends to have the smallest binary image size. In C++ if you need to interact with other languages a lot times your stuck to the C abi which which forces you to avoid a lot C++ features/constructs. As for rust its not an object orientated language and its unsafe blocks generally make it easier to at least keep rust code idiomatic. C++ is also a massive kitchen sink of a language with many ways to hide gotchas. Probably the worst thing in C is its null terminated strings but C++ also suffers from that. C is simple, and rust has at least so far made good design choices for the most part. There also choices in the C++ language that are even part of the standard library that seemed like a good idea but with hind sight are not that great of idea. For example operator overloading. Although we are talking a GCC front end so I would be surprised to see both C and C++.
  - eru 6y ago
    > If I was choosing a compiled language for system development right now I would choose C or Rust. I'm not quite sure what systems development has to do with compiler writing? (I assume by system development, you mean something like writing OS kernels etc?) Eg there are good reasons to stay away from automatic memory management when you are writing an OS, you want control over that. But those reasons hardly apply when you run a simple user space program like a compiler.
    - anfilt 6y ago

deleted 6y ago

[deleted]

ncmncm 6y ago

It would be a grave error to have coded the Rust frontend to Gcc in C (or, as written above, "in c"). Gcc is now a C++ codebase, and new components should be coded in modern C++, for better productivity, performance, safety, and maintainability. (You might prefer not to consider modern C++ more productive, performant, safe, and maintainable than C (and reflexively downvote), but the statement remains true: Gcc did transition to C++, for reasons. And, all the improvements that have kept Gcc competitive with Clang were done, since. And, Clang and LLVM are also coded in C++, also for reasons.)

djur 6y ago
gccrs is written in C++, so no worries there.
anfilt 6y ago
I disagree with the idea of using C++. Even with some of its more modern features. If I was choosing a compiled language for system development right now I would choose C or Rust. For starters C++ does not have a stable ABI. Rust plans too have a stable ABI. In either case right now both fall back to the C ABI, but at least its a goal of the rust devs. C++ is going to be harder to boot strap than either Rust core or C when trying to build a compiler for a new system/platform. C probably is the easiest bootstrap of the 3. Rust and C are generally more performant than C++ code. Also in the realm of low end micro controllers C code tends to have the smallest binary image size. In C++ if you need to interact with other languages a lot times your stuck to the C abi which which forces you to avoid a lot C++ features/constructs. As for rust its not an object orientated language and its unsafe blocks generally make it easier to at least keep rust code idiomatic. C++ is also a massive kitchen sink of a language with many ways to hide gotchas. Probably the worst thing in C is its null terminated strings but C++ also suffers from that. C is simple, and rust has at least so far made good design choices for the most part. There also choices in the C++ language that are even part of the standard library that seemed like a good idea but with hind sight are not that great of idea. For example operator overloading. Although we are talking a GCC front end so I would be surprised to see both C and C++.
- eru 6y ago
  > If I was choosing a compiled language for system development right now I would choose C or Rust. I'm not quite sure what systems development has to do with compiler writing? (I assume by system development, you mean something like writing OS kernels etc?) Eg there are good reasons to stay away from automatic memory management when you are writing an OS, you want control over that. But those reasons hardly apply when you run a simple user space program like a compiler.
  - anfilt 6y ago