Skip to content
  • Simon Marlow's avatar
    [project @ 2002-12-11 15:36:20 by simonmar] · 0bffc410
    Simon Marlow authored
    Merge the eval-apply-branch on to the HEAD
    ------------------------------------------
    
    This is a change to GHC's evaluation model in order to ultimately make
    GHC more portable and to reduce complexity in some areas.
    
    At some point we'll update the commentary to describe the new state of
    the RTS.  Pending that, the highlights of this change are:
    
      - No more Su.  The Su register is gone, update frames are one
        word smaller.
    
      - Slow-entry points and arg checks are gone.  Unknown function calls
        are handled by automatically-generated RTS entry points (AutoApply.hc,
        generated by the program in utils/genapply).
    
      - The stack layout is stricter: there are no "pending arguments" on
        the stack any more, the stack is always strictly a sequence of
        stack frames.
    
        This means that there's no need for LOOKS_LIKE_GHC_INFO() or
        LOOKS_LIKE_STATIC_CLOSURE() any more, and GHC doesn't need to know
        how to find the boundary between the text and data segments (BIG WIN!).
    
      - A couple of nasty hacks in the mangler caused by the neet to
        identify closure ptrs vs. info tables have gone away.
    
      - Info tables are a bit more complicated.  See InfoTables.h for the
        details.
    
      - As a side effect, GHCi can now deal with polymorphic seq.  Some bugs
        in GHCi which affected primitives and unboxed tuples are now
        fixed.
    
      - Binary sizes are reduced by about 7% on x86.  Performance is roughly
        similar, some programs get faster while some get slower.  I've seen
        GHCi perform worse on some examples, but haven't investigated
        further yet (GHCi performance *should* be about the same or better
        in theory).
    
      - Internally the code generator is rather better organised.  I've moved
        info-table generation from the NCG into the main codeGen where it is
        shared with the C back-end; info tables are now emitted as arrays
        of words in both back-ends.  The NCG is one step closer to being able
        to support profiling.
    
    This has all been fairly thoroughly tested, but no doubt I've messed
    up the commit in some way.
    0bffc410