OSDev.org

I would be EXTREMELY grateful if someone could share their experiences with the D language (wiki?). I have thought about converting to D many times cause I love the language, but now I heard that is designed for systems programming

Currently I'm working on D cross-compiler and stuffs like linker script and so. Then a D wiki page will appear !

quanganht wrote:Currently I'm working on D cross-compiler and stuffs like linker script and so. Then a D wiki page will appear ! :)

Cool, I'll be eagerly awaiting.


JAL

berkus wrote:dmd vs. gdc - messy. different options, different search paths. gdc can't find some runtime libs, dmd seems to find standard libs fine, but chokes on importing local modules. May be it was my setup.

dmd - Is it the compiler/linker the D website provide for system programming or just applications? And I didn't find any info on the executable format the linker outputs (my OS uses ELF).
gdc - Wikipedia states it only supports D1.0. The compiler isn't 100% faithful to the specification (though they list the issues on their website).

D1.0 vs D2.0 - The 2.0 dmd compiler is unstable, though there are several features I like. The 2.0 specification is also likely to evolve a bit.

A long time ago, when I tried to port my kernel to D, I ran into those problems as well:

dmd is actively developed and is the official compiler, but is really not intended to be a compiler for the system. It's distributed in binary form (can't seem to find the source), and only for 32-bit Windows and Linux. It only compiles to the native executable of the platform... way to go, system programming!

gdc is an improvement because it's a front-end to gcc, making it more flexible (and support more target formats). However, it's a one-man show, it's been unmaintained for more than a year now, and that state doesn't seem to have changed (It only supports GCC 4.0.* as of this writing, without patches). Apparently, the reason they haven't added support for D in the GCC project (which would really be a blessing, IMHO) is because of licensing conflicts .

There's also llvmdc, which seems to be the best hope so far (D front-end on the LLVM compiler). It's really early in production, but if I figure out how to make it cross-compile x86-64 ELF binaries, then I might have a chance.

Finally, there's the runtime stubs. Oh, the runtime stubs... From my experience, it was too painful to implement (I gave up), and apparently differs between compiler and/or library versions. Not to mention that there are two competing libraries, two partially-incompatible standards, and three different compilers. Great...

But that was a long time ago. Now (for my kernel at least), I'm sticking with my C++ foo.

I agree with you Zenith, dmd is terrible. GDC, using the dmd implementation, is also...meh...bad on many levels. The source is around, GDC uses it. And yes, where did that guy go who is maintaining it?! This is why we are GTFO'ing to LLVM. (We see GCC as a sinking ship, also, but that's a different story)

LLVM's LDC is the way to go. We are working actively with LDC developers on porting XOmB (our D exokernel) to use it. Apparently we are a nice test case They tell us our kernel compiles fine for x86-64 (although LLVM's variadics for x86-64 are nonexistent as of the present). It doesn't produce a valid binary because it needs to be a naked compiler, and it isn't. But hopefully they will step us through that and we can update the wiki.

LDC is great because it marks the true second compiler implementation of the language (remember: gdc uses the dmd codebase). So LDC should be a viable development tool for OS work. (I've obviously not had a chance to really use it though)

quanganht wrote:Currently I'm working on D cross-compiler and stuffs like linker script and so. Then a D wiki page will appear !

Great! I see you are on our mailing list. Please use it for questions, we would like to help. Mixins are so nice for interrupt handling I've personally built gdc cross-compilers several times targeting 32-bit and 64-bit machines. One of us has patches that are necessary.

MessiahAndrw wrote:gdc - Wikipedia states it only supports D1.0.

Yep, pretty much. As Zenith points out, the SOLE maintainer is sorta missing ATM. Also, dmd would be a terrible choice for systems dev...unfortunately. Doesn't target 64 bit machines.. It doesn't like stripping out runtimes and the like. It is difficult, that is. This is much of the reason behind the two runtimes (Tango/Aries vs Phobos) being so incompatible. But, that's why LDC exists.

Zenith wrote:I'm sticking with my C++ foo.

Awwww... (confession: I like me some C++ sometimes )

Overall, I am very impressed at the response of this thread. I will try and contribute what I can to the wiki.

I'm in the process of reading the D language specification (I thought reading how exactly how the language works would beat reading tutorials/samples and leaving a lot of assuming) and I'm just past halfway through. One thing I am unsure of is it says operators :: and -> do not exist.

Now if had a pointer to a struct, which had a member called foo, how would you access it.
myStruct.foo; // compiler detects myStruct is a pointer and all is good
or
(*myStruct).foo;

If the former is true, how you do know if:
myStruct = mySecondStruct;
is calling the copy constructor or making myStruct point to mySecondStruct?

I don't have a D compiler environment set up atm.

Hey guys. I'm using Cygwin. And what the hell is this:


It turns out that G++ included GDC ???

I'm not sure what you're talking about. You just showed us what version of G++ you're using with Cygwin...

Perhaps he's surprised that he's got GDC included when he didn't ask for it.

GCC actually supports several languages beyond C/C++. (Java - or more exactly, GCJ - and Objective-C spring to mind.)

I just finished reading the D1.0 language specification (took roughly 8 hours on and off) from back to front completely.

I'm now inspired to write something in D. Since there seems to be a lot of issues regarding system programming in D, I should write an application. I've decided I should port my game framework to D. The C libraries (Win32, CG, etc) I depend on can be easily interfaced with D.

The only thing disappointing is interop'ing with C++ libraries (which I need for DirectX and majority of physics libraries) which is excluded from D1.0, but not from D2.0. I haven't read exactly how so, but I'm going to update myself and read the 2.0 language spec (though after reading the differences between 1.0 and 2.0 so I'm not repeating myself).

EDIT: It seems like the hard work is done for me http://www.dsource.org/projects/nonagon ... on/d3d9d.d

Wilkie wrote:Overall, I am very impressed at the response of this thread.

And I am very impressed with someone actually using D for OS deving. I considered it, but since I knew (and know) little D, and wasn't sure of the tools, I decided against it (using C++ now). Still very interested in it though!


JAL

MessiahAndrw wrote:One thing I am unsure of is it says operators :: and -> do not exist.

Now if had a pointer to a struct, which had a member called foo, how would you access it.
myStruct.foo; // compiler detects myStruct is a pointer and all is good
or
(*myStruct).foo;

Both would work. All scoping is done via the dot. To do a copy, and both are pointers, you'd do

MessiahAndrw wrote:EDIT: It seems like the hard work is done for me http://www.dsource.org/projects/nonagon ... on/d3d9d.d

Hey, I know personally the guy who wrote that. I have a class with him Tuesdays and Thursdays. He wrote some of our initial stub code for the OS. The world is very small.

quanganht wrote:Then a D wiki page will appear !

Though I'd love to work on my OS, I have other stuff to do, so I decided to to start working on it again until I can do a full port to D (hopefully with the help of your wiki page).

I installed Cygwin again today. And as I'm surfing the list under 'Devel', I saw there was 'gcc-gdd : D compiler' . Unbelievable. When did Cygwin add that option, and I don't even know about it . Testing now. I guess gdc will be include in gcc source code soon ~> cross-compiler no longer be the problem !