Nicholas Clark <[EMAIL PROTECTED]> wrote:
> Parrot gives each PMC class 8 private flag bits. I was wondering how to use
> these most efficiently for ponie. My thoughts so far are
> 1 bit for SVf_IOK
> 1 bit for SVf_NOK
> 1 bit for SVf_POK
> 1 bit for SVf_ROK
I'd not mess around with (or introduce) flag bits. The more that this
would only cover perl5 PMCs. Presuming that the Perl5 PMCs are subtypes
of Parrot core PMCs, I'd do ...
// init
STRING* Integer_string = const_string(interpreter, "Integer");
STRING* scalar_string = const_string(interpreter, "scalar");
...
i_ok = VTABLE_isa(interp, pmc, Integer_string);
scalarish_ok = VTABLE_does(interp, pmc, scalar_string);
...
... *if* you really want to know what the PMC is. Usually you just call
the vtable (or MMD) on the PMC and, if it can do the operation, it will
do it.
The vtable functions C<isa> and C<does>, which take now a string, are a
bit heavy-weighted and might get an extension in the log run that take
an integer flag. Keeping these functions in one place will not harm.
> The PMC has a union that can store an integer or a floating point value or
> a reference (or a string - now sure whether to store a parrot string or a
> char * for SvPVX)
This is the currently layout. As mentioned several times, I'd rather
like to have more specialized, *variable-sized* PMCs. E.g.
+--------------+ +--------------+
| VTABLE *vt | | VTABLE *vt |
+--------------+ +--------------+
| void *data |---+ | void *data |--->+--------------+
+--------------+ | +--------------+ | FLOATVAL |
| INTVAL int_v | <-+ | | | num_val |
+--------------+ +--------------+ | |
+--------------+
Integer Integer upgraded to a Float
Another (half cooked) idea is to have and additional indirection on PMC
access and just resize or move the PMC memory.
> 2 bits to say what we're storing in the union
The vtable is that information:
INTVAL i = VTABLE_get_integer(interpreter, pmc);
FLOATVAL n = VTABLE_get_number(interpreter, pmc);
and
VTABLE_set_integer_native(interpreter, pmc, i);
VTABLE_set_number_native(interpreter, pmc, n);
just do the right thing. Usually there is no need to query the PMC what
it is.
> Nicholas Clark
leo
