This project is mirrored from 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. 02 Sep, 2004 1 commit
  2. 20 Aug, 2004 1 commit
  3. 13 Aug, 2004 1 commit
  4. 21 May, 2004 1 commit
  5. 18 Apr, 2004 1 commit
  6. 16 Apr, 2004 1 commit
    • igloo's avatar
      [project @ 2004-04-16 02:02:44 by igloo] · 490fd965
      igloo authored
      Change the mangler to allow a tab before .section on sparc. Fixes a
      problem which shows up as symbols not being made global so not being
      defined when compiling with gcc >= 3.something.
  7. 10 Dec, 2003 1 commit
    • wolfgang's avatar
      [project @ 2003-12-10 11:35:24 by wolfgang] · 60ea58ab
      wolfgang authored
      PowerPC Linux support for registerised compilation and native code
      generation. (object splitting and GHCi are still unsupported).
      Code for other platforms is not affected, so MERGE TO STABLE.
  8. 28 Sep, 2003 1 commit
  9. 29 Aug, 2003 2 commits
    • simonmar's avatar
      [project @ 2003-08-29 16:00:25 by simonmar] · 7dc97354
      simonmar authored
      Initial x86-64 (aka amd64) support.
      Unregisterised it works perfectly.  Registerised, I think it's almost
      there, except that I seem to be running into the known codegen bug in
      GCC with register variables (bug #7871 in the gcc bugzilla), which
      means registerised support is basically hosed until the GCC folks
      can get their act together.
      We get 8 more registers on amd64, but only 2 more callee-saves
      registers.  The calling convention seems to pass args in registers by
      default, using the previously-callee-saves %rsi and %rdi as two of the
      new arg registers.
      I think GHCi should work, since we already have 64-bit ELF support
      thanks to Mat Chapman's work on the IA64 port.  I haven't tried GHCi,
      The native code generator should be a breeze, because it's so similar
      to plain x86.
    • simonmar's avatar
      [project @ 2003-08-29 12:05:39 by simonmar] · f16020a8
      simonmar authored
      Remove unused references to $T_create_word
  10. 18 Aug, 2003 2 commits
  11. 16 Aug, 2003 1 commit
  12. 27 Jun, 2003 1 commit
  13. 11 Jun, 2003 1 commit
  14. 10 Jun, 2003 1 commit
  15. 09 Jun, 2003 1 commit
  16. 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.
  17. 10 Apr, 2003 1 commit
  18. 31 Mar, 2003 1 commit
  19. 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
        - As a side effect, GHCi can now deal with polymorphic seq.  Some bugs
          in GHCi which affected primitives and unboxed tuples are now
        - 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.
  20. 08 Dec, 2002 1 commit
  21. 22 Oct, 2002 1 commit
  22. 25 Sep, 2002 2 commits
  23. 23 Sep, 2002 1 commit
  24. 10 Sep, 2002 1 commit
  25. 03 Sep, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-09-03 14:39:06 by simonmar] · b7a0fd6f
      simonmar authored
      Just hit a problem caused by gcc 3.1+: it uses instructions like
      	movl %esi, 4(%esp)
      in the prologue, which the mangler wasn't expecting.  This might fix
      problems that other people have been seeing with gcc 3.1 on x86.
  26. 28 Aug, 2002 1 commit
    • ken's avatar
      [project @ 2002-08-28 19:28:02 by ken] · c994c0e7
      ken authored
      Further mangler changes to get ghc working with gcc 3.04 on the Alpha.
      Jeff Lewis: "The compiler was sometimes emitting the $ label for a symbol
      before the regular label.  This really confused the mangler, and it completely
      scrambled the file."
  27. 27 Aug, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-08-27 09:12:53 by simonmar] · b669d6d9
      simonmar authored
      Replace "Funny global thing" with a better error message, as suggested
      by Alastair Reid.  The message is:
        Warning: retaining unknown function `$_' in output from C compiler
      ("unknown function" is a bit vague, but I couldn't come up with an
      alternative that wasn't misleading).
  28. 21 Aug, 2002 1 commit
    • ken's avatar
      [project @ 2002-08-21 22:06:02 by ken] · 5c553db9
      ken authored
      Use __DISCARD__ to prevent overly aggressive optimization by certain
      gcc versions on the Alpha.  Thanks to Jeffrey Lewis!
  29. 16 Jul, 2002 3 commits
    • simonmar's avatar
      [project @ 2002-07-16 12:05:37 by simonmar] · 2db30d06
      simonmar authored
      un-rot one transformation on x86: we normally transform
      	movl $_blah, %eax
      	jmp  *%eax
      into simply
      	jmp _blah
      but the pattern had rotted w.r.t. gcc so this was no longer applying.
      Should reduce code size measurably.
    • simonmar's avatar
      [project @ 2002-07-16 10:51:12 by simonmar] · 025f5dfe
      simonmar authored
      The restore instruction on Sparc apparently has arguments under GCC
      3.1, which caused one of the patterns to break in the mangler.
      I can now run simple programs compiled with GHC on Sparc using GCC
      3.1, so hopefully this fixes it.
      MERGE TO STABLE (and the previous one).
    • simonmar's avatar
      [project @ 2002-07-16 10:17:37 by simonmar] · 2011da8d
      simonmar authored
      GCC 3.1 on Sparc now uses '.long'.
  30. 12 Jun, 2002 1 commit
  31. 09 Jun, 2002 1 commit
  32. 07 Jun, 2002 1 commit
  33. 03 Jun, 2002 1 commit
    • matthewc's avatar
      [project @ 2002-06-03 13:08:37 by matthewc] · cb5ccf0a
      matthewc authored
      Initial mangling and tailcalls support for IA64.
      Function prologues and epilogues are deleted and we use a single register
      stack frame throughout (with a little register renaming in the mangler...)
      Dropthrough from fast to slow entry point is also implemented.
      Tailcalls are marked and converted into jumps at mangle time.
  34. 29 May, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-05-29 13:44:18 by simonmar] · 1f1287d7
      simonmar authored
      gcc 3.1 broke the mangler again...  this time it seems gcc is adding
      spurious writes to the stack in the prologue, triggered perhaps by
      inline functions.  The code generated for uses of ASSIGN_DBL() and
      ASSIGN_INT64() is really terrible - we should really submit a bug
      report to the gcc folks for this one.
      Anyway, this patch should get us going again; we now toss the spurious
      instructions back into the main part of the code (just in case they
      happened to be there for a good reason).
  35. 28 May, 2002 1 commit