Andy Dougherty wrote:
I had two questions:
1. Is the order of elements in struct PMC deliberate?
Nope, just the order I copied them in when collapsing the struct.
struct PMC {
Parrot_UInt flags;
UnionVal cache;
VTABLE *vtable;
DPOINTER *data;
struct PMC_EXT *pmc_ext;
};
In particular, on 32-bit SPARC, sizeof(flag) will be 4, but cache will
have to be aligned on an 8-byte boundary. Thus there will be 4 "wasted"
bytes of padding. Swapping the order (putting cache first and flags
second) will reduce the size of a pmc by 4 bytes. Not crucial, but
nice.
Not crucial either way, so reversed for now.
2. Did you deliberately drop _int_val2 from UnionVal?
Specifically, the former
struct _i {
INTVAL _int_val;
INTVAL _int_val2;
} _i;
has been replaced by a single _int_val entry. However, since the
UnionVal already contains 2 pointers, keeping the second _int_val2 only
costs space on systems where sizeof(INTVAL) > sizeof(void *). Are such
platforms a significant concern?
In the final incarnation of the PDD, the UnionVal struct should be
unchanged from what's in include/parrot/pobj.h. The change must have
slipped through from one of the alternate universes before the final
version.
Allison
