40 ms·

Writing a bare-metal RISC-V application in D

141 points by teleforce 3y ago

cassepipe 3y ago
I have also been using D as a better C (Das better C), it just fixes what needs to be fixed in C. Recommend it
- bachmeier 3y ago
  I haven't had a lot of use for betterC, but I'd imagine the recent ability to compile C code makes it a better option. You can add existing C code to your betterC project and get interoperability for free.
ptspts 3y ago
Isn't open, but at least well-documented hardware one of the goals of RISC-V? The article complains a lot that the integrated hardware is horribly underdocumented.
- 5- 3y ago
  risc-v is an instruction set specification. it doesn't concern much beyond that, so there is nothing special about "risc-v hardware ", which contains many other components at vendor's discretion.
  - brucehoult 3y ago
    ... and often uses the same memory-mapped peripherals the same vendor used for their Arm or 8051 or whatever chips. Having good standard open IP for all that stuff would be great, but that's a different project than RISC-V.
- pjmlp 3y ago
  That is the myth, the reality it is only an instruction set, without the actual hardware, and even the ISA itself can be extended with OEM specific instructions.
  - dailykoder 3y ago
    You are right and it's probably as "bad" as you make it sound, but we've come a long way. One tiny step at a time. Maybe one day full open hardware will make it to the mainstream. Let's just dream a bit (and work on it) Edit: I am aware tho, that there will always be some vendor who just copy pastes the open hardware and sells it for cheaper, because they don't have that much R&D cost. And restricting that on whatever level (government, etc) sounds even worse.
    - Max-q 3y ago
      It's always good to dream, but in silicon implementation and production, millions and billions are spent, so having anybody sharing that I think is not very likely. It's a totally different ballgame than software. But let's hope things change in the future so that this dream can come true.
gavinray 3y ago
I learned a lot from this, neat article! One tip about initializing global variables in D -- the common idiom is to use a "shared static this() {}" block. This lets you set immutable variables once at the start of the program. Since this requires the D Runtime, you can't use it in betterC, but you can use a pragma to mark a "crt_constructor" function as an equivalent: pragma(crt_constructor) extern(C) void init_global_state() { // Set BSS pointers up here } I'm not sure whether this works in bare-metal environments (and maybe that's why it's not used).
- CyberDildonics 3y ago
  Why does it need the D runtime to set a variable once? This seems very complicated.
  - gavinray 3y ago
    To be honest, I'm not entirely sure of the technical reason: https://forum.dlang.org/post/sgiyhdnpdyxvigwtrfqk@forum.dlang.org https://forum.dlang.org/post/sgiyhdnpdyxvigwtrfqk@forum.dlan...
  - adrian_b 3y ago
    I suppose that this is needed if you want to guarantee that all the constructors that are executed before main() are executed in a certain order. I have not searched the latest versions of the C++ standard to see if anything has changed, but in the older versions of C++ it was impossible to ensure that the global constructors will be executed in a certain order (to be able to satisfy dependencies between them). For static variables that only have initial values taken from the executable file, without initialization code, I assume that something like this is not necessary.
    - pjmlp 3y ago
      Still the same in regards to C++.
peter_d_sherman 3y ago
>"It turns out D has introduced a mode called betterC1 (sounds exactly like what I want), which essentially disables all language features that require the D runtime. This makes it roughly as easy to use D for bare-metal programming as C." This is a great idea -- for any past, present or future compiled language -- give it a compile mode which disconnects/decouples it from any runtime or libraries or OS dependencies or other special features or container formats (ELF, EXE, .so, .dll, etc., etc.) That is, just the plain vanilla language! (Hey, maybe this mode should be called 'vanilla'? You know, like: '$ mycompiler -vanilla <other command-line parameters here>...?) Anyway, a great idea from D!
- pjmlp 3y ago
  Which like C++, still allows several productive features over C, and unlike both of them, with better defaults.
- KMag 3y ago
  To decouple from the object file format, you want it to dump assembly? Assembly output still marks sections, though I suppose limiting to .text and .data gives you nearly lowest-common-denominator sections. For very simple executable layouts that don't have separate sections, I suppose the assembler could ignore all section markings. Unless your program doesn't take any arguments or inputs, you're still dependent upon ABI specifics for how arguments are passed or how the bootloader passes boot parameters to the program. In short, it's pretty easy to get 90% of what you're proposing, but it gets very complicated very quickly to rid yourself of nearly every platform dependency, particularly if you're supporting a wide range of platforms from 8-bit MCUs without IP-relative addressing to x86-64 and aarch64 to platforms like DEC Alpha AXP where the firmware is essentially a single-tenant hypervisor (and the OS kernel runs in usermode from a hardware prospective).
  - peter_d_sherman 3y ago
    >"In short, it's pretty easy to get 90% of what you're proposing..." It's pretty easy to get 100% of what I'm proposing -- simply use D! <g> :-) (Or, some other past/present/future language authored with the same set of underlying ideas...) https://softwareengineering.stackexchange.com/questions/244476/what-is-decoupling-and-what-development-areas-can-it-apply-to https://softwareengineering.stackexchange.com/questions/2444... https://cloudcomputingtechnologies.com/the-importance-of-decoupling-in-software-development/ https://cloudcomputingtechnologies.com/the-importance-of-dec...

