Changes between Version 3 and Version 4 of Commentary/Compiler/StackAreas


Ignore:
Timestamp:
May 19, 2008 9:18:05 AM (6 years ago)
Author:
dias
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Compiler/StackAreas

    v3 v4  
    2828{{{ 
    2929f: 
    30    x = m[stack(f, 1)]; // copy the argument from stack area `f' to  
     30   x = m[stack(f, 1)]; // copy the argument from stack area `f' to local x 
    3131   y = x; 
    3232 
     
    3535   sp = stack(L, 1); // Make room on the stack for the arguments 
    3636   m[stack(L, 1)] = x; // copy the argument 
    37    m[stack(L, 0)] = L; 
     37   m[stack(L, 0)] = L; // copy the return address 
    3838   call g(); 
    3939 
     
    4343}}} 
    4444 
    45 The exact syntax will probably be a bit different, making the representation of the stack slots abstract, but there's the gist of it. 
     45The exact syntax will probably be a bit different, but there's the gist of it. 
    4646 
    47 Ah, but do we assign stack slots? As it turns out, an important optimization in GHC is to use return values as stack slots whenever possible. For example, given the program 
     47But how do we map the stack slots to actual hardware locations? As it turns out, it is quite common in GHC that the first definition of a variable comes when its value is returned from a function call. If the value is returned on the stack, then an important optimization is to avoid copying that value to some other ``local`` location on the stack. How is that achieved? By making sure the location where the value is returned is defined as its local location. 
     48 
     49For example, 
    4850 
    4951{{{