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.
