D Cannot Be Used for Real Time / Low Latency Systems? - Of course it can!

Satoshi via Digitalmars-d digitalmars-d at puremagic.com
Fri Dec 25 05:49:33 PST 2015


On Friday, 18 December 2015 at 10:41:46 UTC, Claude wrote:
>> Bottom line is, if you are competent enough, you can be 
>> successfull with D, just like you would be if you were using 
>> C/C++. D's superior compile-time meta programming allows you 
>> to express zero cost abstractions give you the edge that makes 
>> things more enjoyable.
>>
>> There are several open-source kernels written in D that are 
>> proof of the above:
>> https://github.com/Vild/PowerNex
>> https://github.com/Bloodmanovski/Trinix
>> https://github.com/xomboverlord/xomb
>> Adam Ruppe has a chapter about bare-metal programming with D 
>> in his Cookbook.
>
> I do think D may be a perfectly valid real-time language. And 
> indeed, I believe that the GC is not an issue (you can disable 
> it, question solved).
>
> However, is D a proper Embedded System language? I'm not pretty 
> sure it's there yet.
> Plain C rules the world of embedded systems. All the RTES 
> programmers I've met are reluctant to even use C++.
>
> If you cannot program a 16-bit PIC in D, then D will not 
> replace C at all (but is it meant to?).
>
> The open-source kernels above are targeted at PC architecture.
> I know some work have been done to make bare-metal OS targeted 
> at ARM. I don't know what's the state of those projects, and 
> I'd love to make my own once I have time (based on Rasberry Pi 
> for instance).
>
> To validate D as a proper Real-Time Embedded System, one would 
> have to make a proper bare-metal OS a ARMv5 chip (for example). 
> Write your Interrupt Service Routines in assembly calling D 
> functions, program the MMU, the different hardware blocks 
> (UART, INTC, USB etc).
> And the API of such an OS would benefit of the expressiveness 
> power of D (templates, traits UDA etc) and not just be a 
> C-style clone, with an efficiency similar to C (at least same 
> CPU load).


Hi, D should be used for low level/real-time programming.
But there is a lot of exceptions in it and you cannot use entire 
D extensions like synchronized, array relocations, shared, and 
many operations on array like "string" ~  "join", etc.

Im working on modular, microkernel "RTOS" based on sync messages 
passing in D and there is not any big problem with using D as a 
low level language for OS development.

(Im creator of Trinix BTW)


More information about the Digitalmars-d mailing list