Completely Ripping the Runtime out of D

Published , Updated

Tags: and

Update: a lot of this information is already outdated (good news!). See my latest update, and my second update.

Most high level languages are built as a layer on top of C. That includes out-of-the-box D, but it doesn’t have to be that way: D is a plausible candidate for a “better C”. I think this is a pretty cool idea, so I’ve been experimenting with it to see what’s possible. The dmd compiler (and very soon the ldc2 compiler) has a -betterC command line flag that’s intended to remove dependencies on the D runtime. Unfortunately, it’s still extremely rudimentary — the docs only promise it “omit[s] generating some runtime information and helper functions” — so in practice it’s hard to write non-trivial D code without getting runtime dependencies, even if you don’t need them in theory.

With a little linker hacking, it’s possible to rip these unnecessary dependencies out of compiled D code. As an example, I’ll completely remove all references to the D runtime out of some compiled D code so that it can link directly to some C, as if it were C code to begin with.

On Not Optimising for Last Century's Hardware


Tags: , , and

Once upon a time I wrote a super-optimised algorithm for rotating data in an array. At least, it was meant to be super-optimised, but its real-world performance turned out to be terrible. That’s because my intuition about performance was stuck in the 20th century:

  1. Break a program down into basic operations like multiplication and assignment
  2. Give each operation a cost (or just slap on an O(1) if you’re lazy)
  3. Add up all the numbers
  4. Try to make the total in step #3 small

A lot of textbooks still teach this “classic” thinking, but except for some highly constrained embedded systems, it just doesn’t work that well on modern hardware.

Function Attributes and the D ABI


Tags: , and

The D programming language has a bunch of built-in attributes like pure and nothrow. I was wondering how things like libraries might break if function attributes changed between versions, so I gave it a try.

The Enterprise Pushbutton


Tags: , and

Let’s talk about a hardware driver for a pushbutton. A pushbutton driver isn’t as completely trivial as it might sound because you need debouncing logic to ensure a crisp on/off signal, but it’s hard to imagine how it might need more than about 100 lines of C code.

After working on this particular embedded system, I didn’t need to stress my imagination any more. This pushbutton driver was modelled as an explicit finite state machine, and all the possible states and transitions were specified in a spreadsheet. Then there was a python script that processed this spreadsheet and generated state table data as C code. This was linked to an FSM evaluator in C. The FSM was controlled by a bare-metal driver and triggered callbacks on each state transition.

Most of the callbacks were marked “not yet implemented”. In fact, only two states were even reachable: BUTTON_UP and BUTTON_DOWN. Eventually the entire project was canned, but not because of missing support for BUTTON_TIMEOUT or any of the other states.

Oh, yeah, the FSM didn’t do any debouncing, so the low-level driver had to do that before passing button up/down events to the FSM.