Is PMC size fixed?

[Mattia Barbon]

Hello,
currently, new_pmc only allows creating PMC of fixed size;
i'd like to be able to create PMCs with additional data members, for example:

struct my_PMC
{
PMC pmc;
int my_data;
double other_data;
...
};

I know I can use "data" to attach arbitrary data to the PMC, but I'd like
to avoid casting this pointer at every access, either explicitly or via
a macro (mainly for code clarity).
Is this limitation a design decision, or is just that this feature hasn't
been implemented (yet)?

Thanks
Mattia

[Matt Fowles]

Mattia~

I am certain that people will correct me if I am wrong here, but I think
that PMC size must be fixed so that the PMC stacks can do save and
restore commands to all 32 PMC registers in one memory copy. I am sure
there are other cases where fixed size PMC's allow simplifying
assumptions that can be used for optimizations...

Matt

[Stéphane Payrard]

Different buffer "classes" derived from PMC make sense and may later
beused to implement objects with attributes. Currently you are
obliged to create a buffer "derived from" struct Buffer that you will
make the data accessed by SELF->data. This seems an unneeded
indirection when you know that the data will always be there.

I am not yet familiar enough with the code to say if there is
something special about PMC that precludes this feature implementation.

>
> Thanks
> Mattia
>
>
>

[Dan Sugalski]

At 9:29 PM +0200 4/15/03, Mattia Barbon wrote:
> Hello,
>currently, new_pmc only allows creating PMC of fixed size;

> Is this limitation a design decision, or is just that this feature hasn't
>been implemented (yet)?

It's a design decision. PMCs all come out of arenas, so they need to
be the same size. I considered extensibility, but it means multiple
arenas, one for each size, which'd complicate and slow down the
garbage collector.

We'd planned at one point to parcel out Buffer structs of various
sizes since we never walk the buffer arenas, but I'm not sure if that
got implemented, or if the PMC/Buffer unification made that untenable.
--
Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk

[Dan Sugalski]

At 3:47 PM -0400 4/15/03, Matt Fowles wrote:
>Mattia~
>
>I am certain that people will correct me if I am wrong here, but I
>think that PMC size must be fixed so that the PMC stacks can do save
>and restore commands to all 32 PMC registers in one memory copy. I
>am sure there are other cases where fixed size PMC's allow
>simplifying assumptions that can be used for optimizations...

Registers aren't an issue in this case--PMC and String registers hold
pointers, rather than the structs themselves, so they're always
sizeof(void *).

[Steve Fink]

On Apr-15, Dan Sugalski wrote:
> At 9:29 PM +0200 4/15/03, Mattia Barbon wrote:
> > Hello,
> >currently, new_pmc only allows creating PMC of fixed size;
>
>
> > Is this limitation a design decision, or is just that this feature hasn't
> >been implemented (yet)?
>
> It's a design decision. PMCs all come out of arenas, so they need to
> be the same size. I considered extensibility, but it means multiple
> arenas, one for each size, which'd complicate and slow down the
> garbage collector.
>
> We'd planned at one point to parcel out Buffer structs of various
> sizes since we never walk the buffer arenas, but I'm not sure if that
> got implemented, or if the PMC/Buffer unification made that untenable.

Yes, you can create different-sized Buffer "subclasses". See
include/parrot/hash.h for an example (the struct _hash type). It is
allocated through the new_bufferlike_header() call, which takes a size
argument.