Changes between Version 12 and Version 13 of Commentary/Compiler/StackAreas


Ignore:
Timestamp:
Jun 5, 2008 5:20:33 PM (6 years ago)
Author:
dias
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Compiler/StackAreas

    v12 v13  
    55 
    66 
    7 In the old code generator, most of the pipeline refers to variables by name. In fact, we have a phase ordering problem: no compiler phase can name a stack slot until stack layout has been fixed. But stack layout can only be fixed at the end of the pipeline. The consequence of this approach is that we have to provide special treatment for code that must refer to stack slots (e.g. parameter passing in calling conventions, or spills and reloads). In particular, we defined special instructions for !CopyIn and !CopyOut of function arguments, which implicitly stand for an adjustment to the stack pointer and some parallel assignments to the function parameters or return results. Every stage of the back end must cope with these special cases. 
     7In the old code generator, most of the pipeline refers to variables by name. In fact, we have a phase ordering problem: no compiler phase can name a stack slot until stack layout has been fixed. But stack layout can only be fixed at the end of the pipeline. The consequence of this approach is that we have to provide special treatment for code that must refer to stack slots (e.g. parameter passing in calling conventions, or spills and reloads). In particular, we defined special instructions for !CopyIn and !CopyOut of function arguments, which implicitly stand for an adjustment to the stack pointer and some parallel assignments to the function parameters or return results. 
     8 
     9For example, we compile a function call 
     10 
     11{{{ 
     12x, y = f(a, b, c) 
     13}}} 
     14 
     15into the following C--: 
     16 
     17{{{ 
     18  CopyOut(a, b, c); 
     19  call f returns to k; 
     20k: 
     21  CopyIn (x, y) 
     22}}} 
     23 
     24Every stage of the back end must cope with the !CopyIn and !CopyOut pseudoinstructions. 
    825 
    926=== The new approach === 
     
    1936where ''m[e]'' refers to an address ''e'' in memory. 
    2037 
    21 But what about parameter passing? We use a similar technique, but we maintain the relative positions of the arguments. For example, consider a function call: 
     38But what about parameter passing? We use a similar technique, but this time we describe the slot for each location as an offset within the area where the parameters are passed. For example, we compile a function call 
    2239 
    2340{{{ 
     
    2542}}} 
    2643 
     44into approximately the following C--: 
    2745 
     46{{{ 
     47  sp := stack<k + 4>; 
     48  m[stack<k + 1>] := k_info_table; 
     49  m[stack<k + 2>] := a; 
     50  m[stack<k + 3>] := b; 
     51  m[stack<k + 4>] := c; 
     52k:  // on entry to k, sp == stack<k+3> 
     53  x := m[stack<k + 2>] 
     54  y := m[stack<k + 1>] 
     55}}} 
     56 
     57Note that the semantics of the now-unnecessary !CopyIn and !CopyOut are reified by explicit an assignment to the stack pointer and by a series of copy instructions. An optimization that understands copy instructions can improve this code -- without having to worry about understanding the semantics of !CopyIn. 
    2858 
    2959We use the following types: 
     
    4474 
    4575 
    46 == ToDo == 
     76== !ToDo == 
    4777 
    4878 * Explain the stack layout algorithm.