1. 04 Dec, 2004 1 commit
  2. 20 Nov, 2004 1 commit
  3. 11 Nov, 2004 1 commit
  4. 30 Sep, 2004 1 commit
  5. 20 Sep, 2004 1 commit
  6. 19 Sep, 2004 1 commit
  7. 11 Sep, 2003 1 commit
  8. 29 Jul, 2003 1 commit
    • panne's avatar
      [project @ 2003-07-29 19:08:40 by panne] · f7064672
      panne authored
      Revert to previous commit, i.e. ProjectVersion is now a plain "6.1"
      again, not "6.1.20030727". It looked like an accidental commit and
      broke my build scripts.
      f7064672
  9. 28 Jul, 2003 1 commit
    • simonmar's avatar
      [project @ 2003-07-28 16:05:30 by simonmar] · 387a411e
      simonmar authored
      Disable update-in-place.  In its current form, it has a serious bug:
      if the thunk being updated happens to have turned into a BLACKHOLE_BQ,
      then the mutable list will be corrupted by the update.
      
      Disabling update-in-place has some performance implications: many
      programs are not affected, but one program in nofib (nucleic2) goes
      about 20% slower.  However, I can get it to go 300% faster by adding a
      few strictness annotations and compiling with -funbox-strict-fields.
      387a411e
  10. 24 Jul, 2003 1 commit
  11. 23 May, 2003 1 commit
  12. 20 May, 2003 1 commit
  13. 19 May, 2003 1 commit
  14. 28 Mar, 2003 1 commit
  15. 24 Mar, 2003 1 commit
    • simonmar's avatar
      [project @ 2003-03-24 14:46:53 by simonmar] · b3f53081
      simonmar authored
      Fix some bugs in compacting GC.
      
      Bug 1: When threading the fields of an AP or PAP, we were grabbing the
      info table of the function without unthreading it first.
      
      Bug 2: eval_thunk_selector() might accidentally find itself in
      to-space when going through indirections in a compacted generation.
      We must check for this case and bale out if necessary.
      
      Bug 3: This is somewhat more nasty.  When we have an AP or PAP that
      points to a BCO, the layout info for the AP/PAP is in the BCO's
      instruction array, which is two objects deep from the AP/PAP itself.
      The trouble is, during compacting GC, we can only safely look one
      object deep from the current object, because pointers from objects any
      deeper might have been already updated to point to their final
      destinations.
      
      The solution is to put the arity and bitmap info for a BCO into the
      BCO object itself.  This means BCOs become variable-length, which is a
      slight annoyance, but it also means that looking up the arity/bitmap
      is quicker.  There is a slight reduction in complexity in the byte
      code generator due to not having to stuff the bitmap at the front of
      the instruction stream.
      b3f53081
  16. 05 Mar, 2003 1 commit
    • simonmar's avatar
      [project @ 2003-03-05 10:22:22 by simonmar] · 9a1114e3
      simonmar authored
      Duh.  hsc2hs should be in $(GhcBinDistShScripts), not
      $(GhcBinDistBins), otherwise it doesn't get the right directories
      tacked on the front at installation time.  Strange that nobody
      complained that hsc2hs wasn't working from a binary dist *shrug*.
      9a1114e3
  17. 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
  18. 30 Sep, 2002 1 commit
  19. 09 Aug, 2002 1 commit
  20. 08 Jul, 2002 1 commit
  21. 05 Jul, 2002 1 commit
  22. 02 Jul, 2002 1 commit
  23. 01 Apr, 2002 1 commit
  24. 27 Feb, 2002 1 commit
  25. 12 Feb, 2002 1 commit
    • simonmar's avatar
      [project @ 2002-02-12 15:17:13 by simonmar] · 2cc5b907
      simonmar authored
      Switch over to the new hierarchical libraries
      ---------------------------------------------
      
      This commit reorganises our libraries to use the new hierarchical
      module namespace extension.
      
      The basic story is this:
      
         - fptools/libraries contains the new hierarchical libraries.
           Everything in here is "clean", i.e. most deprecated stuff has
           been removed.
      
      	- fptools/libraries/base is the new base package
      	  (replacing "std") and contains roughly what was previously
      	  in std, lang, and concurrent, minus deprecated stuff.
      	  Things that are *not allowed* in libraries/base include:
      		Addr, ForeignObj, ByteArray, MutableByteArray,
      		_casm_, _ccall_, ``'', PrimIO
      
      	  For ByteArrays and MutableByteArrays we use UArray and
      	  STUArray/IOUArray respectively now.
      
      	  Modules previously called PrelFoo are now under
      	  fptools/libraries/GHC.  eg. PrelBase is now GHC.Base.
      
      	- fptools/libraries/haskell98 provides the Haskell 98 std.
      	  libraries (Char, IO, Numeric etc.) as a package.  This
      	  package is enabled by default.
      
      	- fptools/libraries/network is a rearranged version of
      	  the existing net package (the old package net is still
      	  available; see below).
      
      	- Other packages will migrate to fptools/libraries in
      	  due course.
      
           NB. you need to checkout fptools/libraries as well as
           fptools/hslibs now.  The nightly build scripts will need to be
           tweaked.
      
         - fptools/hslibs still contains (almost) the same stuff as before.
           Where libraries have moved into the new hierarchy, the hslibs
           version contains a "stub" that just re-exports the new version.
           The idea is that code will gradually migrate from fptools/hslibs
           into fptools/libraries as it gets cleaned up, and in a version or
           two we can remove the old packages altogether.
      
         - I've taken the opportunity to make some changes to the build
           system, ripping out the old hslibs Makefile stuff from
           mk/target.mk; the new package building Makefile code is in
           mk/package.mk (auto-included from mk/target.mk).
      
           The main improvement is that packages now register themselves at
           make boot time using ghc-pkg, and the monolithic package.conf
           in ghc/driver is gone.
      
           I've updated the standard packages but haven't tested win32,
           graphics, xlib, object-io, or OpenGL yet.  The Makefiles in
           these packages may need some further tweaks, and they'll need
           pkg.conf.in files added.
      
         - Unfortunately all this rearrangement meant I had to bump the
           interface-file version and create a bunch of .hi-boot-6 files :-(
      2cc5b907
  26. 29 Jan, 2002 1 commit
  27. 10 Jan, 2002 1 commit
  28. 10 Sep, 2001 3 commits
  29. 30 Aug, 2001 1 commit
  30. 31 Jul, 2001 1 commit
  31. 16 Jul, 2001 1 commit
  32. 05 Jul, 2001 1 commit
  33. 28 Jun, 2001 2 commits
  34. 27 Jun, 2001 1 commit
  35. 15 Jun, 2001 1 commit
  36. 14 Jun, 2001 2 commits
    • simonmar's avatar
      [project @ 2001-06-14 13:29:30 by simonmar] · e50a36b1
      simonmar authored
      fix typo in Simon's commit (cGHC_RAWCPP ==> GHC_RAWCPP)
      e50a36b1
    • simonpj's avatar
      [project @ 2001-06-14 12:50:05 by simonpj] · 16d5d1c7
      simonpj authored
      ----------------------
      	Installation packaging
      	----------------------
      
      GHC runs various system programs like
      	cp, touch
      	gcc, as, ld etc
      
      On Windows we plan to deliver these programs along with GHC,
      so we have to be careful about where to find them.
      
      This commit isolates all these dependencies in a single module
      
      	main/SysTools.lhs
      
      Most of the #ifdefery for mingw has moved into this module.
      There's some documentation in SysTools.lhs
      
      Along the way I did lots of other cleanups.  In particular
      
        * There is no more 'globbing' needed when calling runSomething
        * All file removal goes via the standard Directory.removeFile
        * TmpFiles.hs has gone; absorbed into SysTools
        * Some DynFlag stuff has moved from DriverFlags to CmdLineOpts
      
      
      Still to do:
      
        **	I'm a bit concerned that calling removeFile one at a time
      	when deleting masses of split-object files is going to be
      	rather slow
      
        **	GHC now expects to find split,mangle,unlit in
      		libdir/extra-bin
      	instead of just
      		libdir
      
      	So something needs to change in the Unix installation scripts
      
        **    The "ineffective C preprocessor" is a perversion and should die
      16d5d1c7