digitalmars.D - How can I properly import functions from gcx in object.di?
- Antti-Ville Tuunainen (14/14) Jul 10 2012 I'm working on the precise gc patches. I now have a bunch of
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (18/30) Jul 11 2012 DI files are exactly what header files are in C(++) (there are some
- David Nadlinger (17/22) Jul 11 2012 The »correct« approach, as in what is currently done for such
- David Nadlinger (17/22) Jul 11 2012 The »correct« approach, as in what is currently done for such
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
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
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
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