1. 26 Jun, 2009 1 commit
  2. 25 Jun, 2009 2 commits
  3. 24 Jun, 2009 3 commits
  4. 23 Jun, 2009 2 commits
    • Simon Marlow's avatar
      Fix buffering problem when GHCi is using the new IO library · f540ac1c
      Simon Marlow authored
      Behind the scenes, the new IO library always does buffering for read
      Handles regardless of NoBuffering.  Normally this isn't visible, but
      it causes a problem in GHCi where there are two stdin Handles.
      This should fix those ghci test failures that sprung up in full
      testsuite runs recently.
    • Simon Marlow's avatar
      Optimise the %.hi : %.o rule · 0fb9ad3a
      Simon Marlow authored
      Previously this rule had a sanity check for the existence of the .o
      file.  However, the sanity check is expensive, especially on Windows,
      because it requires spawning a shell.  So now we use an empty command
      This change reduced the time to do 'make' in an up-to-date tree on
      Windows from 33s to 16s for me.  (the actual saving depends on how
      much rebuilding you've been doing, and how many .hi files are older
      than their .o files).
      The comments in this file now describe various versions of the rule
      that don't work.
  5. 22 Jun, 2009 1 commit
  6. 23 Jun, 2009 2 commits
  7. 22 Jun, 2009 3 commits
  8. 17 Jun, 2009 1 commit
  9. 03 Jun, 2009 1 commit
  10. 22 Jun, 2009 1 commit
  11. 17 Jun, 2009 1 commit
  12. 16 Jun, 2009 3 commits
  13. 15 Jun, 2009 3 commits
  14. 14 Jun, 2009 1 commit
  15. 13 Jun, 2009 4 commits
  16. 11 Jun, 2009 2 commits
  17. 13 Jun, 2009 1 commit
  18. 12 Jun, 2009 1 commit
    • Duncan Coutts's avatar
      Add and export rts_unsafeGetMyCapability from rts · 85df606a
      Duncan Coutts authored
      We need this, or something equivalent, to be able to implement
      stgAllocForGMP outside of the rts. That's because we want to use
      allocateLocal which allocates from the given capability without
      having to take any locks. In the gmp primops we're basically in
      an unsafe foreign call, that is a context where we hold a current
      capability. So it's safe for us to use allocateLocal. We just
      need a way to get the current capability. The method to get the
      current capability varies depends on whether we're using the
      threaded rts or not. When stgAllocForGMP is built inside the rts
      that's ok because we can do it conditionally on THREADED_RTS.
      Outside the rts we need a single api we can call without knowing
      if we're talking to a threaded rts or not, hence this addition.
  19. 11 Jun, 2009 4 commits
  20. 09 Jun, 2009 3 commits
    • Duncan Coutts's avatar
      Add PrimCall to the STG layer and update Core -> STG translation · cbbee4e8
      Duncan Coutts authored
      It adds a third case to StgOp which already hold StgPrimOp and StgFCallOp.
      The code generation for the new StgPrimCallOp case is almost exactly the
      same as for out-of-line primops. They now share the tailCallPrim function.
      In the Core -> STG translation we map foreign calls using the "prim"
      calling convention to the StgPrimCallOp case. This is because in Core we
      represent prim calls using the ForeignCall stuff. At the STG level however
      the prim calls are really much more like primops than foreign calls.
    • Duncan Coutts's avatar
      Desugaring for "foreign import prim" · 5b7e2a87
      Duncan Coutts authored
      Unlike normal foreign imports which desugar into a separate worker and
      wrapper, we use just a single wrapper decleration. The representation
      in Core of the call is currently as a foreign call. This means the
      args are all treated as fully strict. This is ok at the moment because
      we restrict the types for foreign import prim to be of unboxed types,
      however in future we may want to make prim imports be the normal cmm
      calling convention for Haskell functions, in which case we would not
      be able to assume all args are strict. At that point it may make more
      sense to represent cmm/prim calls distinct from foreign calls, and
      more like the we the existing PrimOp calls are handled.
    • Duncan Coutts's avatar
      Typechecking for "foreign import prim" · 2da37f4f
      Duncan Coutts authored
      The main restriction is that all args and results must be unboxed types.
      In particular we allow unboxed tuple results (which is a primary
      motivation for the whole feature). The normal rules apply about
      "void rep" result types like State#. We only allow "prim" calling
      convention for import, not export. The other forms of import, "dynamic",
      "wrapper" and data label are banned as a conseqence of checking that the
      imported name is a valid C string. We currently require prim imports to
      be marked unsafe, though this is essentially arbitrary as the safety
      information is unused.