1. 10 Dec, 2006 1 commit
  2. 09 Dec, 2006 3 commits
  3. 07 Dec, 2006 5 commits
  4. 06 Dec, 2006 3 commits
  5. 04 Dec, 2006 2 commits
  6. 05 Dec, 2006 4 commits
  7. 04 Dec, 2006 1 commit
  8. 03 Dec, 2006 2 commits
  9. 01 Dec, 2006 4 commits
    • Simon Marlow's avatar
      Add support for the IO manager thread on Windows · 80a766fd
      Simon Marlow authored
      Fixes #637.
      The implications of this change are:
        - threadDelay on Windows no longer creates a new OS thread each time,
          instead it communicates with the IO manager thread in the same way as
          on Unix.
        - deadlock detection now works the same way on Windows as on Unix; that
          is the timer interrupt wakes up the IO manager thread, which causes
          the scheduler to check for deadlock.
        - Console events now get sent to the IO manager thread, in the same way as
          signals do on Unix.  This means that console events should behave more
          reliably with -threaded on Windows.
      All this applies only with -threaded.  Without -threaded, the old
      ConsoleEvent code is still used.
      After some testing, this could be pushed to the 6.6 branch.
    • Simon Marlow's avatar
      Remove the Windows Async IO Manager completely in THREADED_RTS mode · de6c8e52
      Simon Marlow authored
      It isn't used here anyway, just making sure the code doesn't get compiled in.
    • wolfgang.thaller@gmx.net's avatar
      Decouple -O from -fvia-C · 8971f720
      wolfgang.thaller@gmx.net authored
      Nowadays, there are situations where -fvia-C is definitely unwanted, such
      as when -fPIC is used on some platforms, so we do not want implicit -fvia-C
      any more.
    • simonpj@microsoft.com's avatar
      q · ea2d0a53
      simonpj@microsoft.com authored
  10. 21 Nov, 2006 1 commit
  11. 17 Nov, 2006 1 commit
  12. 09 Oct, 2006 1 commit
  13. 06 Oct, 2006 1 commit
  14. 29 Nov, 2006 9 commits
    • simonpj@microsoft.com's avatar
      Remove trace · b20a90d8
      simonpj@microsoft.com authored
    • simonpj@microsoft.com's avatar
      Remove bogus comment · 4706dd57
      simonpj@microsoft.com authored
    • simonpj@microsoft.com's avatar
      Teach SpecConstr how to handle mutually-recursive functions · 9fad5a80
      simonpj@microsoft.com authored
      Roman found cases where it was important to do SpecConstr for
      mutually-recursive definitions.  Here is one:
      	foo :: Maybe Int -> Int
      	foo Nothing  = 0
      	foo (Just 0) = foo Nothing
      	foo (Just n) = foo (Just (n-1))
      By the time SpecConstr gets to it, it looks like this:
      	lvl = foo Nothing
      	foo Nothing  = 0
      	foo (Just 0) = lvl
      	foo (Just n) = foo (Just (n-1))
      Happily, it turns out to be rather straightforward to generalise the
      transformation to mutually-recursive functions.  Look, ma, only 4 
      extra lines of ocde!
    • simonpj@microsoft.com's avatar
      Improve the loop-breaking heuristics · 1dca1587
      simonpj@microsoft.com authored
      The loop-breaking heuristics were making it a high priority to
      avoid choosing a variable as a loop breaker if its *type* was a 
      data type.  The reason is that it's very good to be able to "see"
      constructor applications.
      But it's only good if the constructor application is *visible*, 
      so that is what I test for now.  I found a case (when testing 
      SpecConstr) where I had a Rec like this:
      	rec { lvl = foo Nothing
      	      foo = ...
      	        RULE foo Nothing = ...
      Even if lvl has a data type, it's much better to make lvl the loop
      breaker, not foo, so that foo's RULE is visible in lvl's RHS.
    • simonpj@microsoft.com's avatar
      Comments only · beade0a1
      simonpj@microsoft.com authored
    • simonpj@microsoft.com's avatar
      Make SpecConstr work right for nullary constructors · 4d109022
      simonpj@microsoft.com authored
      For totally stupid reasons, SpecConstr didn't work for the (particularly
      easy) case of nullary constructors like True and False.  I just had some
      equations in the wrong order, so that a Var case came first, which 
      matches a nullary constructor, with the constructor-application case
      The fix is easy.  I did a bit of refactoring at the same time.
    • wolfgang.thaller@gmx.net's avatar
      x86_64 NCG: fix register usage for CALLs · 561e5742
      wolfgang.thaller@gmx.net authored
      For varargs calls, CALL reads the %al register; record that fact for the benefit of the
      register allocator.
      (There was a previous attempt to do this, but it was broken.)
    • sof@galois.com's avatar
      Add Win32/configure.ac to the mix · 3495dc88
      sof@galois.com authored
    • andy@galois.com's avatar
      TickBox representation change · 8100cd43
      andy@galois.com authored
      This changes the internal representation of TickBoxes,
              Note (TickBox "module" n)  <expr>
              case tick<module,n> of
                _ -> <expr>
      tick has type :: #State #World, when the module and tick numbe
      are stored inside IdInfo.
      Binary tick boxes change from
               Note (BinaryTickBox "module" t f) <expr>
                btick<module,t,f> <expr>
      btick has type :: Bool -> Bool, with the module and tick number
      stored inside IdInfo.
  15. 01 Nov, 2006 1 commit
  16. 29 Nov, 2006 1 commit