On 6/15/20 8:21 AM, Adam D. Ruppe wrote:
> On Monday, 15 June 2020 at 08:54:45 UTC, Dibyendu Majumdar wrote:
>> I was wondering whether the runtime can be minimized to only support the GC. Or is that already the case, i.e. the D runtime is already the minimum needed for GC?
> 
> Eh, a good bulk of the d runtime is GC support, it would be hard to pull the gc out without most the rest of it.

How difficult would be to arrange things such that absolutely nothing in the GC makes it in the final ninary if not used?

My recollection is that we currently have a layering on top of the GC that is based on a misunderstanding of how linkers work, and also awkward and unnecessary.

Cutting that off and putting some good work into a self-loading GC (linked in if and only if used) would be amazing work.

On 6/15/20 4:50 PM, Walter Bright wrote:
> On 6/15/2020 3:16 AM, IGotD- wrote:
>> As we have discussed before, the best way for this in my opinion is to have an abstract interface in druntime for the OS functions. This way we could stub those functions that the programmer doesn't need.
> 
> If you include the line:
> 
>     extern (C) void printf() { }
> 
> somewhere in your code, printf() will *not* get linked in.
> 
> An extra interface layer is not necessary.

Word. Any work on reducing druntime needs to be based on a good understanding of how linking works.

On Tuesday, 16 June 2020 at 01:16:27 UTC, Andrei Alexandrescu wrote:
> On 6/15/20 4:50 PM, Walter Bright wrote:
>> On 6/15/2020 3:16 AM, IGotD- wrote:
>>> As we have discussed before, the best way for this in my opinion is to have an abstract interface in druntime for the OS functions. This way we could stub those functions that the programmer doesn't need.
>> 
>> If you include the line:
>> 
>>     extern (C) void printf() { }
>> 
>> somewhere in your code, printf() will *not* get linked in.
>> 
>> An extra interface layer is not necessary.
>
> Word. Any work on reducing druntime needs to be based on a good understanding of how linking works.

hi,

many pepole is requiring that the D runtime needs to be minimal. Yes, this "is a linking problem" just if you're always using "normal" or "rich" OS, things matter if you trying to using D in the microcontroller target such as STM32F4 or something similar, these platfrom has hundreds of KB ram and maybe 1MB of flash memory, it's powerfull enogh for running the D language.

if you trying to build a betterC programing on these platforms(only RTOS or no OS at all), it shows that D runtime is requring some thing that only Rich-OS have.

the rust and zig programming language is doing better in this situation, the D runtime can be made only need to requiring ANSI C stdlib (like nim 'any') and then the D runtime is more portable.


thanks!
----
binghoo dang

On 6/16/20 10:09 PM, dangbinghoo wrote:
> the D runtime can be made only need to requiring ANSI C stdlib (like nim 'any') and then the D runtime is more portable.

That would be nice, and possible if most parts of druntime would be templated and others would only be pulled in if used. It boils down to finding the talented folks to make it happen.

On Wednesday, 17 June 2020 at 02:29:44 UTC, Andrei Alexandrescu wrote:
> possible if most parts of druntime would be templated and others would only be pulled in if used.

I actually don't think it is even necessary to template it. If you had independent modules written with minimal dependencies, there's several things that make it work automatically: dmd -i can compile as-needed. Linkers can leave things out of exes from static libs. Etc.

My arsd package as like 78 modules now. But I'm strict about them not importing each other unless absolutely necessary. You can use most of them individually without caring about the other 77 (but if you do reference it, it gets auto-imported, e.g. Document.fromUrl brings in http... but if you never call that, no need for the http module at all in your build)

There's been some decent work in dmd to support this for language features too, but from the other direction. If a feature isn't present in object.d, it won't reference it. That little glue layer might be templatized so it is available, but not used unless needed... then from there it just imports a traditional module.

Pretty sure good chunks of that would work.

druntime and phobos too have problems of intertwined imports that would take a lot of work to clean up though.

