initial "foreign import prim" patches for review
ryani.spam at gmail.com
Tue Jun 9 14:52:48 EDT 2009
I'm really interested in this; keep your blog updated! :)
Not particularly because I care about GMP, but because as a commercial
games programmer I'm excited about being able to "write to the metal"
and this looks like it'll be another entrance to doing that. From my
point of view, the ideal RTS is no RTS at all, although realistically
a couple of services will still be "wired-in".
On Tue, Jun 9, 2009 at 11:13 AM, Duncan Coutts<duncan at well-typed.com> 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
> 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.
> 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.
> Cvs-ghc mailing list
> Cvs-ghc at haskell.org
More information about the Cvs-ghc