Disable GC entirely

[Dicebot]

On Monday, 8 April 2013 at 08:31:29 UTC, Manu wrote:
> 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.

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.

I have done quite a research on this topic and have a lot to say 
here :)

> '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'.

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.

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.