On Tuesday, 16 June 2020 at 01:12:10 UTC, Andrei Alexandrescu wrote:
> How difficult would be to arrange things such that absolutely nothing in the GC makes it in the final ninary if not used?

I don't know... I haven't looked at it all recently. I know the GC is used in part of the program initialization right now though (as are threads and other things) so that'd probably all have to change.

> My recollection is that we currently have a layering on top of the GC that is based on a misunderstanding of how linkers work, and also awkward and unnecessary.

the gc proxy thing is a mess yah.

On 6/16/20 10:47 PM, Adam D. Ruppe wrote:
> On Tuesday, 16 June 2020 at 01:12:10 UTC, Andrei Alexandrescu wrote:
>> How difficult would be to arrange things such that absolutely nothing in the GC makes it in the final ninary if not used?
> 
> I don't know... I haven't looked at it all recently. I know the GC is used in part of the program initialization right now though (as are threads and other things) so that'd probably all have to change.

There was some work done to remove shared static this() for the GC.

On Wed, Jun 17, 2020 at 02:47:50AM +0000, Adam D. Ruppe via Digitalmars-d wrote:
> On Tuesday, 16 June 2020 at 01:12:10 UTC, Andrei Alexandrescu wrote:
> > How difficult would be to arrange things such that absolutely nothing in the GC makes it in the final ninary if not used?
> 
> I don't know... I haven't looked at it all recently. I know the GC is used in part of the program initialization right now though (as are threads and other things) so that'd probably all have to change.
[...]

As of recent releases, GC initialization is actually lazy now, it will not initialize anything until you actually use it.  Still one step away from being totally optional, granted, but it shouldn't be *too* difficult to make it so that, e.g., the GC code isn't even linked unless there's a reference to one of its symbols somewhere.


T

-- 
You have to expect the unexpected. -- RL

On 2020-06-17 06:08, H. S. Teoh wrote:

> As of recent releases, GC initialization is actually lazy now, it will
> not initialize anything until you actually use it.  Still one step away
> from being totally optional, granted, but it shouldn't be *too*
> difficult to make it so that, e.g., the GC code isn't even linked unless
> there's a reference to one of its symbols somewhere.

How would the GC know if it needs to initialize itself if you allocate the object at compile time, i.e.:

__gshared a = new Object; // module scope

Or is it expected that the above object fill never be freed?

What about the TLS data, isn't that used for the GC? This data is retrieved eagerly when a new thread is started. But since you'll always have at least one thread the data will always be retrieved?

-- 
/Jacob Carlborg

On Wednesday, 17 June 2020 at 02:09:47 UTC, dangbinghoo wrote:
>
> many pepole is requiring that the D runtime needs to be minimal. Yes, this "is a linking problem" just if you're always using "normal" or "rich" OS, things matter if you trying to using D in the microcontroller target such as STM32F4 or something similar, these platfrom has hundreds of KB ram and maybe 1MB of flash memory, it's powerfull enogh for running the D language.
>
> if you trying to build a betterC programing on these platforms(only RTOS or no OS at all), it shows that D runtime is requring some thing that only Rich-OS have.
>
> the rust and zig programming language is doing better in this situation, the D runtime can be made only need to requiring ANSI C stdlib (like nim 'any') and then the D runtime is more portable.
>
>
> thanks!
> ----
> binghoo dang

Indeed and it is not only about "not linking in what you don't need" as the druntime expects a lot of things from the OS. This includes reading elf section information, which shouldn't be needed in a minimal system as we don't even know if the programmer wants to use elf/pe. Maybe the programmer just want to use a binary blob. Typically RTOS in small platforms like STM32F4 or similar often don't implement TLS. For these kind of systems it would be nice if druntime didn't have any TLS variables at all and then the programmer must promise not to use any TLS variables. Essentially where you obtain the TLS area for each thread must be stubbed and just report empty TLS area.

Full D isn't really adapted for limited OS/RTOS today and it has painted itself into a corner by implementing a lot of expected OS support in the druntime. There isn't any wrong with it, it's just that D isn't a systems programming language and the question is if D should go that route. I'd say that D missed that train and D shouldn't peruse that any further.