On 09/06/2009 19:13, Duncan Coutts wrote:
On Tue, 2009-06-09 at 16:32 +0100, Duncan Coutts wrote:
In particular I'd like to get feedback on the choice of representation
in the Core and STG layers.
In the current patches I use the existing FCall/ForeignCall stuff for
the imported prim functions. I did this rather than trying to add
user-imported prim functions to the PrimOp type because it's pretty
wired in that PrimOp is a simple enumeration. An alternative to what
I've got now might be to unify PrimOp with these extra PrimCall things
(ie have a type containing either), or to make a third kind of IdDetail
in addition to the exiting PrimOpId and FCallId.
The reason that longer term we might not want to stick with using
FCall/ForeignCall is that, as I understand it, after some backend
changes the primop and Haskell function cmm level calling conventions
will be unified and then the foreign import primop could be used at
almost any Haskell function type, not just simple unlifed args and
result.
Another reason we might want to treat them as primops in the Core level
is that otherwise we loose the information about primops being
commutable, being (not) able to fail, and the "needs_wrapper" business.
Loosing these things may affect performance because the optimiser has
less information.
For the "foreign import prim" syntax we could provide this info via the
import string, like we do the dynamic/wrapper/& stuff with C imports.
eg:
foreign import prim "can_fail divModInteger"
:: Int# -> ByteArray#
-> Int# -> ByteArray#
-> (# Int#, ByteArray#, Int#, ByteArray# #)
but internally it means we probably have to have some type that unifies
genuine PrimOps with user-defined imported out-of-line cmm calls.
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.
As an intermediate step, we could just move the out-of-line primops out,
leaving the inline ones defined in primops.txt.pp. 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.
On the patches themselves:
- I think we should drop the requirement for "unsafe", it doesn't
have any meaning for primops
- why are arguments required to be unboxed?
Otherwise, looks fine.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
