Disable GC entirely

Manu turkeyman at gmail.com
Mon Apr 8 02:25:37 PDT 2013


On 8 April 2013 18:56, Dicebot <m.strashun at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130408/a43011e5/attachment-0001.html>


More information about the Digitalmars-d mailing list