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/zewevdmburppufkjx...@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....@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
