Hitchikers Guide to Porting Phobos / D Runtime to other architectures

[Sean Kelly]

On Wednesday, 8 January 2014 at 02:54:40 UTC, Mike wrote:
> On Wednesday, 8 January 2014 at 01:27:28 UTC, Walter Bright 
> wrote:
>
>> It's not that hard. Use the -betterC switch to prevent 
>> ModuleInfo records and their dependencies from being emitted, 
>> and then you can write D code that has zero dependence on 
>> druntime or phobos.
>
> As the creator of D and a significant author of the runtime, I 
> think you are taking a lot for granted.  I think from your 
> perpective, it probably isn't all that hard, and certainly as I 
> study D and the runtime, it is becoming significantly easier.  
> But in comparison with C, Dwhatever is right... it's a bear, 
> but I don't necessarily believe that that's bad.

The runtime contains years of accumulated cruft, and it obviously
biased towards the way DMD works.  I'd personally like to see the
"rt" portion at least get a thorough once-over along the lines of
what you're doing to see if parts can be simplified or discarded,
and to determine whether there are any hidden costs to using
language features.

> Furthtermore, the way the D Runtime is organizized, it's quite 
> difficult to see the abstractions (if there are any). Putting 
> some weight behind this issue 
> (https://d.puremagic.com/issues/show_bug.cgi?id=11666) would 
> certainly help.

We'll have to rely mostly on input from GDC and LDC here.  The
current stdc header design is the one that was the easiest for me
to maintain when I was the sole runtime developer and we were
targeting a handful of platforms.  That's clearly changed, but I
don't know what workflow is ideal for the other compilers.  I do
think we may need to stick with manually written headers though,
as much for copyright reasons as anything.  That said, if the
runtime at least were modified to not use the C library at all,
we may eventually be able to detach it completely.  I think we're
probably already down to a small number of functions (memset,
memcpy, and a few maths routines).

> The origin of this thread was really about a porting guide; an 
> excellent idea!  You can wait several months for me learn D and 
> the runtime and I'll create one, or you and the other D Runtime 
> authors can create one and show us just how easy it is.  A 
> simple wiki post like this 
> (http://wiki.osdev.org/Porting_Newlib) would be an excellent 
> start.

The old wiki pages are here:

http://dsource.org/projects/druntime

Also, this may still be relevant:

http://dsource.org/projects/tango/wiki/ChapterC

The information is pretty sparing, but it should provide a decent
starting point and explain at least a bit of the rationale behind
the current design.  The most notable design change since these
were written is that I decided it's reasonable for all portions
of the runtime to import anything in "core", so the separate
compilation aspect isn't quite as true as it once was.  This also
means that not every extern (C) function defined in, say,
core.exception may actually be needed any more from a design
perspective, though I still very much like having the GC interact
with the thread library via the provided extern (C) thread_*
routines.  I think one could easily argue that if the runtime
ever needs to create a Thread, it should do so via a proxy
function instead of directly instantiating the class to retain
ease of porting D to platforms where threads aren't desired.