www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Porting D to custom OS

reply IGotD- <nise nise.com> writes:
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?
Feb 22 2020
next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
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.
Feb 22 2020
prev sibling next sibling parent reply kinke <noone nowhere.com> writes:
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.
Feb 22 2020
parent reply IGotD- <nise nise.com> writes:
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?
Feb 22 2020
parent Jacob Carlborg <doob me.com> writes:
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
Feb 23 2020
prev sibling parent Denis Feklushkin <feklushkin.denis gmail.com> writes:
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.
Feb 23 2020