| Sigbjorn gave me this suggestion, which is based on DataToTagOp.
|
| \begin{code}
| primCode [res] IsHNF [arg]
| = let res' = amodeToStix res
| arg' = amodeToStix arg
| arg_info = StInd PtrRep arg'
| word_32 = StInd WordRep (StIndex PtrRep
| arg_info (StInt (-1)))
| masked_le32 = StPrim SrlOp [word_32, StInt 16]
| masked_be32 = StPrim AndOp [word_32, StInt 65535]
| #ifdef WORDS_BIGENDIAN
| ty_info = masked_le32
| #else
| ty_info = masked_be32
| #endif
| not_a_thunk = StPrim IntEqOp [ StPrim AndOp [ty_info,
StInt 0x10]
| , StInt 0x0
| ]
| -- ToDo: don't hardwire the value of
| _THUNK from InfoTables.h
| assign = StAssign IntRep res' not_a_thunk
| in
| returnUs (\ xs -> assign : xs)
| \end{code}
|
|
| I get different results with the version using the C macro
| and the native code version. In particular I get the wrong
| (unexpected result from the native code version).
|
| The C macro version works like this (uses these macros):
|
| #define closureFlags(c) (closure_flags[get_itbl(c)->type])
| -- in ghc/includes/InfoTables.h
|
| #define closure_THUNK(c) ( closureFlags(c) & _THU)
| -- in ghc/includes/InfoTables.h
|
| #define get_itbl(c) (INFO_PTR_TO_STRUCT((c)->header.info))
| -- in ghc/includes/ClosureMacros.h
|
| #define INFO_PTR_TO_STRUCT(info) ((StgInfoTable *)(info) - 1)
| -- in ghc/includes/ClosureMacros.
|
| The (-1) scares me a little bit, in INFO_PTR_TO_STRUCT.
|
| The array closure_flags[] is just a look up table, indexed by
| the closure type. So the key part of the code above is:
|
| get_itbl(c)->type
|
| In the native code version above, the lines below act like
| get_itbl(c):
|
| arg_info = StInd PtrRep arg'
| word_32 = StInd WordRep (StIndex PtrRep arg_info (StInt (-1)))
|
| After this I am lost. It seems to be grabbing the top or
| bottom 16 bits of word_32 (depending on endianness) and then
| ANDing those bits with 0x10 (which is the bit mask for _THU),
| and checking for 0.
|
| My feeling is that I should be finding out the "type" field
| from the closure and then switching on its value.
What you have started with looks plausible. If you can extract
enough info from the NCG, you can usually find the problem
without too much difficulty.
I suggest you make friends with -ddump-stix, so that you can
see directly the result of your extension to the primCode fn
above.
Then (if you are mad enough) the usual way to go about this is:
1. Write a plausible primCode case -- as you've already done.
2. Compile with -ddump-stix and see if it looks plausible
in context.
3. Read the assembly code (-ddump-asm) and relate it to the
Stix.
4. Try and relate (3) to the assembly code for the same
when compiled with -fvia-C. This usually helps.
(3) and (4) are a lot easier if you do it on x86 than sparc
because x86 code is a lot less verbose. You do need to be
clear about x86 addressing modes, tho.
| I don't understand the native code generator well enough. I
| am assuming that closures are laid out the same way as via-C,
Yes. Code from the NCG and -fvia-C is 100% interoperable.
| in particular that there is going to be some stuff in the
| info table before the "type" field (this looks variable
| depending on how things are built). Basically I'm looking for
| a way to do the equivalent of "->type". Maybe there is a
| better way to do it.
Suggestion: find some other primop which uses the ->type field
and which is implemented in the NCG (not all are). That might
help.
Finally let me point you at ghc/utils/debugNCG, a small but
very useful program for debugging the NCG. I would never have
got it working as well as it does without it. This should
work -- but it might have slight bitrot -- it's very fragile
and makes lots of assumptions about gcc's output. I haven't
used it for a good few months.
J
_______________________________________________
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
