Improve D's support for esoteric platforms

[Herringway]

Description

I frequently use D to target some highly unusual platforms. Most recently, I've managed to compile a hello world for the NES console, with its 6502 CPU! Previously, I have also compiled games for the nintendo GBA console, and I'm preparing to do the same for the Sega Genesis (m68k), SNES (65816) and Game Boy (Z80). These are all possible with existing tools and compilers, however, there are a number of deficiencies that have been getting in the way and making things harder than they need to be.

1. The frontend needs to have the platform's details hardcoded into it. This means either a lot of recompiling for the compiler (not fun for LDC or GDC) or just compiling to IR and accepting that some details may not be ideal. Moving this configuration into config files (a la rust's target specs) would simplify this greatly. Note that even if the compiler can't actually compile for the CPU in question, with IR output it may still be usable; my current process for the NES is to compile to IR with LDC and feed it to llvm-mos's clang.
2. D Runtime. Completely unusable on bare metal. betterC is painful. PAYG runtime is a good start. Module-level else static assert(0); needs to be eliminated in favour of something that only asserts if used (possibly else immutable noreturn Foo;, though there are some showstopper bugs atm). There may be no C runtime to fall back on, so native D versions of several things will be needed (time_t in particular seems to come up a lot).
3. More control over dub's linking step, including the possibility of skipping it entirely. Some platforms have unusual linking requirements and may provide their own linkers. Compiling to IR would be nice to have as well.
4. Null checks. D relies on an OS to provide them. Bare metal does not provide them. A null function pointer on a system where $0 is open bus is fun to debug...

What are rough milestones of this project?

Each of these are independent and can be finished in any order.

How does this project help the D community?

D is a highly attractive option for low level programming, being able to provide safe and efficient access to hardware with a familiar syntax.

Recommended skills

• Familiarity with the D compiler frontend, druntime or dub.
• Not easily discouraged

Point of Contact

Unsure. I can only offer the experience I mentioned above.

References

Issue #14100
Issue #14101 and H1 2015 Priorities and Bare-Metal Programming

[kassane]

I had performed a test on ldc2 using llvm-mos.
The built examples run normally, but bit prediction is complicated for architectures below 32-bit.

I tried to make some changes on the LLVM backend but the result was always the same. Maybe the dmd frontend needs to adapt support.

• Struct size mismatch for mos6502 kassane/dlang-mos-hello-world#1

[Herringway]

I had performed a test on ldc2 using llvm-mos. The built examples run normally, but bit prediction is complicated for architectures below 32-bit.

I tried to make some changes on the LLVM backend but the result was always the same. Maybe the dmd frontend needs to adapt support.

• Struct size mismatch for mos6502 kassane/dlang-mos-hello-world#1

I'm glad that I'm not the only one interested in this. As you've discovered, there's quite a few things that need to be addressed before writing code for these platforms can be considered frictionless. Just getting a hello world for the NES compiled was troublesome enough.