<div dir="ltr">On 8 April 2013 18:56, Dicebot <span dir="ltr"><<a href="mailto:m.strashun@gmail.com" target="_blank">m.strashun@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">On Monday, 8 April 2013 at 08:31:29 UTC, Manu wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
D for embedded, like PROPER embedded (microcontrollers, or even raspberry<br>
pi maybe?) is one area where most users would be happy to use a custom<br>
druntime like the ones presented earlier in this thread where it's<br>
strategically limited in scope and designed not to allocate.<br>
</blockquote>
<br></div>
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.<br>

<br>
I have done quite a research on this topic and have a lot to say here :)<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
'Really<br>
embedded' software tends not to care so much about portability.<br>
A bigger problem is D's executable size, which are rather 'plump' to be<br>
frank :P<br>
Last time I tried to understand this, one main issue was objectfactory, and<br>
the inability to strip out unused classinfo structures (and other junk).<br>
Any unused data should be stripped, but D somehow finds reason to keep it<br>
all. Also, template usage needs to be relaxed. Over-use of templates really<br>
bloats the exe. But it's not insurmountable, D could be used in 'proper<br>
embedded'.<br>
</blockquote>
<br></div>
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.<br>

<br>
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.<br>
</blockquote><div><br></div><div style>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).</div>
<div style>I'd love to see a concerted push to solve these 2 key problems scheduled and a just get them done some time...</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

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

</blockquote></div><br></div><div class="gmail_extra" style>Oh god! Now there's expectation! >_<</div><div class="gmail_extra" style>Yeah... we'll see how that one goes.</div><div class="gmail_extra" style>
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! ;)</div>
<div class="gmail_extra" style><br></div><div class="gmail_extra" style>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.</div>
<div class="gmail_extra" style><div class="gmail_extra">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</div></div></div>