On Mon, 28 Apr 2008, chromatic wrote:
> 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.
And wisely so! I sometimes (ok, often) find it a bit hard to tell what
the underlying assumptions are.
> Does 32-bit SPARC align all pointers on 8-byte boundaries?
No. It's the double inside the UnionVal cache that forces the 8-byte
alignment.
>
> My ultimate goal is to get pobj_t down to:
>
> typedef struct pobj_t {
> Parrot_UInt flags;
> void *GC_next;
> } pobj_t;
That should not require any padding. So my objection about wasting space
can be ignored, since it would only be a temporary issue that would
ultimately go away.
> ... 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.
Sounds like a worthy goal. A cache is a nice-sounding idea, but perhaps
not quite at this lowest level.
--
Andy Dougherty [EMAIL PROTECTED]
