GHC Trac Home
GHC Git Repos
Working on GHC
Mailing Lists & IRC
The GHC Team
All Feature Req's
Tickets I Created
Patches for review
New Feature Req
side by side
lines around each change
Show the changes in full context
White space changes
Oct 11, 2006 3:03:06 PM (
== Storage manager representations ==
The code generator needs to know the layout of heap objects, because it generates code that accesses and constructs those heap objects. The runtime also needs to know about the layout of heap objects, because it contains the garbage collector. How can we share the definition of storage layout such that the code generator and the runtime both have access to it, and so that we don't have to keep two independent definitions in sync?
Currently we solve the problem this way:
* C types representing heap objects are defined in the C header files, see for example [[GhcFile(includes/Closures.h)]].
* A C program, [[GhcFile(includes/mkDerivedConstants.c)]], `#includes` the runtime headers.
This program is built and run when you type `make` or `make boot` in `includes/`. It is
run twice: once to generate `includes\DerivedConstants.h`, and again to generate
* The file `DerivedConstants.h` contains lots of `#defines` like this:
#define OFFSET_StgTSO_why_blocked 18
which says that the offset to the why_blocked field of an `StgTSO` is 18 bytes. This file
is `#included` into [[GhcFile(includes/Cmm.h)]], so these offests are available to the
[wiki:Commentary/Rts/Cmm hand-written .cmm files].
* The file `GHCConstants.h` contains similar definitions:
oFFSET_StgTSO_why_blocked = 18::Int
This time the definitions are in Haskell syntax, and this file is `#included` directly into
[[GhcFile(compiler/main/Constants.lhs)]]. This is the way that these offsets are made
available to GHC's code generator.