| In all the cases I tried, the info pointer in the closure | header pointed to the end of the info table. Although a | comment in ghc/includes/ClosureMacros.h worries me: | | "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. | | Can someone please clarify when the info pointer will point | 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. 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 | info table may change in the future, and you get a nasty | unchecked dependency between the primops in the NCG and the | design of the rts. This is a major design problem (IMO) with the NCG. It afflicts 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 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 | NCG as you get with the C version of primops. My current idea | is to make some C primops that do the structure and array | indexing for me, and then use them in the NCG. i.e. primops | that essentially export 'closure_flags[type]' and | '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