[INFO] Buffer/PMC unification

0 views
Skip to first unread message

Leopold Toetsch

unread,
Dec 9, 2002, 9:27:59 AM12/9/02
to P6I
I will start $subject soon. This will generate a lot of changes in CVS.
The basic common structure will be a Parrot Object or PObj for short.

To get there, the first step will be hiding affected structure members
inside some accessor macros and unification of PMC/Buffer flags.

(When this is done, changing below structures to our needs should be
really simple)

The involved structures will be something like this finally:

typedef union UnionVal {
struct { /* for 32 bit ints, 64 bit double */
Parrot_Int int_val[2]; /* the 2nd int_val might be useful for */
} i; /* e.g. {nom/denom} floats */
Parrot_Float num_val; /* PMCs UnionVal members */
Parrot_Pointer struct_val;
struct STRING* string_val;
struct PMC* pmc_val;
struct { /* Buffers structure */
void * bufstart;
size_t buflen;
} b;
} UnionVal;

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

/* plain Buffer is the smallest Parrot Obj */
typedef struct Buffer {
PObj o;
} Buffer;

/* a scalar PMC is a Parrot Object with a VTABLE */
typedef struct PMC {
PObj o;
nVTABLE *vtable;
} PMC;

For the full story please read (again) these threads starting with
Subjects:
- [RFC] Buffer/PMC unification, variable/value vtable split, tied scalars
- Of PMCs Buffers and memory management

leo

Leopold Toetsch

unread,
Dec 10, 2002, 5:29:23 AM12/10/02
to P6I
Leopold Toetsch wrote:

> I will start $subject soon. This will generate a lot of changes in CVS.


The first of a bunch of patches is in.
(If you want to shorten rebuild times, please install ccache - great tool)

- BUFER_*_FLAGs have moved to the new include/parrot/pobj.h
- string.c is done

All direct access to buffer->flags or pmc->flags is deprecated, when all
is done. Accessor macros in pobj.h should be used instead:

e.g.
PObj_external_TEST(o), PObj_external_SET(o), PObj_external_CLEAR(o)
for testing, setting and clearing the flag "external" for a PObj "o".

For commonly used combinations of flags there are special macros like:
PObj_is_cowed_TESTALL(o).

The flags themself can be accessed by: PObj_get_FLAGS(o).

leo

Leopold Toetsch

unread,
Dec 10, 2002, 7:33:38 AM12/10/02
to P6I
Leopold Toetsch wrote:

> I will start $subject soon.


Next piece. BUFFER_*_FLAGs and PMC_*_FLAGs are now united, same things
have the same value.

Please do a "make clean" after check out due to lacking dependencies in
classes.

BTW what are the BUFFER_needs_GC_FLAG / PMC_private_GC_FLAG. Are these a
synonym for active_destroy_FLAG?

leo

Leopold Toetsch

unread,
Dec 10, 2002, 8:43:02 AM12/10/02
to P6I
Next one. #3.


The ugly, everywhere warning producing, static buffer_lives() went to
dod.c where it belongs to.

leo


Leopold Toetsch

unread,
Dec 10, 2002, 11:39:46 AM12/10/02
to Leopold Toetsch, P6I
Changes #4 and #5 are in.

This completes the changes on BUFFER_*_FLAGs.

leo

Leopold Toetsch

unread,
Dec 11, 2002, 7:12:16 AM12/11/02
to P6I
Changes #6.

- PMC_*_FLAGs are history.
- I did remove the bogus looking, unused, untested and superfluous
<destroy> from core.ops

All access to PMC/Buffer->flags has to be done via the accessor macros
in pobj.h. If some are missing, please add them, when needed.

Next will be hiding other Buffer/PMC structure members that might
conflict, like buffer and buflen.

leo

Leopold Toetsch

unread,
Dec 11, 2002, 9:45:48 AM12/11/02
to P6I
Done.

Buffers and PMCs are Parrot Objects now, sharing a common header, PObj.

The struct members:
- buffer
- buflen
- cache
- version (for GC_DEBUG)
are actually #defines now. This implies that the usage of these names is
forbidden in the whole parrot tree.

This rule will last until the final structures are fixed, and somone
changes all usage of above data members to the real thing.

Finally I was to lazy to change all ->flags in keys.c and list.c, a
macro in these files is used to access flags directly.

make quickfulltest doesn't show any error, nor do perl6 tests.

After the feature freeze/release, we can have a look at DOD/GC &
Buffer/PMC memory management functions to look, what can be simplified then.

Please do a "make clean" after checkout.

Have fun,
leo

Dan Sugalski

unread,
Dec 12, 2002, 11:10:09 AM12/12/02
to Leopold Toetsch, P6I
At 1:12 PM +0100 12/11/02, Leopold Toetsch wrote:
>Changes #6.
>
>- PMC_*_FLAGs are history.
>- I did remove the bogus looking, unused, untested and superfluous
><destroy> from core.ops

It's not actually superfluous. If for some reason someone wants to
write part of the GC cleanup sweep in pasm, they'll need it. It's
also needed when code needs to explicitly kill a PMC.
--
Dan

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

Leopold Toetsch

unread,
Dec 12, 2002, 11:26:51 AM12/12/02
to Dan Sugalski, P6I
Dan Sugalski wrote:

> At 1:12 PM +0100 12/11/02, Leopold Toetsch wrote:
>
>> Changes #6.
>>
>> - PMC_*_FLAGs are history.
>> - I did remove the bogus looking, unused, untested and superfluous
>> <destroy> from core.ops
>
>
> It's not actually superfluous. If for some reason someone wants to write
> part of the GC cleanup sweep in pasm, they'll need it. It's also needed
> when code needs to explicitly kill a PMC.

Just don't reference the PMC and it will go away. I can't imagine the
"some reason" it will be dead slow.

And, actively destroying something is dangerous.

When there is a real need for it, ok - then add it again.

leo


Reply all
Reply to author
Forward
0 new messages