This project is mirrored from https://gitlab.haskell.org/ghc/ghc.git. 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. 11 Jun, 2009 4 commits
  2. 09 Jun, 2009 5 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.
      cbbee4e8
    • 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.
      5b7e2a87
    • 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.
      2da37f4f
    • Duncan Coutts's avatar
      Lexing and parsing for "foreign import prim" · a4005d2d
      Duncan Coutts authored
      We only allow simple function label imports, not the normal complicated
      business with "wrapper" "dynamic" or data label "&var" imports.
      a4005d2d
    • Duncan Coutts's avatar
      Add new FFI calling convention "prim" · 71aa4a47
      Duncan Coutts authored
      First in a series of patches to add the feature.
      This patch just adds PrimCallConv to the CCallConv type.
      71aa4a47
  3. 20 Jun, 2009 2 commits
  4. 17 Jun, 2009 1 commit
  5. 16 Jun, 2009 1 commit
  6. 18 Jun, 2009 1 commit
  7. 16 Jun, 2009 1 commit
  8. 18 May, 2009 1 commit
  9. 16 Jun, 2009 4 commits
  10. 15 Jun, 2009 6 commits
  11. 13 Jun, 2009 2 commits
  12. 12 Jun, 2009 3 commits
  13. 10 Jun, 2009 1 commit
  14. 08 Jun, 2009 1 commit
  15. 29 May, 2009 1 commit
  16. 12 Jun, 2009 1 commit
    • Ian Lynagh's avatar
      Fix the compiler-hs-dependency's · 2675f2b6
      Ian Lynagh authored
      We needed some more $s to delay evaluation until the values are
      available, and the calls needed to be later in the ghc.mk so that
      compiler_stage2_WAYS etc are defined.
      2675f2b6
  17. 11 Jun, 2009 5 commits