[m-dev.] for review: layouts without static code addresses

[Zoltan Somogyi]

Fergus, I made the changes you requested; the result is bootchecking now.

> > ... The cast in the body of MR_INIT_PROC_LAYOUT_ADDR
> > +** is needed because compiler-generated layout structures have their own
> > +** compiler-generated type.)
> 
> BTW, why do they have their own compiler-generated type?

Partly because of history. The compiler has never had the infrastructure
for creating structures of an existing type, and Tyson used the existing
infrastructure rather than adding to it when he added layout structures.
In fact, we had layout structures for a while before I created the C struct
definition for accessing them from C code; Tyson's original code referred
to the various fields via offsets specified through C #defines.

The other partial reason is that how much of the layout structure the compiler
generates depends on the options. With some options, we use only the first
four fields (plus one as a sentinel saying the other fields are not present),
the first ten fields (plus a sentinel), or all twelve (soon to be thirteen).
To prevent reserving space which is not used, the compiler would have to define
each layout structure as being the appropriate one of three different although
closely related C struct definitions. And since much of the runtime system
wants to deal with all proc layouts uniformly, that solution would not get
rid of the requirement for casts.

One can think up more type-safe solutions than the existing approach, but as
far as I can see, they involve significant extra complexity and significant
changes to existing code. Although I also prefer type safety, which is why
I moved the implementation of layout structures in that direction so far,
I don't believe that further moves in that direction would be worth the effort
given our scarce resources.

One change I do intend to make after the release, though, is to use
different naming schemes for proc layouts and internal layouts. At the moment,
it is too easy to mistake one for the other.

Zoltan.