I'm trying to find information how to port D, especially the D runtime to a proprietary OS. The OS support seems to be scattered around several files with a lot version (OS) switches. This makes kind of hard to understand what you have to implement. Also, what happens if you only have partial support, for example networking is completely left out.

Will there be a future improvement of this so that OS specific support can be moved to separate files and selected on module level instead? For example.

void DSpecificLibraryFunction(...)
{
    OSDependentLibraryFunction(...)
}

so that there are predefined OS specific functions that are selected on module level. Also version() switches where everything is consolidated into one file makes it more difficult to merge.

Do we have any guide for OS porting?

On Saturday, 22 February 2020 at 13:20:40 UTC, IGotD- wrote:
> I'm trying to find information how to port D, especially the D runtime to a proprietary OS. The OS support seems to be scattered around several files with a lot version (OS) switches. This makes kind of hard to understand what you have to implement. Also, what happens if you only have partial support, for example networking is completely left out.
>
> Will there be a future improvement of this so that OS specific support can be moved to separate files and selected on module level instead? For example.
>
> void DSpecificLibraryFunction(...)
> {
>     OSDependentLibraryFunction(...)
> }
>
> so that there are predefined OS specific functions that are selected on module level. Also version() switches where everything is consolidated into one file makes it more difficult to merge.
>
> Do we have any guide for OS porting?

Best place to start would be without druntime at all, just a minimal object module, and extern(C) main, then work your way up, introducing each module one at a time to make sure that it all works.

There are a few core components that you need to port in order to get things working, or at least, you need to isolate and verify that it works, as if they don't then you'll get some very hard to debug issues.

The two main ones to pay close attention to are rt.sections and core.thread.  If exception handling is not dwarf-based, then you'll have to implement your own rt.deh too.

On Saturday, 22 February 2020 at 13:20:40 UTC, IGotD- wrote:
> Do we have any guide for OS porting?

I'd suggest to first hack the compiler, so that it doesn't predefine the host OS, but a new version for your OS (and check whether predefining `version (Posix)` is appropriate or not). That way, you'll hit static asserts when compiling druntime/Phobos, where OS-specific parts don't handle the new OS yet. Once all compile errors are fixed, you can then move on to compiling and linking the druntime/Phobos test runners, fixing all linker errors along the way, and finally fixing all failing unittests, possibly requiring compiler codegen adaptations.

On Saturday, 22 February 2020 at 15:18:09 UTC, kinke wrote:
>
> I'd suggest to first hack the compiler, so that it doesn't predefine the host OS, but a new version for your OS (and check whether predefining `version (Posix)` is appropriate or not). That way, you'll hit static asserts when compiling druntime/Phobos, where OS-specific parts don't handle the new OS yet. Once all compile errors are fixed, you can then move on to compiling and linking the druntime/Phobos test runners, fixing all linker errors along the way, and finally fixing all failing unittests, possibly requiring compiler codegen adaptations.

That's sound like a start. Is there some kind of automation behind this based on the target triple (-mtriple) or just some kind of hardcoded default versions identifiers somewhere in the source code?

On 2020-02-22 20:30, IGotD- wrote:

> That's sound like a start. Is there some kind of automation behind this based on the target triple (-mtriple) or just some kind of hardcoded default versions identifiers somewhere in the source code?

Have a look at [1] for a recent example.

[1] https://github.com/ldc-developers/ldc/pull/3288/commits/b9c284537a8392a5348fa32d36260595c66997f1

-- 
/Jacob Carlborg

On Saturday, 22 February 2020 at 13:20:40 UTC, IGotD- wrote:
> I'm trying to find information how to port D, especially the D runtime to a proprietary OS.

Here is my "Frankenstein" MCU project: https://github.com/denizzzka/d_c_arm_test
Maybe this will help you somehow.

It is forced to use simultaneously: ldc2, clang, gcc, make, meson. Currently it uses ARM but also I interested in RISC-V.

It almost works except druntime.

> Will there be a future improvement of this so that OS specific support can be moved to separate files and selected on module level instead?

Hurrah! I come by search with same idea!

I looked into druntime for several days (and never before) and now I think that tree of its source code isn't organized properly and this stucks porting it to architectures very different from well-known Posix.

For example, look:
https://github.com/dlang/druntime/blob/master/src/core/stdc/errno.d
https://github.com/dlang/druntime/blob/master/src/core/stdc/stdio.d

Without moving out of architecture-dependent code into separate "subprojects" it is impossible to imagine that this code can be ported without significant labor costs.

Also, such a takeaway is necessary because by "architecture" we can mean  identical "CPU + OS" bundles but just with different definitions ​​of modern types like int_fast16_t and so on - thousands of "architectures"! This is actual for MCU.

Moreover, it would be nice to make as much as possible any parts of this "backend" optional. Let a compilation error happens if there is no some functionality. Then these talks about a certain "minimal druntime", which, in fact, provides abilities what already gives betterC, will stop.

Perhaps this proposal isn't new, but the search yielded nothing except your message.