Changes between Version 61 and Version 62 of Commentary/Compiler/StackAreas


Ignore:
Timestamp:
Jun 30, 2008 4:09:29 PM (6 years ago)
Author:
dias
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Compiler/StackAreas

    v61 v62  
    7272 
    7373 
    74 Note: A `RegSlot` is laid out in the same fashion, with the offset 0 pointing off the high byte of the stack slot. To address an 8-byte double-word, we would use the offset 8. To address only the high word of the same stack slot, we would use the offset 4. 
     74A `RegSlot` is laid out in the same fashion, with the offset 0 pointing off the high byte of the stack slot. To address an 8-byte double-word, we would use the offset 8. To address only the high word of the same stack slot, we would use the offset 4. 
    7575 
    76  
    77 Note: We don't have a virtual frame pointer in this story, but do we really want it? Here's a minor argument against: it requires special treatment by some analyses in Quick C-- (on the other hand, QC-- doesn't have distinguished global registers, so it might not even be an issue in GHC, which has many distinguished global registers). 
     76Currently, the intermediate code does not explicitly use a virtual frame pointer, but when we talk about offsets into the stack, we implicitly assume that there is a virtual frame pointer that points just off the oldest byte of the return address on entry to the procedures. 
    7877 
    7978 
     
    8483   Area |-> VirtualOffset 
    8584}}} 
    86 which assigns a virtual stack slot (i.e offset relative to the virtual frame pointer) to each `Area`.   '''Mutter about vfp'''. 
     85which assigns a virtual stack slot (i.e offset relative to the virtual frame pointer) to each `Area`. 
    8786 
    8887A naive approach to laying out the stack would be to give each variable its own stack slot for spilling, and allocate only the ends of the stack frame for parameter-passing areas. But this approach misses two opportunities for optimization: