On Monday, 8 April 2013 at 08:31:29 UTC, Manu wrote:Yes, this is one of important steps in solution and some good work has been already done on topic. Main issue is that it won't be any convenient unless second step is done - making core language/compiler more friendly to embedded needs so that you can both implement custom druntime AND have solid language. Ability to track/prohibit GC allocations is one part of this. Static array literals is another. Most likely you'll also need to disable RTTI like it is done in C++/Embedded projects I have seen so far.
D for embedded, like PROPER embedded (microcontrollers, or even raspberry
pi maybe?) is one area where most users would be happy to use a custom
druntime like the ones presented earlier in this thread where it's
strategically limited in scope and designed not to allocate.
I have done quite a research on this topic and have a lot to say here :)Sure. Actually, executable size is an easy problem to solve considering custom druntimed mentioned before. Most of size in small executables come from statically linked huge druntime. (Simple experiment: use "-betterC" switch and compile hello-world program linking only to C stdlib. Same binary size as for C analog). Once you have defined more restrictive language subset and implemented minimal druntime for it, executable sizes will get better. Template issue is not an issue on their own, but D front-end is very careless about emitting template symbols (see my recent thread on topic). Most of them are weak symbols but hitting certain cases/bugs may bloat executable without you even noticing that.
'Really
embedded' software tends not to care so much about portability.
A bigger problem is D's executable size, which are rather 'plump' to be
frank :P
Last time I tried to understand this, one main issue was objectfactory, and
the inability to strip out unused classinfo structures (and other junk).
Any unused data should be stripped, but D somehow finds reason to keep it
all. Also, template usage needs to be relaxed. Over-use of templates really
bloats the exe. But it's not insurmountable, D could be used in 'proper
embedded'.
None of those issues is unsolvable show-stopper. But there does not seem an interest to work in this direction from current dmd developers (I'd be glad to be mistaken) and dmd source code sets rather hard entry barrier.
You see, game developers are not the only ones with real-time requirements that are freaking tired of working with 40-year obsolete languages :) I am very interested in this topic. Looking forward to watching your DConf presentation recording about tricks used to adapt it to game engine by the way.