On 8 April 2013 18:56, Dicebot <[email protected]> wrote: > 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. >
Yeah, I wish I had the time (or patience) to get involved at that level. Breaking the ice in DMD seems daunting, and there's so many satellite jobs I already can't find the time to work on (like std.simd). I'd love to see a concerted push to solve these 2 key problems scheduled and a just get them done some time... 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. > Oh god! Now there's expectation! >_< Yeah... we'll see how that one goes. I'm actually starting to worry I might not have as much exciting experiences to share as people may be hoping... infact, I'm having quite a lot of trouble making that talk seem interesting even to myself. My current draft feels a bit thin. I hope it's not terrible! ;) I think my biggest issue is that a slideshow is not a good place for demonstrating code snippets, and it's hard to illustrate my approach (particularly the curly bits) without showing a bunch of code... so I'll end up just describing it maybe? I dunno. Chances are you're just gonna hear a bunch of the same rants that everyone's heard from me a bunch of times before :P
