www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - How can I properly import functions from gcx in object.di?

reply "Antti-Ville Tuunainen" <avtuunainen gmail.com> writes:
I'm working on the precise gc patches. I now have a bunch of 
templates and all the other infrastructure, but what's holding me 
back is that I don't quite understand the .di files.

In order for user-defined datastructures to instantiate the 
correct templates, the template code needs to live (/be imported 
into) the object.di file. However, for any kind of efficiency, 
the templates also need to be able to directly call functions 
and/or access the state from src/gc/gcx.d. I cannot just import 
it, because it won't be available during (user code) compilation. 
What is the correct approach?

Currently, I'm leaning on creating a new public gc.di (or 
similar), with functions to scan ranges and single pointers, and 
add implementations of those to the gcx side. Is this the correct 
way forward?
Jul 10 2012
next sibling parent =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <alex lycus.org> writes:
Hi,

On 11-07-2012 01:54, Antti-Ville Tuunainen wrote:

 I'm working on the precise gc patches. I now have a bunch of templates
 and all the other infrastructure, but what's holding me back is that I
 don't quite understand the .di files.


DI files are exactly what header files are in C(++) (there are some 
subtle differences, but you can think of them this way). They are merely 
an interface to the implementation.

We have a few hand-crafted DI files in druntime (object.di and 
core/thread.di) in order to hide a number of implementation details, 
while the rest of the DI files for druntime are generated or the 
implementation files just directly copied.


 In order for user-defined datastructures to instantiate the correct
 templates, the template code needs to live (/be imported into) the
 object.di file. However, for any kind of efficiency, the templates also
 need to be able to directly call functions and/or access the state from
 src/gc/gcx.d. I cannot just import it, because it won't be available
 during (user code) compilation. What is the correct approach?


Basically gc.* and rt.* are completely internal to the runtime. There is 
no (unobscure/supported) way to get at these modules.

Can you be more specific as to what information the templates need to 
get at (or provide)? That is, how will the templates interface with the GC?


 Currently, I'm leaning on creating a new public gc.di (or similar), with
 functions to scan ranges and single pointers, and add implementations of
 those to the gcx side. Is this the correct way forward?


Not sure. Need more information about the above first.

-- 
Alex Rønne Petersen
alex lycus.org
http://lycus.org
Jul 11 2012
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Tuesday, 10 July 2012 at 23:54:49 UTC, Antti-Ville Tuunainen 
wrote:

 […] However, for any kind of efficiency, the templates also 
 need to be able to directly call functions and/or access the 
 state from src/gc/gcx.d. I cannot just import it, because it 
 won't be available during (user code) compilation. What is the 
 correct approach?


The »correct« approach, as in what is currently done for such 
situations, would be to define the functions you need as 
extern(C) in gc.gc, and then just declare them where you need.

The reason behind this is that core.*, gc.* and rt.* are designed 
to be three completely independent entities, or at least were 
originally supposed to be. Compiler writers would implement the 
rt_ functions, GC implementors would mess around with gc_*, and 
the different parts could be combined by just linking libraries 
together, with the user-facing core.* implementation staying the 
same.

In the case of GC code, the situation is a bit more complex due 
to the GC proxy mechanism, which may or may not go away in the 
future – just look at gc/gc.d, and you should get a pretty good 
idea what's going on.

David
Jul 11 2012
prev sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Tuesday, 10 July 2012 at 23:54:49 UTC, Antti-Ville Tuunainen 
wrote:

 […] However, for any kind of efficiency, the templates also 
 need to be able to directly call functions and/or access the 
 state from src/gc/gcx.d. I cannot just import it, because it 
 won't be available during (user code) compilation. What is the 
 correct approach?


The »correct« approach, as in what is currently done for such 
situations, would be to define the functions you need as 
extern(C) in gc.gc, and then just declare them where you need.

The reason behind this is that core.*, gc.* and rt.* are designed 
to be three completely independent entities, or at least were 
originally supposed to be. Compiler writers would implement the 
rt_ functions, GC implementors would mess around with gc_*, and 
the different parts could be combined by just linking libraries 
together, with the user-facing core.* implementation staying the 
same.

In the case of GC code, the situation is a bit more complex due 
to the GC proxy mechanism, which may or may not go away in the 
future – just look at gc/gc.d, and you should get a pretty good 
idea what's going on.

David
Jul 11 2012