Is there any plan for a dependency-free subset of "core" runtime?

Seb seb at wilzba.ch
Thu Jul 19 14:19:32 UTC 2018


On Thursday, 19 July 2018 at 12:40:09 UTC, Zheng (Vic) Luo wrote:
> On Thursday, 19 July 2018 at 11:35:00 UTC, Seb wrote:
>>
>> Well, since 2.079 it's actually possible to use D without a 
>> dependency any runtime (even libc):
>>
>> https://dlang.org/changelog/2.079.0.html#minimal_runtime
>>
>> Also with -betterC you can actually use lots of things from 
>> core that don't depend on the runtime. For example, 
>> std.algorithm/range works in betterC:
>>
>> https://run.dlang.io/is/38yowj
>>
>> Now, I assume you are asking whether there are plans for a 
>> minimal -betterC runtime?
>> There aren't "official" plans, but AFAICT a few people are 
>> independently working on this. It might be a good idea to join 
>> efforts with them.
>
> Thank you for the clarification. I am working on a libc-free 
> project (SAOC project: 2D rasterizer on embedded devices) and 
> just faced some missing symbols(__assert, _memset32) from 
> various libraries in snippets like 
> https://run.dlang.io/is/Kme62V (more missing symbols without C 
> runtime). I am a little bit confused at the boundary of D 
> components:
>
> - which subset of standard library can be used under -betterC?

Unfortunately, it's not properly defined (or tested) as -betterC 
is still WIP and there's also WIP to make the standard library 
more opt-in (e.g. the GC only starts when you actually use it 
since 2.080).
Anyhow, for -betterC there's a lot of all currently supported 
features:

https://dlang.org/spec/betterc.html

In terms of the standard library, everything that is either 
templated or a template will very likely work, e.g.

- std.algorithm (mostly)
- std.range (mostly)
- std.meta
- std.typecons

I actually have a PR in the works to add a -betterC testsuite to 
Phobos.

> - even with -betterC, the compiler sometimes require external 
> symbols like __assert to work, so what are all the required 
> symbols? rust-core limits them to five: memcpy, memcmp, memset, 
> rust_begin_panic and rust_eh_personality.

assert is lowered to the C runtime assert with betterC.
With -betterC you should still have access to memcpy, just import 
core.stdc.string (see: 
https://dlang.org/library/core/stdc/string/memcpy.html).
If you don't use the C runtime which provides assert, memcpy etc. 
you need to define them yourself in the minimal runtime.
However, I think GDC/LDC provide intrinsics for a few of these 
operations.

See e.g. 
https://github.com/JinShil/stm32f42_discovery_demo/tree/master/source/runtime

> Is there any way to make this project remain as a "library" 
> with a few explicit external symbol dependencies instead of 
> bundling a minimal d-runtime/libc stubs? Since eliminating 
> d-runtime looks like an overkill in the most of time (almost 
> every embedded project defines their own 
> size_t/string/bitop/attribute, hope to see a core subset of 
> d-runtime to prevent reinventing the wheel.

Well, if you just use -betterC you still have access to all 
definitions in druntime (like size_t).
You just need to avoid linking with the C runtime when you 
absolutely want to avoid it (i.e. build the executable).

Here's a simple example of a D program for Linux x86_64 without 
any runtime that still accepts arguments , can do primitive 
output and uses declarations from druntime like size_t:

https://gist.github.com/wilzbach/1bb812b9bdd2fed693b0ee4a6f8a2fd8

tl;dr: the declarations in druntime are still usable - you simply 
can't call libc functions if you plan to build an executable from 
your library that should be runtime free.


More information about the Digitalmars-d-learn mailing list