Daniel Peebles wrote: > On Tue, Jan 25, 2011 at 5:22 PM, Roman Leshchinskiy >> >> Hmm, come to think of it, could they perhaps be written in Cmm (calling >> memcpy etc. internally) and imported using the (rather obscure) "prim" >> calling convention? >> >> >> http://www.haskell.org/ghc/docs/7.0-latest/html/users_guide/ffi.html#ff >> i-prim >> >> They wouldn't have to be true primops then, i.e., they wouldn't require >> extensions to the compiler itself. I don't know if this is feasible, >> though. > > > I considered that actually, but they seemed of general-enough interest > that I think it'd make sense for them to be primops.
I agree that they are of general interest but that isn't necessarily the right criterion for determining if something should be a primop. As long as it's provided, nobody will care how it's implemented except for the implementers themselves. > Duncan Coutts has > mentioned that foreign import prim wasn't really meant for average library > code. What we are talking about is definitely not average library code! Anyway, I don't really care either way, I just thought that the prim FFI route would be simpler and require less maintenance in the future. > There's also talk of switching the Primops.cmm imports from the .pp file > to an actual set of foreign import prim declarations, which would allow > real haddock! Not sure what to do about the inline primops though! That's easy, GHC should be able to inline Cmm code :-) Roman _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
