Changes between Version 3 and Version 4 of Commentary/Rts/HaskellExecution/PointerTagging

Jul 27, 2007 11:02:07 AM (10 years ago)



  • Commentary/Rts/HaskellExecution/PointerTagging

    v3 v4  
    4444  * In the continuation of an algebraic case, R1 is assumed tagged
    45   * On entry to a function, R1 is assumed tagged
     45  * On entry to a non-top-level function, R1 is assumed tagged
    4747These assumptions make the code faster: when extracting values from the closure pointed to be R1, we just subtract the (known) tag from the offset.
    49 There is one unexpected consequence of the function entry code assuming that R1 is tagged: the function pointer in a `RET_FUN` stack frame ''must'' be tagged, because it is just loaded into R1 before jumping to the entry code for the function.  This is the single exception to the general rule that tags are optional in pointers found in heap objects.
     49So each place that enters one of these code fragments must ensure that it is correctly tagging R1.  Here are the cases for an algebraic case alternative:
     51  * the scrutinee of the case jumps directly to the alternative, if R1 is already tagged
     52  * the constructor entry code returns to an alternative.  This code adds the correct tag.
     53  * if the case alternative fails a heap or stack check, then the RTS will re-enter the alternative after
     54    GC.  In this case, our re-entry arranges to enter the constructor, so we get the correct tag by
     55    virtue of going through the constructor entry code.
     57Here are the cases for a function:
     59  * we can assume that pointers to non-top-level functions are always tagged, so entering directly
     60    is safe.
     61  * unknown function application goes via `stg_ap_XXX` (see [wiki:Commentary/Rts/HaskellExecution/FunctionCalls#GenericApply Generic Apply). 
     62    The generic apply functions must therefore arrange to correctly tag R1 before entering the function.
    5164== Compacting GC ==