On Wed, 2009-06-10 at 09:39 +0100, Simon Marlow wrote:
> Yes, I think this is the right way to go.
>
> foreign import prim "has_side_effects commutable foo#" :: ...
>
> and then perhaps all the primops could be defined this way. For the
> inline primops the code generator would have to spot them and generate
> inline code, but all knowledge of the out-of-line primops would be
> outside the compiler itself. primops.txt.pp would go away, as would
> genprimopcode. We get the curried wrappers for free, so no need for the
> PrimOpWrappers module. GHC.Prim would be an ordinary module with source
> code.
Sounds nice :-)
> As an intermediate step, we could just move the out-of-line primops out,
> leaving the inline ones defined in primops.txt.pp.
That's certainly easier.
> All of this is unforced of course, but I think it would be a nice
> cleanup. On the other hand, it would mean that GHC.Prim becomes an
> interface file that GHC has to slurp on startup.
So it means switching from the PrimOp enumeration to a Prim data type
that records all the info like commutable, inline/out-of-line etc.
Perhaps the intermediate state would be keeping the existing PrimOp enum
as BuiltinPrimOp and using it to pre-populate the environment with
PrimOp values (calling the existing generated functions to get the
commutable, wrapper etc info). Something like:
data PrimOp = PrimOp {
primOpInfo :: ...
primOpOutOfLine :: ...
primOpCanFail :: ...
primOpHasSideEffects :: ...
primOpNeedsWrapper :: ...
commutableOp :: ...
-- | Some PrimOps are built-in and sometimes we need to treat
-- some of them specially.
primOpBuiltin :: Maybe BuiltinPrimOp
primOpTag :: ...
}
instance PrimOp Eq/Ord where {- using primOpTag -}
> On the patches themselves:
>
> - I think we should drop the requirement for "unsafe", it doesn't
> have any meaning for primops
I figured we should require one or the other, just so that we know there
is not any code using the other one in case we decide to give it a
meaning later. Otherwise one can write either and have it accepted but
the information not used. How about just reversing the requirement (ie
require the default of safe)?
> - why are arguments required to be unboxed?
Because it's simpler to start with. It means we do not need to generate
any boxing/unboxing wrapper code. All current out-of-line primops use
unboxed types so there's no immediate need. It's a restriction that can
be lifted later eg once we unify the primop and normal calling
conventions.
Duncan
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
