This project is mirrored from https://gitlab.haskell.org/ghc/ghc.git. Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
  1. 12 Nov, 2003 1 commit
    • sof's avatar
      [project @ 2003-11-12 17:27:00 by sof] · a814590c
      sof authored
      Tidy up a couple of unportable coding issues:
      
      - conditionally use empty structs.
      - use GNU attributes only if supported.
      - 'long long' usage
      - use of 'inline' in declarations and definitions.
      
      Upshot of these changes is that MSVC is now capable of compiling
      the non-.hc portions of the RTS.
      a814590c
  2. 30 Jun, 2003 1 commit
  3. 14 May, 2003 1 commit
    • simonmar's avatar
      [project @ 2003-05-14 09:13:52 by simonmar] · 7a236a56
      simonmar authored
      Change the way SRTs are represented:
      
      Previously, the SRT associated with a function or thunk would be a
      sub-list of the enclosing top-level function's SRT.  But this approach
      can lead to lots of duplication: if a CAF is referenced in several
      different thunks, then it may appear several times in the SRT.
      Let-no-escapes compound the problem, because the occurrence of a
      let-no-escape-bound variable would expand to all the CAFs referred to
      by the let-no-escape.
      
      The new way is to describe the SRT associated with a function or thunk
      as a (pointer+offset,bitmap) pair, where the pointer+offset points
      into some SRT table (the enclosing function's SRT), and the bitmap
      indicates which entries in this table are "live" for this closure.
      The bitmap is stored in the 16 bits previously used for the length
      field, but this rarely overflows.  When it does overflow, we store the
      bitmap externally in a new "SRT descriptor".
      
      Now the enclosing SRT can be a set, hence eliminating the duplicates.
      
      Also, we now have one SRT per top-level function in a recursive group,
      where previously we used to have one SRT for the whole group.  This
      helps keep the size of SRTs down.
      
      Bottom line: very little difference most of the time.  GHC itself got
      slightly smaller.  One bad case of a module in GHC which had a huge
      SRT has gone away.
      
      While I was in the area:
      
        - Several parts of the back-end require bitmaps.  Functions for
          creating bitmaps are now centralised in the Bitmap module.
      
        - We were trying to be independent of word-size in a couple of
          places in the back end, but we've now abandoned that strategy so I
          simplified things a bit.
      7a236a56
  4. 11 Dec, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-12-11 15:36:20 by simonmar] · 0bffc410
      simonmar 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
  5. 25 Sep, 2002 1 commit
  6. 22 Nov, 2001 1 commit
    • simonmar's avatar
      [project @ 2001-11-22 14:25:11 by simonmar] · db61851c
      simonmar authored
      Retainer Profiling / Lag-drag-void profiling.
      
      This is mostly work by Sungwoo Park, who spent a summer internship at
      MSR Cambridge this year implementing these two types of heap profiling
      in GHC.
      
      Relative to Sungwoo's original work, I've made some improvements to
      the code:
      
         - it's now possible to apply constraints to retainer and LDV profiles
           in the same way as we do for other types of heap profile (eg.
           +RTS -hc{foo,bar} -hR -RTS gives you a retainer profiling considering
           only closures with cost centres 'foo' and 'bar').
      
         - the heap-profile timer implementation is cleaned up.
      
         - heap profiling no longer has to be run in a two-space heap.
      
         - general cleanup of the code and application of the SDM C coding
           style guidelines.
      
      Profiling will be a little slower and require more space than before,
      mainly because closures have an extra header word to support either
      retainer profiling or LDV profiling (you can't do both at the same
      time).
      
      We've used the new profiling tools on GHC itself, with moderate
      success.  Fixes for some space leaks in GHC to follow...
      db61851c
  7. 06 Feb, 2001 1 commit
  8. 26 Jan, 2001 1 commit
  9. 11 Dec, 2000 1 commit
  10. 04 Dec, 2000 1 commit
  11. 13 Nov, 2000 1 commit
  12. 07 Nov, 2000 1 commit
  13. 06 Oct, 2000 1 commit
    • simonmar's avatar
      [project @ 2000-10-06 15:38:06 by simonmar] · 1b8911b4
      simonmar authored
      The GC needs to be cleverer about which address ranges are in
      text/data space if we're dynamically loading modules.
      
      (BTW, this linking stuff is mostly ported from code written by Julian
      Seward for STG Hugs).
      1b8911b4
  14. 17 Aug, 2000 1 commit
    • rrt's avatar
      [project @ 2000-08-17 15:19:17 by rrt] · 0a92ced2
      rrt authored
      Changed HAVE_WIN32_DLL_SUPPORT to ENABLE_WIN32_DLL_SUPPORT so that the
      relevant bits are only used in the dynamic Windows build (as they should be).
      0a92ced2
  15. 16 Aug, 2000 1 commit
    • rrt's avatar
      [project @ 2000-08-16 15:29:34 by rrt] · 67baef13
      rrt authored
      Change use of HAVE_WIN32_DLL_SUPPORT to ENABLE_WIN32_DLL_SUPPORT, to stop
      things going horribly wrong with static linking on win32.
      67baef13
  16. 07 Aug, 2000 1 commit
    • qrczak's avatar
      [project @ 2000-08-07 23:37:19 by qrczak] · 4b172698
      qrczak authored
      Now Char, Char#, StgChar have 31 bits (physically 32).
      "foo"# is still an array of bytes.
      
      CharRep represents 32 bits (on a 64-bit arch too). There is also
      Int8Rep, used in those places where bytes were originally meant.
      readCharArray, indexCharOffAddr etc. still use bytes. Storable and
      {I,M}Array use wide Chars.
      
      In future perhaps all sized integers should be primitive types. Then
      some usages of indexing primops scattered through the code could
      be changed to then-available Int8 ones, and then Char variants of
      primops could be made wide (other usages that handle text should use
      conversion that will be provided later).
      
      I/O and _ccall_ arguments assume ISO-8859-1. UTF-8 is internally used
      for string literals (only).
      
      Z-encoding is ready for Unicode identifiers.
      
      Ranges of intlike and charlike closures are more easily configurable.
      
      I've probably broken nativeGen/MachCode.lhs:chrCode for Alpha but I
      don't know the Alpha assembler to fix it (what is zapnot?). Generally
      I'm not sure if I've done the NCG changes right.
      
      This commit breaks the binary compatibility (of course).
      
      TODO:
      * is* and to{Lower,Upper} in Char (in progress).
      * Libraries for text conversion (in design / experiments),
        to be plugged to I/O and a higher level foreign library.
      * PackedString.
      * StringBuffer and accepting source in encodings other than ISO-8859-1.
      4b172698
  17. 26 May, 2000 1 commit
    • sewardj's avatar
      [project @ 2000-05-26 10:14:33 by sewardj] · fda822c6
      sewardj authored
      Changes to allow Hugs to be built with mingw32, not cygwin.  Also,
      updates so that DietHEP works properly for mingw32.  Most changes are
      trivial (assert --> ASSERT), etc.  For hugs, have deleted queries
      about the width of a terminal window, and so the printing of dots
      as progress indicators is gone too.  No great loss.  Zapped various
      other out-of-date platform-specific junk in machdep.c.
      fda822c6
  18. 17 Mar, 2000 1 commit
  19. 27 Oct, 1999 1 commit
  20. 03 Aug, 1999 1 commit
  21. 06 Jul, 1999 1 commit
  22. 25 Jun, 1999 1 commit
    • simonmar's avatar
      [project @ 1999-06-25 09:13:37 by simonmar] · 6d40c9e6
      simonmar authored
      New define: TABLES_NEXT_TO_CODE says whether info tables are assumed
      to reside just before the code for a function.   We used to use
      USE_MINIINTERPRETER for this function, but it makes sense in certain
      cases to separate the use of tail-calls from tables-next-to-code.
      
      StgMacros: add a couple of missing macros to support update in place.
      6d40c9e6
  23. 13 May, 1999 1 commit
    • simonm's avatar
      [project @ 1999-05-13 17:30:50 by simonm] · 589b7946
      simonm authored
      Support for "unregisterised" builds.  An unregisterised build doesn't
      use the assembly mangler, doesn't do tail jumping (uses the
      mini-interpreter), and doesn't use global register variables.
      
      Plenty of cleanups and bugfixes in the process.
      
      Add way 'u' to GhcLibWays to get unregisterised libs & RTS.
      
      [ note: not *quite* working fully yet... there's still a bug or two
        lurking ]
      589b7946
  24. 11 May, 1999 1 commit
    • keithw's avatar
      [project @ 1999-05-11 16:47:39 by keithw] · eb407ca1
      keithw authored
      (this is number 9 of 9 commits to be applied together)
      
        Usage verification changes / ticky-ticky changes:
      
        We want to verify that SingleEntry thunks are indeed entered at most
        once.  In order to do this, -ticky / -DTICKY_TICKY turns on eager
        blackholing.  We blackhole with new blackholes: SE_BLACKHOLE and
        SE_CAF_BLACKHOLE.  We will enter one of these if we attempt to enter
        a SingleEntry thunk twice.  Note that CAFs are dealt with in by
        codeGen, and ordinary thunks by the RTS.
      
        We also want to see how many times we enter each Updatable thunk.
        To this end, we have modified -ticky.  When -ticky is on, we update
        with a permanent indirection, and arrange that when we enter a
        permanent indirection we count the entry and then convert the
        indirection to a normal indirection.  This gives us a means of
        counting the number of thunks entered again after the first entry.
        Obviously this screws up profiling, and so you can't build a ticky
        and profiling compiler any more.
      
        Also a few other changes that didn't make it into the previous 8
        commits, but form a part of this set.
      eb407ca1
  25. 04 May, 1999 1 commit
  26. 27 Apr, 1999 2 commits
  27. 23 Apr, 1999 1 commit
  28. 23 Mar, 1999 1 commit
  29. 15 Mar, 1999 1 commit
  30. 11 Mar, 1999 1 commit
  31. 03 Mar, 1999 2 commits
  32. 02 Mar, 1999 1 commit
  33. 05 Feb, 1999 1 commit
  34. 13 Jan, 1999 1 commit
    • simonm's avatar
      [project @ 1999-01-13 17:25:37 by simonm] · 4391e44f
      simonm authored
      Added a generational garbage collector.
      
      The collector is reliable but fairly untuned as yet.  It works with an
      arbitrary number of generations: use +RTS -G<gens> to change the
      number of generations used (default 2).
      
      Stats: +RTS -Sstderr is quite useful, but to really see what's going
      on compile the RTS with -DDEBUG and use +RTS -D32.
      
      ARR_PTRS removed - it wasn't used anywhere.
      
      Sanity checking improved:
      	- free blocks are now spammed when sanity checking is turned on
      	- a check for leaking blocks is performed after each GC.
      4391e44f
  35. 02 Dec, 1998 1 commit