H1 2015 Priorities and Bare-Metal Programming

[Johannes Pfau via Digitalmars-d]

Am Sun, 01 Feb 2015 02:11:42 -0800
schrieb Walter Bright <newshound2 at digitalmars.com>:

> On 2/1/2015 1:38 AM, Timo Sintonen wrote:
> > The one of major issues is: how to access hardware. We need a
> > language feature to access hardware registers. This has been
> > discussed twice. Both time you rejected anything but your own idea
> > of library functions. You rejected anything anybody said. No
> > serious programmer will write code that way. It worked in 80's when
> > we had an uart with three registers 8 bit each. Now an usb or
> > ethernet peripheral may have 100 registers 32 bit each.
> 
> core.bitop.volatileLoad() and volatileStore() are implemented, and do
> the job. They are compiler intrinsics that result in single
> instructions. They support 8, 16, 32 and 64 bit loads and stores.

I think everybody agreed that these low-level primitives can't be used
in end-user code. We can generate nice wrappers (nicer than C code),
which perform as well as C code, but only with force-inline _and_
enabled optimizations (we essentially need heavy constant folding).

We also need a pragma(address) to complement pragma(mangle).

Here's some proof-of concept running D on an 8bit AVR:
https://github.com/D-Programming-microD/avr-playground/blob/master/src/test.d

WIP implementation of Volatile!T and a register string mixin:
http://pastebin.com/sb58UW00

Volatile!T: Line 16
Volatile!T usage: Line 73

generateRegisterType: Line 150
usage: Line 353
sample output: 356


So I'd say there are not too many language problems, the main problem
is runtime/compiler interaction:

* If you don't want to use any runtime at all that's actually the
  easier part. We'd need to implement a little more of betterC but this
  can be done easily. Mike would prefer the compiler to autodetect the
  capabilities of the runtime (implemented hooks) instead of compiler
  switches. That'd be better but some more work.

* Using only part of druntime is ugly. The one thing most people would
  probably like to strip out is the GC, but keep exception handling,
  threads, ... But the GC is everywhere: core.demangle doesn't work
  without, backtraces, exceptions, threads. Right now you either use
  all of druntime or nothing but it's not possible to use parts of
  druntime only, it's not modular enough.