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.