At 11:13 AM 2/7/2001 +0100, Edwin Steiner wrote:
>Dan Sugalski wrote:
>[snip]
> > That's OK, since my example was wrong. (D'oh! Chalk it up to remnants of
> > the martian death flu, along with too much blood in my caffeine stream) The
> > example
> >
> > $foo{bar} = $baz + $xyzzy[42];
> >
> > turns into
> >
> > baz->vtable->add[NATIVE](foo, baz, xyzzy, key);
>
>Why does the bytecode compiler know it should generate NATIVE int addition?
>Are you assuming 'use integer'? (see also next comment)
It's in there for clarity. It's likely either been cached somewhere, or
comes from a call to the type vtable entry for the second parameter.
> > with the add routine doing
> >
> > IV lside = baz->vtable->get_int[NATIVE](baz, key+1);
> > IV rside = xyzzy->vtable->get_int[NATIVE](xyzzy, key+2);
>
>This code assumes $xyzzy[42] will fit in an IV. It could
>be bigint, bigfloat, ... and already create an overflow when
>*converted* to IV, not only when added to lside.
>
>I know this is so because it's the add[NATIVE] implementation, right(?).
Right.
>But why does the bytecode compiler (or any other code from parsing
>to execution) know that NATIVE will be appropriate?
>Where does this assumption about both $baz and $xyzzy[42] come from?
Well, we know about baz because it's baz's vtable being used. We know about
$xyzzy[42] because we asked it and left that out for clarity. (Or because
we wanted to treat it explicitly as a native integer type)
> > IV sum;
> > bigstr *bigsum;
> > CHECK_OVERFLOW(bigstr, (sum = lside + rside));
> >
> > if (OVERFLOW) {
> > foo->vtable->set_integer[BIGINT](foo, bigsum, key[0]);
> > } else {
> > foo->vtable->set_integer[NATIVE](foo, sum, key[0]);
> > }
> >
> > and foo's set_integer storing the passed data in the database as
> appropriate.
> >
> > >And if we replace that line for the correspondent set_string operation, I
> > >don't see the need to have add in a vtable, because I cannot
> understand how
> > >it could be implemented differently for another variable aside from foo.
> >
> > Now, as to this...
> >
> > What happens if you have an overloaded array on the left side? Or a complex
> > number? Or a bigint? The point of having add in the vtable (along with a
> > lot of the other stuff that's in there) is so we can have a lot of
> > special-purpose code rather than a hunk of general-purpose code. The idea
> > is to reduce the number of tests and branches and shrink the size of the
> > code we actually execute so we don't blow processor cache or have to clear
> > out execution pipelines.
>
>Having the `key' data structure looks like special-p. -> general-p.
>to me. Is it your idea that the key pointers will simply get passed
>along most of the time and in the end there will be few branches
>because eg. an array value knows it has to do indexing and a scalar
>value will ignore the key pointer?
Yep. (unless we put some meaning to a key for a scalar) Container variables
can have their vtable entries called with or without keys--passing a key of
42 to get_integer for an array gets you the integer value of one of the
array's entries, while calling get_integer with no key gets you the integer
value of the entire array. (Which is probably how scalar(@array) is going
to be implemented)
>Are there estimates about the relative frequencies of
> $a
>vs. $a[] or $a{}
>in perl code?
I know chip has some, but I've been unable to get them from him. One of the
points he made for his Topaz talk is that the majority of the memory a perl
program of any size takes up is tied to its hash and array usage.
>How will non-constant keys be handled? Will there be key data structures
>created on the C-stack or in reused buffers? Or will it be like this:
> 1. one or more ops calculate the key and fetch the PMC
> from the container,
> 2. the PMC is passed to other functions with a NULL key entry.
Good question. I don't know yet.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
