1. 07 Apr, 2006 1 commit
    • Simon Marlow's avatar
      Reorganisation of the source tree · 0065d5ab
      Simon Marlow authored
      Most of the other users of the fptools build system have migrated to
      Cabal, and with the move to darcs we can now flatten the source tree
      without losing history, so here goes.
      The main change is that the ghc/ subdir is gone, and most of what it
      contained is now at the top level.  The build system now makes no
      pretense at being multi-project, it is just the GHC build system.
      No doubt this will break many things, and there will be a period of
      instability while we fix the dependencies.  A straightforward build
      should work, but I haven't yet fixed binary/source distributions.
      Changes to the Building Guide will follow, too.
  2. 21 Jan, 2006 2 commits
  3. 06 Apr, 2006 5 commits
  4. 05 Apr, 2006 3 commits
  5. 30 Mar, 2006 3 commits
  6. 29 Mar, 2006 3 commits
  7. 23 Mar, 2006 1 commit
  8. 28 Mar, 2006 1 commit
  9. 27 Mar, 2006 3 commits
    • Simon Marlow's avatar
      Add a new primitive forkOn#, for forking a thread on a specific Capability · c520a3a2
      Simon Marlow authored
      This gives some control over affinity, while we figure out the best
      way to automatically schedule threads to make best use of the
      available parallelism.
      In addition to the primitive, there is also:
        GHC.Conc.forkOnIO :: Int -> IO () -> IO ThreadId
      where 'forkOnIO i m' creates a thread on Capability (i `rem` N), where
      N is the number of available Capabilities set by +RTS -N.
      Threads forked by forkOnIO do not automatically migrate when there are
      free Capabilities, like normal threads do.  Still, if you're using
      forkOnIO exclusively, it's a good idea to do +RTS -qm to disable work
      pushing anyway (work pushing takes too much time when the run queues
      are large, this is something we need to fix).
    • Simon Marlow's avatar
      eliminate a warning · 5ed93b10
      Simon Marlow authored
    • Simon Marlow's avatar
      elimiante a couple of warnings · 24fd303c
      Simon Marlow authored
  10. 24 Mar, 2006 3 commits
    • Simon Marlow's avatar
      fix a warning · a1b4e3b8
      Simon Marlow authored
    • Simon Marlow's avatar
      Add some more flexibility to the multiproc scheduler · 4368121d
      Simon Marlow authored
      There are two new options in the -threaded RTS:
        -qm       Don't automatically migrate threads between CPUs
        -qw       Migrate a thread to the current CPU when it is woken up
      previously both of these were effectively off, i.e. threads were
      migrated between CPUs willy-milly, and threads were always migrated to
      the current CPU when woken up.  This is the first step in tweaking the
      scheduling for more effective work balancing, there will no doubt be
      more to come.
    • duncan.coutts@worc.ox.ac.uk's avatar
      mkDerivedConstants.c depends on ghcplatform.h · 354cefe7
      duncan.coutts@worc.ox.ac.uk authored
      I think this missing dep is what broke my parallel build
      I used make -j2 with ghc- and got:
      ==fptools== make boot -wr --jobserver-fds=3,11 -j;
      in /var/tmp/portage/ghc-6.4.2_pre20060323/work/ghc-
      Creating ghcplatform.h...
      gcc -O -O2 -march=k8 -pipe -Wa,--noexecstack    -c mkDerivedConstants.c -o mkDerivedConstants.o
      In file included from ghcconfig.h:5,
                       from Stg.h:42,
                       from Rts.h:19,
                       from mkDerivedConstants.c:20:
      ghcplatform.h:1:1: unterminated #ifndef
      With this patch applied I can no longer repoduce this build bug.
      So I think this patch should be applied to the cvs ghc-6-4-branch too.
  11. 27 Mar, 2006 2 commits
  12. 25 Mar, 2006 1 commit
  13. 08 Mar, 2006 1 commit
  14. 24 Mar, 2006 3 commits
  15. 23 Mar, 2006 2 commits
    • Volker Stolz's avatar
      Accept amd64-*-freebsd architecture · 1eff6846
      Volker Stolz authored
    • Simon Marlow's avatar
      gcc is getting smarter, so we need to hit it with a bigger stick · 7aede9b1
      Simon Marlow authored
      On x86_64 we are using C argument registers for global registers in
      the STG machine.  This is always going to be problematic when it comes
      to making C calls from STG and compiling via C.  Prior to GCC 4.1.0
      (approx) it was possible to just assign the argument expressions to
      temporaries to avoid a clash.  Now, we need to add an extra dummy
      function call as a barrier between the temporary assignments and the
      actual call.  The dummy call is removed by the mangler.
  16. 18 Mar, 2006 3 commits
  17. 22 Mar, 2006 2 commits
  18. 21 Mar, 2006 1 commit