Hitchikers Guide to Porting Phobos / D Runtime to other architectures

[Mike]

On Tuesday, 7 January 2014 at 21:52:54 UTC, Dwhatever wrote:
>> What CPU/MCU are you targeting?  Are you building for 
>> bare-metal?
>
> Yes, for bare metal, no OS, nothing.
>
> I think I have to specify my target architecture and CPU 
> otherwise the compiler cannot know that I'm cross compiling for 
> ARM. -march= -mcpu= will not work for me.
>
> I'm trying to compile a simple stand alone object file.
>
> class TestClass
> {
>     ubyte member;
>
>     this(ubyte m) { member = m; }
>     ubyte Get() { return member; }
> };
>
>
> extern(C) void main()
> {
>     // stack class
>    scope test = new TestClass(0);
>
>    // simple inline asm test
>    __asm("mov r0,#1;
>           mov r1,#2", "~{r0,r1}");
> }
>
> This test should be simple enough I thought but it turned out 
> that to compile and link this, D requires almost everything 
> from the runtime.
>
> So the challenge is, compile and link the simple code above 
> targeting ARM using LDC, no OS allowed.

First of all, there's no such thing as a class allocated on the 
stack in D. See here ( http://dlang.org/deprecate.html#scope for 
allocating classes on the stack).  You have to go with structs if 
you want that feature, but there are other ways like Scoped(T), 
RefeCounted(T), scope(exit), etc...  It feels as little half-ass 
to do things this way, but D is quite powerful, and an alternate, 
elegant solution is probably just waiting to be discovered.

Anyway, once you add the word "class" or "struct" you release an 
avalanche of snowballing required runtime stuff that you are 
likely not even using, directly or indirectly, in your program. 
And if using --gc-sections in your linker, it all just gets 
stripped out in the end. I was trying to articulate that here 
(http://forum.dlang.org/post/zewevdmburppufkjxdje@forum.dlang.org)

IMO this is a problem with the compiler, not D, and LDC suffers 
from it much more than GDC. Iain Buclaw recently made a change to 
GDC 
(http://forum.dlang.org/post/mailman.3.1387377012.2938.d.gnu@puremagic.com) 
that allowed me to reduce my object.d to 140 lines, and with an 
accompanying malloc and free, I was able to create classes. I 
don't know what the change was, but it was most beneficial 
(Thanks Iain!). I hope the LDC folks can do the same, but I 
probably need to file an enhancement request and make a case for 
it.

I'm sorry I can't share my code at the moment; I haven't decided 
yet where to put it.  I was studying Adam Ruppe's minimal X86 
port last night and found it most useful (Thumbs Up!), but with a 
2000 line object.d, it's stretching the word "minimal", at least 
when compared with C. But if you really want all the cool stuff D 
has to offer, this is probably what will be required in the end.

All the compilers seem to have been written mostly with the PC in 
mind, and seem to expect too much of the D runtime accompanying 
the compiler, which is definitely very different from C/C++ where 
you only pay for what you use. It also seems some argue that if 
you aren't using the full runtime, you aren't using D, and they 
have a point, but only one that limits D's appeal.  The compiler 
folks have been most helpful so far as I try to "go minimal" with 
D, but I hope they will see the benefit of an "only require what 
is actually used" approach. D is, however, different from C, and 
this may have some consequences as mentioned here ( 
http://forum.dlang.org/post/lagsn7$2lqc$1@digitalmars.com).

In further constrast with C, much of the language is implemented 
in the runtime, as you previously alluded to.  Even the 
switch...case statement seems to be, at least partially, 
implemented in the runtime 
(https://github.com/D-Programming-Language/druntime/blob/master/src/rt/switch_.d). 
  I think this is great, because this means we don't have to know 
how to build compilers to port the language to a given platform.  
And with a "pay as you go" compiler, this could make D suitable 
for even the tiniest of microcontrollers.

Anyway, if you want to go minimal, go with GDC for now.  I hope 
to file some enhancement requests with the compilers soon that 
will help with this very issue, but I don't know how interested 
they will be in addressing them.  I do see progress being made, 
so I'm hopeful.

Mike