set_string_native
Leopold Toetsch
PMC_str_val(SELF) = value;
instead (perlstring.pmc:193). This breaks exactly one test which
explicitely tests this behavior nothing else.
And there is of course the assign opcode, that does the same. But we
could have:
set P0, "xx" # ref
assign P0, "xx" # copy
This would need another vtable though,
Comments welcome,
leo
Dan Sugalski
>This vtable currently copies the string.
Yeah, and we've the same issue with set_pmc -- some of the versions
make a copy and some just use the passed in PMC. (the
get_[string|pmc] vtable methods have a similar issue--should they
return the real thing or a copy?)
I'm up for a set and assign string & pmc vtable method, as well as a
get and access (to get a copy and a direct reference, respectively)
string and pmc method, though there's always the caveat that some
PMCs won't be able to actually do this and will have to make a copy
anyway.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Leopold Toetsch
> At 5:35 PM +0200 4/16/04, Leopold Toetsch wrote:
>>This vtable currently copies the string.
> Yeah, and we've the same issue with set_pmc -- some of the versions
> make a copy and some just use the passed in PMC. (the
> get_[string|pmc] vtable methods have a similar issue--should they
> return the real thing or a copy?)
assign Px, Sy $1->vtable->assign_string_native # copy string
set Px, Sy $1->vtable->set_string_native # refer to string
assign Px, Py $1->vtable->assign_pmc
set Px, Py $1->vtable->set_pmc
I'm not sure if we need the two different get vtable methods though. At
least there isn't any usage for these ;)
What about keyed variants of assign for strings and PMCs?
OTOH
assign Px, Iy
assign Px, Ny
could be aliased in the assembler to their C<set> variants, so that we
can toss these opcodes.
leo
Dan Sugalski
>Dan Sugalski <d...@sidhe.org> wrote:
>> At 5:35 PM +0200 4/16/04, Leopold Toetsch wrote:
>>>This vtable currently copies the string.
>
>> Yeah, and we've the same issue with set_pmc -- some of the versions
>> make a copy and some just use the passed in PMC. (the
>> get_[string|pmc] vtable methods have a similar issue--should they
>> return the real thing or a copy?)
>
> assign Px, Sy $1->vtable->assign_string_native # copy string
> set Px, Sy $1->vtable->set_string_native # refer to string
>
> assign Px, Py $1->vtable->assign_pmc
> set Px, Py $1->vtable->set_pmc
>
>I'm not sure if we need the two different get vtable methods though. At
>least there isn't any usage for these ;)
Well, think of aggregates (where it's most likely to be used) where
you'd want to either get a copy of an element (because you don't want
to modify what was in the aggregate) or the actual element itself
(because you do, and don't want to re-store the value in the
aggregate. That's where I can see this being really useful.
Leopold Toetsch
> At 6:04 PM +0200 4/19/04, Leopold Toetsch wrote:
>>
>>I'm not sure if we need the two different get vtable methods though. At
>>least there isn't any usage for these ;)
> Well, think of aggregates (where it's most likely to be used)
That was the next question, you'd snipped away :)
set Sx, Py
assign Sx, Py
don't access aggregates.
The assign forms
set Sx, Py[Iz] # implemented
assign Sx, Py[Iz] # needed?
new Sx, Py[Iz] # or even
new Px, Py[Iz] # these 2?
and the PMC variants (and different _keyed variants) are missing.
All the assigned get can be done (or should at least) with an additional
instruction, which could be a shallow clone. The set vs assign "set"
instruction can't be emulated. I'm still in favour of keeping the opcode
count as small as needed. Parrot's opcode dispatch is fast enough to
deal with that. Cache misses due to huge opfiles are issues, which
can't be delt with. The same idea holds for vtable size.
leo