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.

Wenda

larsivi is one of the developers of the Tango library, so give serious credence to his answer too. – Management

Oh and "D-Lite" is a great name :). I hope someone uses it. – Management

Possible dupe: #1114438 – Monotone

It's simalar, but this is somewhat more specific. – Wenda

Also, embedded programming does not have to imply real time programming. – Tunnell

I suppose you're right, but I haven't had luck to work on one that wasn't. Embedded systems emplies a special purpose system not used for general purpose computing applications. i.e. A dumb cell phone, for the most part. An IPhone, na, it's a palm top computer with telephone capability. Crap I still have some old dev systems that with lower specs than the IPhone, we can't get rid of them cause the tools don't run on a modern PC. – Wenda

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.

Tunnell

We have some clients that are very concerned with program verification and program correctness. Some of D's features seem spot on for that. As far as the "standard C lib" most embedded dev systems have a certain amount of support for that, they may say you have to fill in low level support for I/O, kinda like doing callbacks, but you typically don't do file access anyway. – Wenda

A "lite" set of libaries may eliminate some of the bulk. I don't NEED alot features that would be applicable to an OS based system. However ADA also supports Multitasking and that does imply a large runtime support library on an embedded system. Embedded ADA runtimes practically came with an OS just to support multitasking. – Wenda

If you are willing/capable of putting some effort into this, I would be interested in co-operating. – Tunnell

Willing yes. Capable, maybe after I get my head around the language. Right now, my understanding is more or less just the "surface" material. I need to get it installed in a environment where I can "play" and get the syntax and features to sink in. – Wenda

@Tunnell Is this still the status quo in 2014? – Dufresne

@Dufresne I wouldn't know, I haven't really been involved with D in the most recent years. – Tunnell

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.

Management

I did read his post. As a matter of fact I even commented to it! :) Disabling bounds checking in the compiler is good, but I think it would be nice to specify bounds checking off for specific pieces of code, and use it in others that are't timing critical for safty purposes. In most case I don't even use malloc, I preallocate sometimes to specific memory addressing (i.e. internal vs external ramblocks) via the linker. – Wenda

"I did read his post." Sorry Pete, not meant to sound pushy! When I posted you didn't have comments (we were editing at the same time). But I mainly meant to note to anyone else who might read this answer that they should read his first, and on StackOverflow answers can get re-ordered. – Management

"Specify bounds checking off for specific pieces of code". I agree. I don't know if there's any facility for that. – Management

It's a hack but you can turn bounds checking on and off on a per file bases and link the mix together. This might force some "odd" codeing style constraints. – Truelove

@quark, no worrys note the smiley face. @Truelove as long as the compiler doesn't lose it's mind when you do that it doesn't sound unreasonable. In general there is some ulgyness associated with hardware programming that most languages don't have nice syntax for. i.e. It would be nice to be able to tell the compiler that a variable or structure existed ontop of memory mapped registers, as a volatile read only value. – Wenda

If you deactivate the GC (and threading portions) of the runtime, it should be relatively easy to make changes towards single threadedness. Doing away with the GC precludes the use of certain array languages features though. Another option would be to rewrite the GC into a simple on-demand service, such that the application always holds direct control over it, both for allocation and collection purposes. – Tunnell

Is the runtime written in D? Actually I should really get more familar with the language, before I assume to capable of significant modifications to it's internals. Right now, I'm just kind of evaluating it's functionality, and suitability for the type of work I do. – Wenda

Pete: Yes the actual runtime is written in D, but it's interface is a C interface to allow for bootstrapping implementations over ubiquitous C run times. Checkout dsource.org/projects/druntime – Management

Answer 3

The answers to this question are outdated:

Can D support an embedded system that not going to be running an OS?

D can be cross-compiled for ARM Linux and for ARM Cortex-M. Some projects aim at creating libraries for Cortex-M architectures like MiniLibD for the STM32 or this project which uses a generic library for the STM32. (You could implement your own minimalistic OS in D on ARM Cortex-M.)

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.

No, see answer above... (But I would not expect that "smaller" architectures than Cortex-M will be supported in the near future.)

Garbage collection is great on Windows or Linux, but, and unfortunately embedded applications sometime must do explicit memory management.

You can write Garbage Collection free code. (The D foundation seems to aim at a "GC free compliant" standard library Phobos but that is work in progress.)

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

(As you said this depends on your "personal taste" and design decisions. But I would assume an acceptable performance overhead for bound checking due to the background of the D compiler developers and D's design aims.)

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.

(What is the question? One could implement mutlithreading using D's language capabilities e.g. like explained in this question. BTW: If you want to use interrupts consider this "hello world" project for a Cortex-M3.)

Is there a D-Lite for embedded systems?

The SafeD subset of D targets at the embedded domain.

Irenairene