I didn't see the message that started this thread, but I'll reply anyway...
Esa Ilari Vuokko wrote:
Monday, May 22, 2006, 12:35:21 AM, you wrote:
I am still puzzled by function arities, only thing I can see is that
IO-function seems to have arity one too big.
from GHC/IOBase.lhs:
newtype IO a = IO (State# RealWorld -> (# State# RealWorld, a #))
Yeah, that should explain it partly. For example putStrLn's
InfoTable says arity 2 Ok, expanded:
String -> (State# RealWorld) -> (# State# ReadWorld, () #)
But the function type is ARG_P. Which means one parameter in stack
(and it's a pointer). This might be due to RealWorld getting
optimised away, but it still makes function arity-field pretty
useless as far as I can see. Well, useless and pretty misleading :)
The arity field and the function type have different meanings. The
difference is subtle but very important.
A function of arity 2 must be applied to two arguments, even if one of
them is void (eg. State# RealWorld). A function of type (State#
RealWorld -> T) is very different from a value of type T: doing seq on
it is a nop, for example. The arity is used by the generic apply
machinery in the RTS (AutoApply.hc, generated by genapply).
The function type (I presume you mean field f.fun_type in
StgFunInfoTable, also called the "argument descriptor") is a value that
has two uses:
- it tells the RTS how to call the function; that is, which args
to put in which registers or stack slots, and
- it describes the layout of the stack when the function returns to
the RTS for some reason (eg. to garbage collect)
In our calling convention, void arguments are ignored: no code is
generated for passing a void argument, and no stack space is reserved.
So a function taking two arguments, one pointer and one void, has
exactly the same argument descriptor as a function that just takes a
single pointer argument.
For more info you could take a look at compiler/codeGen/CgCallConv.hs.
Hope this helps, let me know if there's anything else you need.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
