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.
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.
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.
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.
How do languages in GCC map to hardware? Could I, for instance, write in Rust and compile for GCC-MSP430, or a 68k architecture?
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?
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.
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.
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.