21–30 of 300 posts
Earlier quoted context omitted.
Multiple implementations of a standard help shine light into dark corners.
Indeed, but I think they should first create a standard?
ISO will stamp any fantasy like OOXML, but that doesn't mean the standard is useful.
Earlier quoted context omitted.
GCC already has compiler front ends for Fortran, Ada, Go, and formerly Java. Adding another language, especially one as popular as Rust, couldn't hurt.
Huh, I didn't realize that
What does a "front-end" mean exactly, in this context?
At a high level, GCC and LLVM are divided into two ends: the front and the back. The front end takes the source code and turns it into some form that's language agnostic (e.g. LLVM bitcode). The back end takes those structures and turns it into machine code. This allows the compiler to be modular. Old compilers didn't use this concept. So a C->x86 compiler and a Fortran->x86 one couldn't share code as easily. And if…
Earlier quoted context omitted.
At a high level, GCC and LLVM are divided into two ends: the front and the back. The front end takes the source code and turns it into some form that's language agnostic (e.g. LLVM bitcode). The back end takes those structures and turns it into machine code. This allows the compiler to be modular. Old compilers didn't use this concept. So a C->x86 compiler and a Fortran->x86 one couldn't share code as easily. And if…
Would it ever make sense to build a chip/vm (something like the JVM) designed to run the intermediate code directly?
Why would someone want this? (Honest question)
Gcc has more stable hardware targets than llvm, for starters.
The main benefit of a GCC front-end is to move Rust beyond a single vendor, and shakeout ambiguities in the (informal) language specification.
Why would someone want this? (Honest question)
The main source of interest for GCC Rust is because GCC targets more platforms than LLVM. A partially-overlapping interest is using Rust in Linux: Linux targets non-LLVM platforms, but is also deeply tied to GCC and Rust-for-Linux would have a lower barrier to entry if it doesn't require a second toolchain. Long-term, it's considered a strong signal for the health and viability of Rust if it's not strictly tied to on…
Earlier quoted context omitted.
At a high level, GCC and LLVM are divided into two ends: the front and the back. The front end takes the source code and turns it into some form that's language agnostic (e.g. LLVM bitcode). The back end takes those structures and turns it into machine code. This allows the compiler to be modular. Old compilers didn't use this concept. So a C->x86 compiler and a Fortran->x86 one couldn't share code as easily. And if…
Would it ever make sense to build a chip/vm (something like the JVM) designed to run the intermediate code directly?
LLVM's original purpose was something analogous to the JVM, but it's obviously evolved to be more of a compiler platform, debugging toolchain, etc these days
(No direct hardware support, though, as cool as that sounds)
Earlier quoted context omitted.
At a high level, GCC and LLVM are divided into two ends: the front and the back. The front end takes the source code and turns it into some form that's language agnostic (e.g. LLVM bitcode). The back end takes those structures and turns it into machine code. This allows the compiler to be modular. Old compilers didn't use this concept. So a C->x86 compiler and a Fortran->x86 one couldn't share code as easily. And if…
Would it ever make sense to build a chip/vm (something like the JVM) designed to run the intermediate code directly?
Meanwhile normal instruction sets are just a bytecode optimized to run quickly.
LLVM-IR at least also isn't stable, so not a good thing to bake into a chip - but you could conceivably make a stable intermediate language.
Why would someone want this? (Honest question)