Changes between Version 13 and Version 14 of Commentary/Rts/HaskellExecution


Ignore:
Timestamp:
Jun 26, 2007 11:30:03 AM (7 years ago)
Author:
simonmar
Comment:

move subsections into separate pages

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Rts/HaskellExecution

    v13 v14  
    99GHC 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. 
    1010 
    11  
    12 == Registers == 
    13  
    14 Source files: [[GhcFile(includes/Regs.h)]], [[GhcFile(includes/MachRegs.h)]] 
    15  
    16 During 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 available 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 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 (youngest) available byte in the current stack. 
    24  
    25 There are bunch of other virtual registers, used for temporary argument passing, for words, floats and doubles: `R1` .. `R10`, `F1` .. `F4`, `D1` .. `D4`, `L1` .. `L2`. 
    26  
    27 In 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  
    29 The code generator knows how many real registers there are, and tries to avoid using virtual registers that are 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  
    31 == Function Calls == 
    32  
    33 Source files: [[GhcFile(rts/Apply.h)]], [[GhcFile(rts/Apply.cmm)]] 
    34  
    35 Dealing with calls is by far the most complicated bit of the execution model, and hence of the code generator.  GHC uses an ''eval/apply'' strategy for compiling function calls; all the details of the design are in the paper [http://www.haskell.org/~simonmar/papers/eval-apply.pdf Making a fast curry: push/enter vs. eval/apply for higher-order languages]. 
    36  
    37 First, we need some terminology: 
    38  
    39   * The '''arity''' of a function is the number of lambdas statically used in [wiki:Commentary/Compiler/StgSynType the lambda-form of its definition].  Note that arity is not deducible from the type.  Example: 
    40 {{{ 
    41 f :: Bool -> Bool -> Bool 
    42 f = \x -> case x of  
    43                True  -> not 
    44                False -> id 
    45 }}} 
    46     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`. 
    47  
    48   * 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]'''. 
    49  
    50   * A '''known call''' is a call of a function whose binding site is statically visible: 
    51     * The function is bound at top level in this module; or, 
    52     * 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; or, 
    53     * The function is bound by an `let` binding that encloses the call. 
    54  
    55  
    56 When compiling a call, there are several cases to consider, which are treated separately.   
    57  
    58   * '''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]. 
    59  
    60   * '''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.  On average, about 80% of all calls fall into this category (see the eval/apply paper for measurements). 
    61  
    62   * '''Known function, too few arguments'''.  In this case, we want to build a partial application (PAP), and return with a pointer to the PAP in the return register.  Since building a PAP is a complicated business, instead we just behave as for an unknown function call, which will end up calling into the [[ref(Generic apply)]] code, which will build the PAP for us. 
    63  
    64   * '''Known function, too many arguments'''.  We want to save the extra arguments on the stack, push a return address, and then behave just like a saturated call.  When the result comes back, we should behave like "unknown call".  However, to avoid needing to generate code for a new continuation here, the return address that we push on the stack is that of an appropriate [[ref(Generic apply)]] function, which will perform the application of the extra arguments to the (unknown) function returned by the saturated call. 
    65  
    66 === Generic apply === 
    67  
    68 Files: [[GhcFile(utils/genapply)]] 
    69  
    70 When compiling a call that has an unknown function, we must generate code to 
    71   * Evaluate the function 
    72   * Scrutinise the function value returned to see its arity, and dispatch into the same three cases as in the case of known calls: 
    73     * Exactly the right number of arguments: load them into the standard locations and tail-call the function's entry point 
    74     * Too few arguments: build a PAP 
    75     * Too many arguments: save the excess arguments, and tail call the function as for a saturated cal. 
    76 All 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 the generated code appears in `rts/AutoApply.cmm`. 
    77  
    78 For example, if we find a call to an unknown function applied to two (boxed) `Int` arguments, load the function and its two arguments as for the standard entry convention and jump to `stg_ap_pp_fast`.  This latter code is in `rts/AutoApply.cmm`, generated by the `genapply` tool.  The "`pp`" part is the bit that says the code is specialised for two pointer arguments. 
    79  
    80 In addition to the family of `stg_ap_<pattern>_fast` functions for making calls to unknown functions with various argument patterns, there is a corresponding family of return addresses `stg_ap_<pattern>_info`.  The idea is that you can push a continuation that will make a call to the function that is returned to it.  For example, to push a continuation that will apply a single pointer argument, we would push the following words on the stack: 
    81  
    82 || arg || 
    83 || `stg_ap_p_info` || 
    84  
    85 == Entry conventions == 
    86  
    87 Entry conventions are very conventional: the first N argumements in registers and the rest on the stack. 
    88  
    89 == Return Convention == 
    90  
    91 === Direct Returns === 
    92  
    93 === Vectored Returns === 
    94  
    95 == Updates == 
    96  
    97 Source files: [[GhcFile(rts/Updates.h)]], [[GhcFile(rts/Updates.cmm)]] 
    98  
    99 == Heap/Stack check failures == 
    100  
    101 Source files: [[GhcFile(rts/HeapStackCheck.cmm)]] 
    102  
    103 When 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. 
     11Contents: 
     12  
     13 * [wiki:Commentary/Rts/HaskellExecution/Registers Registers] 
     14 * [wiki:Commentary/Rts/HaskellExecution/FunctionCalls Function Calls] 
     15 * [wiki:Commentary/Rts/HaskellExecution/CallingConvention Call and Return Conventions] 
     16 * [wiki:Commentary/Rts/HaskellExecution/HeapChecks Heap and Stack checks] 
     17 * [wiki:Commentary/Rts/HaskellExecution/Updates Updates]