On Monday, 6 January 2014 at 11:47:57 UTC, Dwhatever wrote:
I'm trying to do the same, trying to compile OS free code but I haven't so far been successful because D requires the runtime and then also Phobos. Compared to C/C++ where you can create pretty advanced stand alone code without even include any standard libraries, this because much of C++ is part of the compiler.

I created a bare-metal freestanding (OS Free) hello world program and wrote a wiki about it here (http://wiki.dlang.org/Extremely_minimal_semihosted_%22Hello_World%22)

The problem is that there's not really much D in that D program, but it is a working foundation on which to build. If you plan on writing D code for embedded systems, you probably don't want all of the runtime anyway (at least I don't).

Using GDC compiled for arm-none-eabi, I created a malloc/free implementation in D and am now able to create classes that are allocated on the heap with "new" and deallocated using "destroy". I also created a reference counted implementation too that automatically deallocates when the reference count reaches 0. But, I'm still struggling with the memory management as a whole.

Unfortunately once I started creating structs and classes I had to implement a bunch of "TypeInfo.." stuff in object.d even though it appears none of it gets used. My object.d is now only about 140 lines.

This was only possible with a recent change to GDC (http://forum.dlang.org/post/[email protected]) and the -fno-emit-moduleinfo switch. I tried with LDC too, but LDC requires the world, so I gave up for now.

If any compiler implementers are reading this, please try to generate only code that is used by the program being compiled. I need to get this sorted out and submit some bug/enhancement requests to the compiler writers, but I first need to understand things better so I can articulate it well.

With D this is not the case. I don't really have a good picture what is part of the compiler or the runtime. Even creating a simple sample class and create a stack object requires that I include *everything*, that hairy runtime phobos nest. The runtime also has dependencies into Phobos which I find to be very inconvenient and I don't think it is a good idea. The runtime should be stand alone and Phobos should depended on the runtime and not vice versa.

I sympathize and agree. I can't see the abstraction in the phobos/runtime hairball. That's why I'm throwing the baby out with the bathwater and making a new baby.

I also wish the runtime wasn't so coupled to the garbage collector. The garbage collector is just one of several ways to manage memory, and I don't think the runtime should be so dependent on it, but that's probably easier said than done.

Compared to C/C++, D is very hard to get to work in the embedded/OS less environment because of this.

I agree, but it won't get any better until you and I step up and do something about it.

Reply via email to