adding isWHNF primop to 5.00.2 native code generator

[Julian Seward (Intl Vendor)]

| In all the cases I tried, the info pointer in the closure=20
| header pointed to the end of the info table. Although a=20
| comment in ghc/includes/ClosureMacros.h worries me:
|=20
|        "info pointer"    The first word of the closure.  Might point
|                          to either the end or the beginning of the
|                          info table, depending on whether we're using
|                          the mini interpretter or not.  GET_INFO(c)
|                          retrieves the info pointer of a closure.
|=20
| Can someone please clarify when the info pointer will point=20
| to the beginning or end of the table?

Normally, the info pointer points at the first word following
the info table.  This word is the start of the closure's entry
code.  That means that, given an info pointer, we can either
evaluate the closure by executing from that address, or look up
info about it by indexing backward from it into the info table
proper.

However, for portable (-unreg) compilation, we can't control the
relative placement of code and data.  In this case the first word
of the itbl points to the entry code.=20

For nativeGen hacking you only need to consider the fast (pointer
to end) case.

| My problem is that this is a dodgy assumption since the design of the=20
| info table may change in the future, and you get a nasty=20
| unchecked dependency between the primops in the NCG and the=20
| design of the rts.=20

This is a major design problem (IMO) with the NCG.  It afflicts=20
every single macro and structure layout which the NCG has to deal
with, and has already cost us some hours tracing bugs to do with
divergences between the two implementations.  I had a plan to=20
derive all the structure layouts and macro defs from a single source
to avoid this kind of breakage, but I don't know if it will ever
be implemented.

| It seems hard to get the kind of automatic offset calculation in the=20
| NCG as you get with the C version of primops. My current idea=20
| is to make some C primops that do the structure and array=20
| indexing for me, and then use them in the NCG. i.e. primops=20
| that essentially export 'closure_flags[type]' and=20
| 'get_itbl(c)->type' to the NCG.

It's a problem.

StIndex is sometimes helpful, particularly since you can specify
a PrimRep which indicates how the index should be scaled.  Exactly
like adding an integer to a pointer in C.

J