141 points by teleforce 3y ago

cassepipe 3y ago

I have also been using D as a better C (Das better C), it just fixes what needs to be fixed in C. Recommend it

bachmeier 3y ago
I haven't had a lot of use for betterC, but I'd imagine the recent ability to compile C code makes it a better option. You can add existing C code to your betterC project and get interoperability for free.

ptspts 3y ago

Isn't open, but at least well-documented hardware one of the goals of RISC-V? The article complains a lot that the integrated hardware is horribly underdocumented.

5- 3y ago
risc-v is an instruction set specification. it doesn't concern much beyond that, so there is nothing special about "risc-v hardware ", which contains many other components at vendor's discretion.
- brucehoult 3y ago
  ... and often uses the same memory-mapped peripherals the same vendor used for their Arm or 8051 or whatever chips. Having good standard open IP for all that stuff would be great, but that's a different project than RISC-V.
pjmlp 3y ago
That is the myth, the reality it is only an instruction set, without the actual hardware, and even the ISA itself can be extended with OEM specific instructions.
- dailykoder 3y ago
  You are right and it's probably as "bad" as you make it sound, but we've come a long way. One tiny step at a time. Maybe one day full open hardware will make it to the mainstream. Let's just dream a bit (and work on it) Edit: I am aware tho, that there will always be some vendor who just copy pastes the open hardware and sells it for cheaper, because they don't have that much R&D cost. And restricting that on whatever level (government, etc) sounds even worse.
  - Max-q 3y ago
    It's always good to dream, but in silicon implementation and production, millions and billions are spent, so having anybody sharing that I think is not very likely. It's a totally different ballgame than software. But let's hope things change in the future so that this dream can come true.

gavinray 3y ago

I learned a lot from this, neat article! One tip about initializing global variables in D -- the common idiom is to use a "shared static this() {}" block. This lets you set immutable variables once at the start of the program. Since this requires the D Runtime, you can't use it in betterC, but you can use a pragma to mark a "crt_constructor" function as an equivalent: pragma(crt_constructor) extern(C) void init_global_state() { // Set BSS pointers up here } I'm not sure whether this works in bare-metal environments (and maybe that's why it's not used).

CyberDildonics 3y ago
Why does it need the D runtime to set a variable once? This seems very complicated.
- gavinray 3y ago
  To be honest, I'm not entirely sure of the technical reason: https://forum.dlang.org/post/sgiyhdnpdyxvigwtrfqk@forum.dlang.org https://forum.dlang.org/post/sgiyhdnpdyxvigwtrfqk@forum.dlan...
- adrian_b 3y ago
  I suppose that this is needed if you want to guarantee that all the constructors that are executed before main() are executed in a certain order. I have not searched the latest versions of the C++ standard to see if anything has changed, but in the older versions of C++ it was impossible to ensure that the global constructors will be executed in a certain order (to be able to satisfy dependencies between them). For static variables that only have initial values taken from the executable file, without initialization code, I assume that something like this is not necessary.
  - pjmlp 3y ago
    Still the same in regards to C++.

peter_d_sherman 3y ago

>"It turns out D has introduced a mode called betterC1 (sounds exactly like what I want), which essentially disables all language features that require the D runtime. This makes it roughly as easy to use D for bare-metal programming as C." This is a great idea -- for any past, present or future compiled language -- give it a compile mode which disconnects/decouples it from any runtime or libraries or OS dependencies or other special features or container formats (ELF, EXE, .so, .dll, etc., etc.) That is, just the plain vanilla language! (Hey, maybe this mode should be called 'vanilla'? You know, like: '$ mycompiler -vanilla <other command-line parameters here>...?) Anyway, a great idea from D!

pjmlp 3y ago
Which like C++, still allows several productive features over C, and unlike both of them, with better defaults.
KMag 3y ago
To decouple from the object file format, you want it to dump assembly? Assembly output still marks sections, though I suppose limiting to .text and .data gives you nearly lowest-common-denominator sections. For very simple executable layouts that don't have separate sections, I suppose the assembler could ignore all section markings. Unless your program doesn't take any arguments or inputs, you're still dependent upon ABI specifics for how arguments are passed or how the bootloader passes boot parameters to the program. In short, it's pretty easy to get 90% of what you're proposing, but it gets very complicated very quickly to rid yourself of nearly every platform dependency, particularly if you're supporting a wide range of platforms from 8-bit MCUs without IP-relative addressing to x86-64 and aarch64 to platforms like DEC Alpha AXP where the firmware is essentially a single-tenant hypervisor (and the OS kernel runs in usermode from a hardware prospective).
- peter_d_sherman 3y ago
  >"In short, it's pretty easy to get 90% of what you're proposing..." It's pretty easy to get 100% of what I'm proposing -- simply use D! <g> :-) (Or, some other past/present/future language authored with the same set of underlying ideas...) https://softwareengineering.stackexchange.com/questions/244476/what-is-decoupling-and-what-development-areas-can-it-apply-to https://softwareengineering.stackexchange.com/questions/2444... https://cloudcomputingtechnologies.com/the-importance-of-decoupling-in-software-development/ https://cloudcomputingtechnologies.com/the-importance-of-dec...