At 03:30 PM 1/16/01 +0000, David Mitchell wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote
> > Subject: Re: vtbl-based SVs and sv_setsv()
> >
> > At 06:42 PM 1/13/01 -0800, Benjamin Stuhl wrote:
> > >How is setting one SV from another going to be implemented?
> > >My (admittedly vague) recollection was that it would be
> > >something like
> > >
> > >void sv_setsv(SV* dest, SV* src)
> > >{
> > > dest->sv_vtbl->delete(dest); /* clear the old value */
> > > dest->sv_vtbl = src->sv_vtbl;
> > > dest->sv_vtbl->dupfrom(dest, src); /* and copy in the
> > >new */
> > >}
> > >
> > >That is, in $a = $b, $a would get a new vtbl, the one from
> > >$b. My question is how does this work with the need for
> > >assign-by-value, which is required for things like ties and
> > >overloads?
> >
> > The assignment will look like this in bytecode:
> >
> > sassign dest_scalar, source_scalar;
> >
> > and proably like this in C:
> >
> > dest_scalar->vtable[ASSIGN](source_scalar);
> >
> > or, more directly, the destination scalar is responsible for handling the
> > assignment. Passive scalars will generally toss their contents, reassign
> > their vtables, and copy the data, possibly after doing some type checking.
> > (If, for example, a variable was a locked type it wouldn't necessarily do
>this)
> >
> > The vtable method for active data will extract what it needs from the
> > source scalar and Do Magic with it.
>
>If the destination is passive but the src is complicated, then it might
>cause problems if the *dst* is responsible for copying the 'husk'
>of the src var. Eg the src may maintain pointers to some complex internal
>ref-counted structure which needs updating on copy.
>In which case I'd suggest that Benjamin's pseudocode
There's going to be a "clone" vtable function to handle this case, and
others like it.
> > > dest->sv_vtbl->delete(dest); /* clear the old value */
> > > dest->sv_vtbl = src->sv_vtbl;
> > > dest->sv_vtbl->dupfrom(dest, src); /* and copy in the
>
>
>is the correct implementation for ASSIGN method for a 'simple' scalar
>type, in that the dupfrom() method called is that actually associated with
>the src rather than dest.
More likely the assign functions would then call clone if it didn't
recognize the type of the source PMC.
>This makes me think of another thing - methods that return a new tmp SV
>(eg add): would it be better for them instead to be passed an SV to
>assign to?
>
>ie instead of
>
>SV *tmpsv = sv1->add(sv1,sv2); // using C rather C++ arg conventions
>
>we have
>
>tmpsv = new_tmp_sv();
>sv1->add(tmpsv,sv1,sv2);
>
>If we are going for a register-based system (ie an array of tmp SVs
>for use by the compiler/optimiser), then this could cut down on unnecessary
>tmp SV creation, copying and destruction.
Yup. This is exactly what I'm thinking of, as well as tossing many of the
return values from the original draft of the vtable spec. (One fewer thing
to pass makes things that much less slow)
>This is analagous to a generic 3-address CPU architecure with an
>add instruction like add "r1,r2,r3".
>
>The code $a = $b + $c * $d would then appear in bytecode as
>
>mult c, d, r1 # r1 is a "register" SV that the compiler has determined
>is free
>add b, r1, r2 # ditto r2
>sassign r2, a
>
>Note that in this scheme, a method has to assume that it's destination
>arg is 'simple' and can have any existing contents blown away -
>or possibly even that it is the callers' responsiblity to have already
>blown away any previous contents.
Temp PMCs will be nukable regardless, though we may call the "trash" vtable
method for things the optimizer's not sure of.
>Becuase of this, was can't optimise
>
>add b, r1, r2
>sassign r2, a
>
>into
>
>add b, r1, a
>
>unless we know at compile time that $a is a 'simple' scalar.
Well, I think we can do that in many cases, though the potentially huge
amount of active data perl can have makes things interesting. :(
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
