LLVM compiles C, C++, Rust, etc. into an intermediate language and then compiles that language into assembly for the target platform. I’m not sure if gcc uses an intermediate language or not. Either way, the compiler can compile any of its supported languages into any of its target platforms.
For Rust, you will probably need to look into “no_std” for systems that don’t have a typical libc setup.
anton@lemmy.blahaj.zone
on 19 Mar 20:26
nextcollapse
I think both gcc and clang are roughly build around the C memory model.
If you want to interface with hardware you probably do volatile reads and writes to specific memory addresses.
You should be able to compile for most gcc supported platforms.
Rust has support for many embedded targets. I can personally vouch for the MSP430. Rust compiles down to an intermediate language which can then use the same compilers and linkers as C. For instance when compiling Rust for the MSP430, GCC-MSP430 is actually part of the toolchain.
Probably a silly question, but why isn’t this intermediate representation of LLVM created in hardware, or is it?
Redjard@lemmy.dbzer0.com
on 19 Mar 23:03
nextcollapse
I don’t understand your question.
sugar_in_your_tea@sh.itjust.works
on 20 Mar 00:49
nextcollapse
There was (is?) an interpreter for llvm code, but code at that level hasn’t really gone through optimization, which will be specific to each compile target.
bitcrafter@programming.dev
on 20 Mar 02:08
collapse
The IR is designed to be easy to optimize, not easy for a real machine to execute. Among other things, it assumes it has access to an infinite number of registers so that it never needs to (and in fact is not allowed to) write a new value into a previously used register.
Thanks. It sounds like an interesting architecture to look into how the rest is abstracted within the CPU basics like ALU, timers, flags, and interrupts
bitcrafter@programming.dev
on 23 Mar 18:15
collapse
It’s not really an architecture that is intended to map into anything in existing hardware, but having said that, Mill Computing is working on a new extremely unconventional architecture that is a lot closer to this; you can read more about it here, and specifically the design of the register file (which resembles a convener belt) is discussed here.
I was thinking of stack machines when I asked about LLVM in hardware. It is interesting to see them mentioned here. At the end of the second link to the conveyer belt description, it calls the belt a programming model. So is this actually implemented anywhere in conventional hardware. The belt and the way registers are used makes intuitive sense to me. I do not understand exactly where the ALU sits or how flags and interrupts fit in.
I get rather confused going from the basics of Ben Eater/Melvino’s 8-bit processor to pipelines and out of order execution. This makes more sense in my surface understanding so far. Thanks for sharing.
threaded - newest
How do languages in GCC map to hardware? Could I, for instance, write in Rust and compile for GCC-MSP430, or a 68k architecture?
LLVM compiles C, C++, Rust, etc. into an intermediate language and then compiles that language into assembly for the target platform. I’m not sure if gcc uses an intermediate language or not. Either way, the compiler can compile any of its supported languages into any of its target platforms. For Rust, you will probably need to look into “no_std” for systems that don’t have a typical libc setup.
I think both gcc and clang are roughly build around the C memory model.
If you want to interface with hardware you probably do volatile reads and writes to specific memory addresses.
You should be able to compile for most gcc supported platforms.
Rust has support for many embedded targets. I can personally vouch for the MSP430. Rust compiles down to an intermediate language which can then use the same compilers and linkers as C. For instance when compiling Rust for the MSP430, GCC-MSP430 is actually part of the toolchain.
Thanks. What is this intermediate language you speak of? That sounds curious if it could be approached casually.
https://en.wikipedia.org/wiki/LLVM#Intermediate_representation
Probably a silly question, but why isn’t this intermediate representation of LLVM created in hardware, or is it?
I don’t understand your question.
There was (is?) an interpreter for llvm code, but code at that level hasn’t really gone through optimization, which will be specific to each compile target.
The IR is designed to be easy to optimize, not easy for a real machine to execute. Among other things, it assumes it has access to an infinite number of registers so that it never needs to (and in fact is not allowed to) write a new value into a previously used register.
Thanks. It sounds like an interesting architecture to look into how the rest is abstracted within the CPU basics like ALU, timers, flags, and interrupts
It’s not really an architecture that is intended to map into anything in existing hardware, but having said that, Mill Computing is working on a new extremely unconventional architecture that is a lot closer to this; you can read more about it here, and specifically the design of the register file (which resembles a convener belt) is discussed here.
I was thinking of stack machines when I asked about LLVM in hardware. It is interesting to see them mentioned here. At the end of the second link to the conveyer belt description, it calls the belt a programming model. So is this actually implemented anywhere in conventional hardware. The belt and the way registers are used makes intuitive sense to me. I do not understand exactly where the ALU sits or how flags and interrupts fit in.
I get rather confused going from the basics of Ben Eater/Melvino’s 8-bit processor to pipelines and out of order execution. This makes more sense in my surface understanding so far. Thanks for sharing.