On Monday 28 April 2008 10:24:37 Andy Dougherty wrote:

> On Sun, 27 Apr 2008, chromatic wrote:

> >  /* Parrot Object - base class for all others */
> >  typedef struct pobj_t {
> > +    Parrot_UInt flags;
> >      UnionVal u;
> > -    Parrot_UInt flags;
> >  } pobj_t;

> On 32-bit SPARC, at least, that's going to introduce a wasted 4 bytes of
> padding.  (UnionVal will be aligned on an 8-byte boundary, but
> Parrot_Uint is only 4 bytes long.)  This is, of course, not an error in
> and of itself, but if any of those "dodgy" casts assume no padding, then
> there will be an error.

I don't believe they rely on padding, but that's why I ask.

Does 32-bit SPARC align all pointers on 8-byte boundaries?

My ultimate goal is to get pobj_t down to:

        typedef struct pobj_t {
                Parrot_UInt flags;
                void *GC_next;
        } pobj_t;

... where GC_next is a pointer to the next pobj_t in a linked list.  This'll 
let us get rid of all of the dodgy casts required to maintain arena free 
lists as well as to remove the UnionVal member from GCable structures that 
don't need it, saving two pointers from every Stack_Chunk_t, for example.

> I'll try building, but since there are 4 permutations to try (cc and gcc,
> and with and without this patch) and since each build takes 1 to 2 hours
> if everything goes well, it won't be until tomorrow at the earliest that
> I can report anything back.  (Longer, if manual intervention is required
> to fix unrelated errors.)

Much appreciated.

-- c

Reply via email to