Getting Embedded with D (the programming language)

Question

I like a lot of what I've read about D.

• Unified Documentation (That would make my job a lot easier.)
• Testing capability built in to the language.
• Debug code support in the language.
• Forward Declarations. (I always thought it was stupid to declare the same function twice.)
• Built in features to replace the Preprocessor.
• Modules
• Typedef used for proper type checking instead of aliasing.
• Nested functions. (Cough PASCAL Cough)
• In and Out Parameters. (How obvious is that!)
• Supports low level programming - Embedded systems, oh yeah!

However:

• Can D support an embedded system that not going to be running an OS?
• Does the outright declearation that it doesn't support 16 bit processors proclude it entirely from embedded applications running on such machines? Sometimes you don't need a hammer to solve your problem.
• Garbage collection is great on Windows or Linux, but, and unfortunately embedded applications sometime must do explicit memory management.
• Array bounds checking, you love it, you hate it. Great for design assurance, but not alway permissable for performance issues.
• What are the implications on an embedded system, not running an OS, for multithreading support? We have a customer that doesn't even like interrupts. Much less OS/multithreading.
• Is there a D-Lite for embedded systems?

So basically is D suitable for embedded systems with only a few megabytes (sometimes less than a magabyte), not running an OS, where max memory usage must be known at compile time (Per requirements.) and possibly on something smaller than a 32 bit processor?

I'm very interested in some of the features, but I get the impression it's aimed at desktop application developers.

What is specifically that makes it unsuitable for a 16-bit implementation? (Assuming the 16 bit architecture could address sufficient amounts of memory to hold the runtimes, either in flash memory or RAM.) 32 bit values could still be calculated, albeit slower than 16 bit and requiring more operations, using library code.

Answer 1

I have to say that the short answer to this question is "No".

• If your machines are 16 bit, you'll have big problems fitting D into it - it is explicitly not designed for it.
• D is not a light languages in itself, it generates a lot of runtime type info that normally is linked into your app, and that also is needed for typesafe variadics (and thus the standard formatting features be it Tango or Phobos). This means that even the smallest applications are surprisingly large in size, and may thus disqualify D from the systems with low RAM. Also D with a runtime as a shared lib (which could alleviate some of these issues), has been little tested.
• All current D libraries requires a C standard library below it, and thus typically also an OS, so even that works against using D. However, there do exist experimental kernels in D, so it is not impossible per se. There just wouldn't be any libraries for it, as of today.

I would personally like to see you succeed, but doubt that it will be easy work.

Answer 2

First and foremost read larsivi's answer. He's worked on the D runtime and knows of what he's talking about.

I just wanted to add: Some of what you asked about is already possible. It won't get you all the way, and a miss is as good as a mile here but still, FYI:

Garbage collection is great on Windoze or Linux, but, and unfortunately embedded apps sometime must do explicite memory management.

You can turn garbage collection off. The various experimental D OSes out there do it. See the std.gc module, in particular std.gc.disable. Note also that you do not need to allocate memory with new: you can use malloc and free. Even arrays can be allocated with it, you just need to attach a D array around the allocated memory using a slice.

Array bounds checking, you love it, you hate it. Great for design assurance, but not alway permissable for performance issues.

The specification for arrays specifically requires that compilers allow for bounds checking to be turned off (see the "Implementation Note"). gdc provides -fno-bounds-check, and in dmd using -release should disable it.

What are the implications on an embedded system, not running an OS, for multithreading support? We have a customer that doesn't even like interrupts. Much less OS/multithreading.

This I'm less clear on, but given that most C runtimes allow turning off multithreading, it seems likely one could get the D runtime to disable it as well. Whether that's easy or possible right now though I can't tell you.