- 16 Jun, 2009 2 commits
-
-
Ian Lynagh authored
-
Ian Lynagh authored
-
- 15 Jun, 2009 3 commits
-
-
Ian Lynagh authored
When configure tests for a feature it may not generate warning-free C code, and thus may think that the feature doesn't exist if -Werror is on.
-
Ian Lynagh authored
-
Ian Lynagh authored
-
- 14 Jun, 2009 1 commit
-
-
Ian Lynagh authored
-
- 13 Jun, 2009 4 commits
-
-
Duncan Coutts authored
Nothing from gmp is used in the rts anymore.
-
Duncan Coutts authored
-
Duncan Coutts authored
and remove the implementations of stg(Alloc|Realloc|Dealloc)ForGMP
-
Duncan Coutts authored
The implementations are still in the rts.
-
- 11 Jun, 2009 2 commits
-
-
Ian Lynagh authored
-
Ian Lynagh authored
-
- 13 Jun, 2009 1 commit
-
-
Duncan Coutts authored
In particular we need alloc_blocks and alloc_blocks_lim for MAYBE_GC. The gmp cmm primops also use stg_ARR_WORDS_info.
-
- 12 Jun, 2009 1 commit
-
-
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.
-
- 11 Jun, 2009 4 commits
-
-
Duncan Coutts authored
In practise currently you also need UnliftedFFITypes, however the restriction to just unlifted types may be lifted in future.
-
Duncan Coutts authored
We don't handle "foreign import prim" in TH stuff.
-
Ian Lynagh authored
-
Duncan Coutts authored
The safe/unsafe annotation doesn't currently mean anything for prim. Just in case we decide it means something later it's better to stick to using one or the other consistently. We decided that using safe is the better one to require (and it's also the default).
-
- 09 Jun, 2009 5 commits
-
-
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 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 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.
-
Duncan Coutts authored
We only allow simple function label imports, not the normal complicated business with "wrapper" "dynamic" or data label "&var" imports.
-
Duncan Coutts authored
First in a series of patches to add the feature. This patch just adds PrimCallConv to the CCallConv type.
-
- 20 Jun, 2009 2 commits
-
-
Ian Lynagh authored
-
Ian Lynagh authored
-
- 17 Jun, 2009 1 commit
-
-
Ian Lynagh authored
-
- 16 Jun, 2009 1 commit
-
-
Ian Lynagh authored
The ${1+"$@"} was being evaluated by make, rather than being escaped.
-
- 18 Jun, 2009 1 commit
-
-
Simon Marlow authored
-
- 16 Jun, 2009 1 commit
-
-
Simon Marlow authored
See comments for details
-
- 18 May, 2009 1 commit
-
-
Simon Marlow authored
-
- 16 Jun, 2009 4 commits
-
-
Simon Marlow authored
-
Simon Marlow authored
Including help for directory-specific targets, such as 'make 1' in ghc
-
Simon Marlow authored
-
Simon Marlow authored
-
- 15 Jun, 2009 6 commits
-
-
Simon Marlow authored
-
Simon Marlow authored
-
Simon Marlow authored
-
Simon Marlow authored
i.e. not dph, and hence not stage2
-
Simon Marlow authored
i.e. not dph, and hence not the stage 2 compiler.
-
Simon Marlow authored
Fixes failure when Haddocking Data.Monoid in libraries/base
-