"Michel J Lambert" <[EMAIL PROTECTED]> wrote:
>This depends upon how variables and the registers interact. If, like a
>real CPU, registers must be stored back into traditional memory as
>variables, then there is no problem.
<snip example pasm code>
>If instead, registers are aliased onto traditional memory variables, such
>that a PMC pointed to by a register is *also* pointed to by a stash
>somewhere, then it's a bit harder.
The issue here is whether PerlRef PMCs will reference a PMC or a symbol
table/stash entry. I was assuming the former, in which case we have
something like:
#$foo = "abc";
new P0, PerlString
set P0, "abc"
stash_store P0, "foo"
#$bar = \$foo;
new P1, PerlRef
stash_load P0, "foo" #Not needed if P0 unchanged
set P1, P0 #Make P1 reference P0 (not 'foo')
stash_store P1, "bar"
#print $$bar
deref P2, P1 #put the PMC pointed to by P1, into P2
print P2
#$foo = 3;
set P0, 3
# no stash_store here because we have not created a new variable
#print $$bar
deref P2, P1
print P2
and we are relying on the address of P0 to remain constant.
> STRING* s = string_copy(INTERP, (STRING*)SELF->cache.struct_val);
> dest->cache.struct_val =
> string_concat(INTERP,
> s,
> value->vtable->get_string(INTERP, value),
> 0
> );
> /* don't destroy s, as it is dest->cache.struct_val */
>
> What's the point of making a copy of that string? I don't really know,
> and I don't see the point. The comment at the end doesn't help any, either
>
This code seems to be related to differences between documentation and
implementation.
Quote from docs/strings.pod:
---------
To concatenate two strings - that is, to add the contents of string
C<b> to the end of string C<a>, use:
STRING* string_concat(STRING* a, STRING *b, INTVAL flag)
C<a> is updated, and is also returned as a convenience.
--------
The current implementation of string_concat always creates a new string;
both a & b are unchanged.
The code snippet you give seems to believe the documentation.
Perhaps we need both two-argument and three-argument versions; this could be
implemented as a three-argument function which detects 'out == in1' and acts
accordingly.
Note that string_repeat and string_substr are documented in the same place
as only creating a new string if the final parameter is NULL; the
implementations again differ.
I agree that the whole issue of garbage collection relating to newborns and
temporaries is problematic. One option might be to always flag newly-created
objects in some way, then have a single function call to release them; at
least this means just one function call at the end of each procedure. This
still leaves a problem with nested procedures.
--
Peter Gibbs
EmKel Systems
