Published , Updated
It was less than a year ago that I wrote about linker hacking the
runtime out of D code so that it could work as “better C” code, but things have already changed a lot since then. A
few days ago Walter Bright announced a new, improved
-betterC switch, which can now do a lot of the stuff that
needed ugly hacking before.
Published
D’s runtime is a recurring hot topic, but there’s obviously a lot of confusion about what the D runtime even is. I gave a quick explanation during my talk at DConf 2017, but I decided to write a blog post because I’ve seen confusion since then, and because I think blog posts are just a much better format for technical stuff, anyway.
Published
Just a quick update because I’ve been too busy to write much recently.
I’m giving a talk at DConf 2017 in Berlin! D’s been growing strongly in the past five years, and DConf’s been growing dramatically since the first one in 2013, so it’s pretty exciting to get involved. No, really. I often give tech talks at no-name events here in Sydney, but I’m half scared I’ll wet my pants on stage with a lineup like this — in my university days, I used to read all the C++ books by Andrei Alexandrescu and Scott Meyer that I could get my hands on.
If you have a DConf ticket, I look foward to seeing you there. If not, then you can look forward to watching the videos :)
Instead of writing a real blog post, I’m dropping a link to this classic about backwards compatibility nightmares, which you might like if you thought the mess that’s x86 BIOS booting was interesting. It’s a chapter from The Old New Thing, a book by Raymond Chen from Microsoft, based on his blog. Raymond Chen has spent a lot of his career making sure new versions of Windows can still run old software, no matter how badly the old software abused APIs and deserved to crash. Most of the technical details belong to the 90s, but there are plenty of morals for software development in the real world today. If you can read that chapter without ever wanting to weep for the industry, you’re stronger than I am.
Published , Updated
This post is somewhat outdated. It’s still relevant, but some of the problems I discussed have already been fixed.
Previously I talked about booting a PC directly to bare metal D and said that Hello World is never a strong test of a programming environment. To get a better feel for what D is really like on bare metal, I wrote Xanthe, a simple, classic-style vertical scrolling shooter game with no dependencies on either the D or C runtime.
Published , Updated
After my previous post on using D for C-like programming, I wondered about going deeper. What’s the minimum it would take to run C-like D code on a PC? Could it run straight from a BIOS bootloader?
If you seriously want to make an OS, you’re much better off using an existing bootloader like U-Boot or GRUB, or at least using UEFI. But doing it this way is interesting because the x86 PC has an insane level of backwards compatibility, and booting from the BIOS to a modern high-level language is like doing an archealogical dig through the past 40 years of computing history.
Published , Updated
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.
Published
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:
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.
Published
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.
Published
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.
The FSM didn’t do any debouncing, so the low-level driver had to do that before passing button up/down events to it.
