On Oct 23, 2006, at 7:17 AM, Simon Marlow wrote:
I don't expect PAR to work in any branch of GHC, except in sources
you get directly from the GPH folk. The PAR code in released
versions of GHC isn't tested, certainly doesn't work, and probably
doesn't compile either.
Do you still do development work on GranSim?
I haven't used ZLA's before, so that was partly my misconception
and partly an underlying disagreement I have with flexible array
members in general. I always thought of flexible array member as
a pointer; I now understand that structures containing a ZLA-
flexible array member are treated as if the ZLA-member does not
exist, especially for sizeof(), but their incomplete type must
reserve space (sizeof (void), which is also an incomplete type, is
1).
I don't understand that last comment. Why should the incomplete
type have a size that is 1 byte larger than a normal sizeof()?
My mistake, sorry. From the portion of the C99 standard I quoted on
flexible array members--I have been calling them ZLA's because that
is what the gcc manual calls them--it seemed to imply that there may
be additional padding for a ZLA in a particular implementation:
"...except that it may have more trailing padding than the omission
would imply." (Section 6.7.2.1, Paragraph 16.)
My mistake came when I tried to equate (implementation dependent
flexible array) padding to the type (void): the size of void is not
defined in the standard (it is an incomplete type that cannot be
completed, so by definition it has no size). A pointer to void, of
course, has the same representation and alignment requirements as a
pointer to char (see Section 6.2.5, Paragraphs 19 and 26) so the fact
that sizeof(void) works and returns the same value as sizeof(char)
may be a quirk of gcc.
The actual implementation does include the offset to the flexible
array member, so sizeof() should account for that.
Do you mean that the size of the type should include any padding
required before the flexible array, but no size for the array
itself? (that I agree with).
Definitely.
All of the closure structures are carefully written to be a
multiple of StgWord in size, and are always aligned to an StgWord
boundary (no more, no less), because that is how the heap/stack
works in GHC. Info tables are also a multiple of StgWord, but
there it is less clear: we might like the code to be more aligned
than StgWord, but to do that we would probably have to pad *before*
the info table.
You might like to take a look at
http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage
in particular the sections on heap layout and slop.
<snip>
Right. This isn't an issue for us (no padding is ever required).
This is very interesting stuff. I took some time to look carefully
at the resulting layout through MkDerivedConstants and
DerivedConstants.h (on a completed build), as well as some of the
assembler output for the C and Haskell code. The system is very
compact: I could not find any padding at all and I learned a bit at
the same time :) There is also no padding for flexible array members.
Cheers,
Pete
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
