Thread overview
Re: Writting SO kernel in D
Apr 19, 2007
Javi
Apr 19, 2007
BCS
Apr 19, 2007
Sean Kelly
Apr 19, 2007
Frits van Bommel
Apr 19, 2007
Sean Kelly
April 19, 2007
Frits van Bommel Wrote:

> Actually, that looks like exception support. Try compiling with
> "-fno-exceptions" to turn it off.
> Though if you ever want to use exceptions in your kernel you'll have to
> eventually copy the code from the runtime or reimplement it yourself. (I
> have no idea what it requires, for all I know the default implementation
> could work just fine in a kernel)

Thank you very much! I works fine now.

Another question:
Where is the runtime code localted on disk? And If this code resides in a big file, how can I extract only the relevant routines?
Sorry, but I'm not a compiler expert.


April 19, 2007
Javi wrote:
> Frits van Bommel Wrote:
> 
> 
>>Actually, that looks like exception support. Try compiling with "-fno-exceptions" to turn it off.
>>Though if you ever want to use exceptions in your kernel you'll have to eventually copy the code from the runtime or reimplement it yourself. (I have no idea what it requires, for all I know the default implementation could work just fine in a kernel)
> 
> 
> Thank you very much! I works fine now.
> 
> Another question: Where is the runtime code localted on disk? And If this code resides in a big file, how can I extract only the relevant routines?
> Sorry, but I'm not a compiler expert.
> 
> 

I think it's in libphobos.a (or the .lib equivalent on Win32)
April 19, 2007
Javi wrote:
> 
> Another question: Where is the runtime code localted on disk? And If this code resides in a big file, how can I extract only the relevant routines?
> Sorry, but I'm not a compiler expert.

It's in Phobos in the /internal directory.  Under that is the /gc directory, which contains the garbage collector implementation.

If you're using Tango, the compiler runtime is in /lib/compiler/gdc or /lib/compiler/dmd, and the garbage collector is in /lib/gc/basic.


Sean
April 19, 2007
Sean Kelly wrote:
> Javi wrote:
>>
>> Another question: Where is the runtime code localted on disk? And If this code resides in a big file, how can I extract only the relevant routines?
>> Sorry, but I'm not a compiler expert.
> 
> It's in Phobos in the /internal directory.  Under that is the /gc directory, which contains the garbage collector implementation.
> 
> If you're using Tango, the compiler runtime is in /lib/compiler/gdc or /lib/compiler/dmd, and the garbage collector is in /lib/gc/basic.

And since he's using GDC[1] some of it is in d/phobos/gcc/ in the GDC source tree, or include/d/*/gcc/ in the installed version. Specifically, look at deh.d for exceptions.


[1]: and presumably not Tango, since he's coding a kernel. Though he could of course use that version just as well.
April 19, 2007
Frits van Bommel wrote:
> Sean Kelly wrote:
>> Javi wrote:
>>>
>>> Another question: Where is the runtime code localted on disk? And If this code resides in a big file, how can I extract only the relevant routines?
>>> Sorry, but I'm not a compiler expert.
>>
>> It's in Phobos in the /internal directory.  Under that is the /gc directory, which contains the garbage collector implementation.
>>
>> If you're using Tango, the compiler runtime is in /lib/compiler/gdc or /lib/compiler/dmd, and the garbage collector is in /lib/gc/basic.
> 
> And since he's using GDC[1] some of it is in d/phobos/gcc/ in the GDC source tree, or include/d/*/gcc/ in the installed version. Specifically, look at deh.d for exceptions.

Oops, good point.  In Tango all of this is in the same place, and I'd forgotten GPhobos was different.

> [1]: and presumably not Tango, since he's coding a kernel. Though he could of course use that version just as well.

As a shameless plug, building kernels against Tango should actually be easier than doing so against Phobos, since the runtime can be used completely separately from all user-level code, the GC more easily replaced or customized, etc.  Kernel development was actually one of my primary inspirations for the Tango design, since most of the vocal Ares users were working on kernel projects :-)


Sean