|
CONVERSION ERROR
|
|
# GHC Commentary: The Code Generator
|
|
|
|
|
|
Error: HttpError (HttpExceptionRequest Request {
|
|
[compiler/codeGen](/trac/ghc/browser/ghc/compiler/codeGen)
|
|
host = "ghc.haskell.org"
|
|
|
|
port = 443
|
|
|
|
secure = True
|
|
|
|
requestHeaders = []
|
|
|
|
path = "/trac/ghc/wiki/Commentary/Compiler/CodeGen"
|
|
|
|
queryString = "?version=3"
|
|
|
|
method = "GET"
|
|
|
|
proxy = Nothing
|
|
|
|
rawBody = False
|
|
|
|
redirectCount = 10
|
|
|
|
responseTimeout = ResponseTimeoutDefault
|
|
|
|
requestVersion = HTTP/1.1
|
|
|
|
}
|
|
|
|
(StatusCodeException (Response {responseStatus = Status {statusCode = 403, statusMessage = "Forbidden"}, responseVersion = HTTP/1.1, responseHeaders = [("Date","Sun, 10 Mar 2019 07:03:39 GMT"),("Server","Apache/2.2.22 (Debian)"),("Strict-Transport-Security","max-age=63072000; includeSubDomains"),("Vary","Accept-Encoding"),("Content-Encoding","gzip"),("Content-Length","261"),("Content-Type","text/html; charset=iso-8859-1")], responseBody = (), responseCookieJar = CJ {expose = []}, responseClose' = ResponseClose}) "<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>403 Forbidden</title>\n</head><body>\n<h1>Forbidden</h1>\n<p>You don't have permission to access /trac/ghc/wiki/Commentary/Compiler/CodeGen\non this server.</p>\n<hr>\n<address>Apache/2.2.22 (Debian) Server at ghc.haskell.org Port 443</address>\n</body></html>\n"))
|
|
|
|
|
|
|
|
Original source:
|
|
## Storage manager representations
|
|
|
|
|
|
```trac
|
|
|
|
|
|
|
|
|
|
|
|
= GHC Commentary: The Code Generator =
|
|
|
|
|
|
|
|
[[GhcFile(compiler/codeGen)]]
|
|
|
|
|
|
|
|
== 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?
|
|
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:
|
|
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)]].
|
|
- C types representing heap objects are defined in the C header files, see for example [includes/Closures.h](/trac/ghc/browser/ghc/includes/Closures.h).
|
|
|
|
|
|
* A C program, [[GhcFile(includes/mkDerivedConstants.c)]], `#includes` the runtime headers.
|
|
- A C program, [includes/mkDerivedConstants.c](/trac/ghc/browser/ghc/includes/mkDerivedConstants.c), `#includes` the runtime headers.
|
|
This program is built and run when you type `make` or `make boot` in `includes/`. It is
|
|
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
|
|
run twice: once to generate `includes\DerivedConstants.h`, and again to generate
|
|
`includes/GHCConstants.h`.
|
|
`includes/GHCConstants.h`.
|
|
|
|
|
|
* The file `DerivedConstants.h` contains lots of `#defines` like this:
|
|
- The file `DerivedConstants.h` contains lots of `#defines` like this:
|
|
{{{
|
|
|
|
|
|
```wiki
|
|
#define OFFSET_StgTSO_why_blocked 18
|
|
#define OFFSET_StgTSO_why_blocked 18
|
|
}}}
|
|
```
|
|
|
|
|
|
which says that the offset to the why_blocked field of an `StgTSO` is 18 bytes. This file
|
|
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
|
|
is `#included` into [includes/Cmm.h](/trac/ghc/browser/ghc/includes/Cmm.h), so these offests are available to the
|
|
[wiki:Commentary/Rts/Cmm hand-written .cmm files].
|
|
[hand-written .cmm files](commentary/rts/cmm).
|
|
|
|
|
|
|
|
- The file `GHCConstants.h` contains similar definitions:
|
|
|
|
|
|
* The file `GHCConstants.h` contains similar definitions:
|
|
```wiki
|
|
{{{
|
|
|
|
oFFSET_StgTSO_why_blocked = 18::Int
|
|
oFFSET_StgTSO_why_blocked = 18::Int
|
|
}}}
|
|
```
|
|
|
|
|
|
This time the definitions are in Haskell syntax, and this file is `#included` directly into
|
|
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
|
|
[compiler/main/Constants.lhs](/trac/ghc/browser/ghc/compiler/main/Constants.lhs). This is the way that these offsets are made
|
|
available to GHC's code generator.
|
|
available to GHC's code generator.
|
|
|
|
|
|
== Generated Cmm Naming Convention==
|
|
## Generated Cmm Naming Convention
|
|
|
|
|
|
See [[GhcFile(compiler/cmm/CLabel.hs)]]
|
|
|
|
|
|
See [compiler/cmm/CLabel.hs](/trac/ghc/browser/ghc/compiler/cmm/CLabel.hs)
|
|
Labels generated by the code generator are of the form {{{<name>_<type>}}}
|
|
|
|
where {{{<name>}}} is {{{<Module>_<name>}}} for external names and {{{<unique>}}} for
|
|
|
|
internal names. {{{<type>}}} is one of the following:
|
|
Labels generated by the code generator are of the form `<name>_<type>`
|
|
|
|
where `<name>` is `<Module>_<name>` for external names and `<unique>` for
|
|
info:: Info table
|
|
internal names. `<type>` is one of the following:
|
|
srt:: Static reference table
|
|
|
|
srtd:: Static reference table descriptor
|
|
<table><tr><th>info</th>
|
|
entry:: Entry code (function, closure)
|
|
<td>Info table
|
|
slow:: Slow entry code (if any)
|
|
</td></tr>
|
|
ret:: Direct return address
|
|
<tr><th>srt</th>
|
|
vtbl:: Vector table
|
|
<td>Static reference table
|
|
<n>_alt:: Case alternative (tag n)
|
|
</td></tr>
|
|
dflt:: Default case alternative
|
|
<tr><th>srtd</th>
|
|
btm:: Large bitmap vector
|
|
<td>Static reference table descriptor
|
|
closure:: Static closure
|
|
</td></tr>
|
|
con_entry:: Dynamic Constructor entry code
|
|
<tr><th>entry</th>
|
|
con_info:: Dynamic Constructor info table
|
|
<td>Entry code (function, closure)
|
|
static_entry:: Static Constructor entry code
|
|
</td></tr>
|
|
static_info:: Static Constructor info table
|
|
<tr><th>slow</th>
|
|
sel_info:: Selector info table
|
|
<td>Slow entry code (if any)
|
|
sel_entry:: Selector entry code
|
|
</td></tr>
|
|
cc:: Cost centre
|
|
<tr><th>ret</th>
|
|
ccs:: Cost centre stack
|
|
<td>Direct return address
|
|
|
|
</td></tr>
|
|
|
|
<tr><th>vtbl</th>
|
|
|
|
<td>Vector table
|
|
|
|
</td></tr>
|
|
|
|
<tr><th>\<n\>_alt</th>
|
|
|
|
<td>Case alternative (tag n)
|
|
|
|
</td></tr>
|
|
|
|
<tr><th>dflt</th>
|
|
|
|
<td>Default case alternative
|
|
|
|
</td></tr>
|
|
|
|
<tr><th>btm</th>
|
|
|
|
<td>Large bitmap vector
|
|
|
|
</td></tr>
|
|
|
|
<tr><th>closure</th>
|
|
|
|
<td>Static closure
|
|
|
|
</td></tr>
|
|
|
|
<tr><th>con_entry</th>
|
|
|
|
<td>Dynamic Constructor entry code
|
|
|
|
</td></tr>
|
|
|
|
<tr><th>con_info</th>
|
|
|
|
<td>Dynamic Constructor info table
|
|
|
|
</td></tr>
|
|
|
|
<tr><th>static_entry</th>
|
|
|
|
<td>Static Constructor entry code
|
|
|
|
</td></tr>
|
|
|
|
<tr><th>static_info</th>
|
|
|
|
<td>Static Constructor info table
|
|
|
|
</td></tr>
|
|
|
|
<tr><th>sel_info</th>
|
|
|
|
<td>Selector info table
|
|
|
|
</td></tr>
|
|
|
|
<tr><th>sel_entry</th>
|
|
|
|
<td>Selector entry code
|
|
|
|
</td></tr>
|
|
|
|
<tr><th>cc</th>
|
|
|
|
<td>Cost centre
|
|
|
|
</td></tr>
|
|
|
|
<tr><th>ccs</th>
|
|
|
|
<td>Cost centre stack
|
|
|
|
</td></tr></table>
|
|
|
|
|
|
|
|
|
|
Many of these distinctions are only for documentation reasons. For
|
|
Many of these distinctions are only for documentation reasons. For
|
|
example, _ret is only distinguished from _entry to make it easy to
|
|
example, _ret is only distinguished from _entry to make it easy to
|
|
tell whether a code fragment is a return point or a closure/function
|
|
tell whether a code fragment is a return point or a closure/function
|
|
entry. |
|
entry. |
|
|
|
|
|
``` |
|
|