At 10:58 AM 8/5/00 +0000, Nick Ing-Simmons wrote:
>Ken Fox <[EMAIL PROTECTED]> writes:
> >For foreign objects, I'm not sure why you're forcing a two level
> >dispatch. Why not let the foreign code register dispatches directly
> >in the scalar's vtbl? If we did it that way, a foreign object
> >is just:
> >
> >[SV *] --> [type_code, flags, pointer]
> >
> >The type_code defines the vtbl to use when calling an op on
> >the object. Calling an op is just calling vtbl[type_code].the_op(SV *).
>
>I am tempted to turn that round - have the vtable pointer in the SV *,
>and the type code (if we need it) in the vtable - that saves a deref on
>dispatch - where we need speed - and still allows type code access for
>meta ops.
>
>typedef struct p6vtable {
> unsigned tFlags : 28; // flags for "class"
> unsigned type : 4; // "type code"
> int (*init)(SV *); // constructor
> int (*cleanup)(SV *); // destructor
> IV (*SvIV)(SV *);
> NV (*SvNV)(SV *);
> ...
>} p6vtable;
Too much work for type. The vtable is probably type-specific for most
things, so the type routine could do a simple:
PL_type_t type(PMC) {
return PERL_IS_REFERENCE;
}
or something similar. When a SV changes type it gets a new vtable pointer,
which can also have the type data embedded in it. This way we don't waste
any bits encoding type for most variables, and those variables that *do*
need to have type embedded in them can stick it in the data structure
hanging off the sv_any pointer.
>I think we could allow slot for double in the base class, which
>on many platforms would allow an IV and a void * as well.
Might as well union an NV, IV, and void * together and be done with it. The
vtable will know how to do the right thing.
>One can imagine a "small PV" which splits sv->data.words.iv into two shorts
>for SvCUR and offset. (SvLEN can off course live at the other end of ptr -
>after all if we re-malloc we need to go mess there anyway.)
>I think perl5 may have squeezed the base class a little too small.
Many of the svs might not ever have a PV part. (or IV, or NV, or whatever)
There's no reason that a scalar declared as:
my $foo :integer;
can't just do the int->string conversion each time. If it doesn't happen
often it's not a loss.
>So accessors become things like (inline just to avoid #define for now) :
>
>inline IV
>SvIV(SV *sv)
>{
> return (*sv->vtable.SvIV)(sv);
>}
>
>With the simplest case being
>
>IV
>nativeIV(SV *sv)
>{
> return sv->data.words.iv;
>}
Exactly what I was thinking. Not a huge win with individual scalars, but
for arrays and hashes.... Much bigger win.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
