Changes between Version 2 and Version 3 of Commentary/Rts/HaskellExecution


Ignore:
Timestamp:
Sep 12, 2006 3:13:28 PM (8 years ago)
Author:
simonpj
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Rts/HaskellExecution

    v2 v3  
    22 
    33= The Haskell Execution Model = 
     4 
     5The [wiki:Commentary/Compiler/StgSyn STG language] has a clear ''operational'' model, as well as having a declarative lambda-calculus reading.  The business of the code generator is to translate the STG program into `C--`, and thence to machine code, but that is mere detail. From the STG program you should be able to understand: 
     6  * What functions are in the compiled program, and what their entry and return conventions are 
     7  * What heap objects are allocated, when, and what their layout is 
     8 
     9GHC uses an eval/apply execution model, described in the paper [http://research.microsoft.com/%7Esimonpj/papers/eval-apply How to make a fast curry: push/enter vs eval/apply].  This paper is well worth reading if you are interested in this section. 
     10 
    411 
    512== Registers == 
     
    714Source files: [[GhcFile(includes/Regs.h)]], [[GhcFile(includes/MachRegs.h)]] 
    815 
     16During execution of Haskell code the following (virtual) registers are always valid: 
     17 * `Hp` points to the byte before the first free byte in the (contiguous) allocation space. 
     18 
     19 * `HpLim` points to the last avaiable byte in the current chunk of allocation space (see [[ref(Heap/Stack check failures)]]). 
     20 
     21 * `Sp` points to the youngest allocated byte of stack.  The stack grows downwards.  Why?  Because that means that a return address is at a lower address than the stack frame it "knows about", and that in turn means that we can treat a stack frame very like a heap object, with an info pointer (return address) as its first word. 
     22 
     23 * `SpLim` points to the last available byte in the current stack. 
     24 
     25There are bunch of other virtual registers, used for temporarily for argument passing, for words, floats and doubles: `R1` .. `R9`, `RF1` .. `RF4`, `RD1` .. `RD4`. 
     26 
     27In a register-rich machine, many of these virtual registers will be mapped to real registers.  In a register-poor machine, they are instead allocated in a static memory record, pointed to by a real register, `BaseReg`. 
     28 
     29The code generator knows how many real registers there are, and tries to avoid using virtual registers that aren not mapped to real registers.  So, for example, it does not use `R5` if the latter is memory-mapped; instead, it passes arguments on the stack. 
     30 
    931== Function Calls == 
    1032 
    11 Source files: [[GhcFile(rts/Apply.h)]], [[GhcFile(rts/Apply.cmm)]], [[GhcFile(utils/genapply)]] 
     33Source files: [[GhcFile(rts/Apply.h)]], [[GhcFile(rts/Apply.cmm)]] 
     34 
     35Dealing with calls is by far the most complicated bit of the execution model, and hence of the code generator.  Before we can talk about that, we need some terminology: 
     36  * The '''arity''' of a function is the number of lambdas statically used in [wiki:Commentary/Compiler/StgSyn the lambda-form of its definition].  Note that arity is not deducible from the type.  Example: 
     37{{{ 
     38f :: Bool -> Bool -> Bool 
     39f = \x -> case x of  
     40               True  -> not 
     41               False -> id 
     42}}} 
     43    Here, `f` has arity 1, even though its type suggests it takes two arguments.  The point is that the compiled code for `f` will expect to be passed just one argument, `x`. 
     44 
     45  * The '''entry point''' (sometimes called the '''fast entry point''') of a function of arity N expects its first N  arguments to be passed in accordance with the standard '''[wiki:Commentary/Rts/HaskellExecution#Entryconvention Entry convention]'''. 
     46 
     47  * A '''known call''' is a call of a function whose binding site is statically visible: 
     48    * The function is bound at top level in this module 
     49    * The function is bound at top level in another module, and optimistion is on, so we can see the details (notably arity) of the function in the module's interface file. 
     50    * The function is bound by an `let` binding that encloses the call. 
     51 
     52 
     53When compiling a call, there are several cases to consider, which are treated separately.   
     54  * '''Known function, saturated call'''.   The function is applied to exactly the right number of arguments to satisfy its arity.  In that case, we simply load the arguments according to the standard entry convention, and tail-call (jump to) the function's entry point. 
     55 
     56  * '''Known function, too few arguments'''.  In this case, we build a partial application (PAP), and return with a pointer to the PAP in the return register. 
     57 
     58  * '''Known function, too many arguments'''.  Save the extra arguments on the stack, push a return address, and then behave just like a saturated call.  When the result comes back, behave like "unknown call". 
     59 
     60  * '''Unknown function''';  a call in which we do not statically know what the function is.  In that case we must do a "generic apply".  This is so exciting that it deserves its [wiki:Commentary/Rts/HaskellExecution#Genericapply own section]. 
     61 
     62=== Generic apply === 
     63 
     64Files: [[GhcFile(utils/genapply)]] 
     65 
     66When compiling a call that has an unknown function, we must generate code 
     67  * Evaluate the function 
     68  * Scrutinise the function value returned to see its arity, and dispatch into the same three cases as in the case of known calls: 
     69    * Exactly the right number of arguments: load them into the standard locations and tail-call the function's entry point 
     70    * Too few arguments: build a PAP 
     71    * Too many arguments: save the excess arguments, and tail call the function as for a saturated cal. 
     72All of this takes quite a lot of code, so we pre-generate a whole bunch of generic-apply code sequencues, one for each combination of arguments.  This code is generated by the tool [[GhcFile(utils/genapply)]], and appears in [[GhcFile(rts/AutoApply.cmm)]]. 
     73 
     74For example, if we find a call to an unknown function applied to two (boxed) `Int` arguments, load the function and its two arguments into the standard places (?) and jump to `stg_ap_pp_entry`.  This latter code is in [[GhcFile(rts/AutoApply.cmm)]], generated by the `autoapply` tool.  The "`pp`" part is the bit that says the code is specialised for two pointer arguments. 
     75 
     76If none of the canned sequences apply, then we have to do somthing yet more exotic, and I have forgotten what it is.  Simon!  Help! 
     77 
     78== Entry conventions == 
     79 
     80Entry conventions are very conventional: the first N argumements in registers and the rest on the stack. 
    1281 
    1382== Return Convention == 
     
    2493 
    2594Source files: [[GhcFile(rts/HeapStackCheck.cmm)]] 
     95 
     96When allocating a heap object, we bump `Hp` and compare to `HpLim`. If the test fails we branch to ???.  Usually this code tests an interrupt flag (to see if execution should be brought tidily to a halt); grabs the next block of alloaction space; makes `Hp` point to it and `HpLim` to its end; and returns.  If there are no more allocation-space blocks, garbage collection is triggered.