Minimum druntime

[kassane]

I think this issue has always been discussed by the D community about the lack of portability of Drt for embedded devices.

Is it intended to create a minimum druntime?

Currently, I use ldmd2 more often than dmd and think about the lack of support for linux-musl and windows-mingw with druntime and stdlib (phobos). This is a painful experience!

Last time, I tried to run openwrt on mipsel router, I needed to do a hack involving zig cc with llvm-libunwind + custom object.d(empty).

Work? Yes!
Same result on windows-mingw.

I don't know if the possibility of allowing users to use an abstract interface to create their custom druntime, reusing core.druntime(minimum runtime) as a base, has been considered.

[adamdruppe]

Yeah, what I'd like to do is to make the necessary OS interface minimal and easy to find and extend. This can be a pain but if we isolate the modules right the pure D bits on top of the OS interface can be pretty easily reused and if they don't call into each other and/or can be versioned out you can strip things down a bit that way, just not using parts you don't need and letting the linker leave them behind.

[IgorDeepakM]

Yes, this is at least something I'm keen on since I have ported and want to port druntime to custom systems. One thing I want to do is make druntime not dependent on any GC. That which means manual allocations and/or relying on containers that handles memory themselves. I hope that druntime isn't that complicated as Phobos so that this is possible without too much work. I know that nogc isn't really a goal with openD but I would still like that druntime is kept as tight as possible without any dependencies to grand memory infrastructures.

This opens up druntime to be used in embedded systems where people wants to handle memory allocations themselves and still be able to use the openD druntime interface for system functions.

Also there are work in the old D project that tries to split up the code so that we don't have version identifier hell. I'm not sure if/how that work will be merged. However, since we have decided to depart from version, I suggest that we can choose what to include in druntime on a needed basis. For example a certain OS doesn't support files or networking and there is a possibility to omit those in the build of druntime.

Another goal would be to remove the dependency of the C library. The C library could be supported as a target for druntime but I would also like that druntime has the option to use the OS API directly instead of going through C lib.

Another thing I would like to as an addition to druntime is a native API for asynchronous IO.

This is huge job in itself and it kind of relies on removing all the version hell because trying to be productive in its current state is very difficult. This is certainly a job for several people for quite some time.

[quickfur]

This sounds like a very ambitious project. Do we actually have the manpower/expertise to pull this off? Upstream D has been trying to move in this direction for years, and not much progress has been made.

One possible approach is to create a new minimal core, separate from the current code, and incrementally grow it while refactoring the existing code to funnel all external (OS/libc/etc) calls through it. This will take a lot of time and care. Be prepared to meet obstacles on the way, such as memcpy dependencies and things like that. The ultimate goal is to rid the current code of all direct calls to OS/libc, and have all such calls go through the minimal core. (The actual implementation could be a transparent templated passthrough to the underlying OS call via inlining; the point is to remove explicit dependencies so that you just have to implement a new minimal core when targeting a new system.)

[adamdruppe]

I think upstream is a bit distracted by that whole templatizing project. I don't think this is necessary or even especially helpful toward the goal of embedded druntimes, and their insistence on static assert(0) is actively harmful toward the goal. So if we change approach on that I do think it is more realistic. I've done a lot of copy/paste minimal druntimes in the past successfully, using a lot of the existing code.

Of course it could be a lot of work anyway...

[quickfur]

The first order of business is to decide what to include in the minimal OS interface. What is absolutely essential, that upper level code can rely on to exist, and what's not essential, and any upper level code that relies on it will have to check for it (either at compile-time or runtime)?

Also don't forget subtle interactions like optimizing compilers recognizing common libc patterns like memcpy and optimizing their codegen accordingly -- if we substitute it with a D version of memcpy that the compiler doesn't recognize, we may miss the optimization and unwittingly end up with a big performance hit.

[denizzzka]

I think this issue has always been discussed by the D community about the lack of portability of Drt for embedded devices.

One thing I want to do is make druntime not dependent on any GC.

2All: Please don't forget about this proposal: dlang/dmd#15887

Is it intended to create a minimum druntime?

druntime is already near to minimal, as for me

I think upstream is a bit distracted by that whole templatizing project. I don't think this is necessary or even especially helpful toward the goal of embedded druntimes

My testing binary for ARM was decreased from ~500Kb to ~400Kb - that is significant for embedded MCUs what provide exactly 512Kb of ROM

[adamdruppe]

interesting. Are you able to elide more typeinfo thanks to the templating? or is it some other mechanism?

[denizzzka]

Are you able to elide more typeinfo thanks to the templating?

Under "templating" I mean "Replace druntime Hooks with Templates" and "Pay-as-you-go druntime" initiative: https://github.com/orgs/dlang/projects/34

It seems that something was done as part of this and now not every TypeInfo entry is compiled into binary as it was previously

[quickfur]

I've been playing around with wasm on ldc2 with --fno-rtti; thanks to the recent work on templatizing druntime, I've been able to evade using TypeInfo for things like array concatenation/append, etc.. Currently still WIP, but I'm hoping I can implement array operations and AA's with zero TypeInfo dependencies. That would be awesome. Pretty sure I can do it for arrays, for AA's not 100% sure, but might be possible depending on how much has been templatized on the compiler side.

[IgorDeepakM]

I haven't been following the WASM discussion, but why is typeinfo such a problem for WASM?

[quickfur]

It's not necessarily a problem per se, it's just a source of a lot of code bloat. TypeInfos get generated for basically every non-POD type in your program, even if you never use them or reference them. For wasm where the target platform may have memory limitations, this is a lot of unnecessary dead weight that we could do better without.

Of course, if you're using dynamic casts at runtime or runtime introspection then by all means TypeInfos are what you need. But I'd like to pay for them only when I actually need them, not by default.