Dan Sugalski wrote:
> At 05:41 PM 2/6/2001 -0200, Branden wrote:
> > > >I actually don't see a reason why the vtable entries should be the
> >opcodes.
> > > >Is there?
> > >
> > > Speed.
> > >
> >
> >Actually, I don't see the problem of defining a C function that would do:
> >
> > void add(SVAR *result, SVAR *lop, SVAR *rop, SVAL *tmp1, SVAL *tmp2)
{
> > /* tmp comes from the temporary file */
> > lop->vtable->FETCH(tmp1, lop);
> > rop->vtable->FETCH(tmp2, rop);
> > lop->vtable->ADD(tmp1, tmp1, tmp2);
> > result->vtable->STORE(result, tmp1, tmp2);
> > }
> >
> >And have it be my opcode. Passing the indexes wouldn't be a problem
either.
> >Is there any problem here?
>
> Well, no, but what's the point? If you're calling lop's ADD vtable entry,
> why not have that entry deal with the rest of it, rather than stick things
> into, and later remove them, from temp slots?
>
Dan,
I see you talk about vtables and opcodes as related things. I really don't
see why you think that's necessary, I'd like to hear why you think it.
As far as I know (and I could be _very_ wrong), the primary objectives of
vtables are:
1. Allowing extensible datatypes to be created by extensions and used in
Perl.
2. Making the implementation of `tie' and `overload' more efficient ('cause
it's very slow in Perl 5).
3. Replacing Perl5's SV*,AV*,HV*,... (I don't know if it should replace or
complement -- ?)
And some secondary objectives are:
4. Allow the use of different string encodings internally.
5. Allow int's and float's to become bigint's and bigfloat's when an
overflow occurs.
Is this right or am I missing something?
The point I want to make, is that vtables are directly related to what tie
and overload are today (or sv_magic, if you want the underlying thing [I
don't know what's underlying in overload case, as it's apparently not
documented]). So I don't really see why opcodes are in the discussion. For
me, at least, tie and overload are related to data, and opcodes with
execution. They are orthogonal things, or at least should be (sure that
doesn't mean they are not related and should be implemented separately, but
they sure can).
Of course I understand some opcodes are related to data manipulation, and
should of course be modelled after vtables, but they surely can be
separated. Before I proposed the code above for `add', taking 3 SVAR's and
doing the same as what you proposed (considering no arrays/hashes). I
thought about it, and I saw that it could be extended to handle 3 PMC's,
instead of SVAR's. If they are SVAL's, they are passed directly to the
vtable, otherwise they are fetched/stored using keys that are passed by
parameters. The add method would be able to determine it by the TYPE vtable
entry (finally found a use for it...). That would actually result in the
exact same opcodes that your approach would.
[[ And I actually see an advantage here. As I expect SVAL's to be used by
temporarys, in a longer expression that involves multiple operations, all
results would be stored in SVAL's, that don't have store/fetch operation
(since it's trivial) and so it's cheaper to use them. ]] <-- I actually am
wrong here. I thought having to call store/fetch would be an issue, since it
is for tied things in Perl 5, but here it only costs what the method has to
do, what gives me the hint that in Perl 6, tie will be the fastest thing
ever.
Some more about opcode dispatching. What it has to do is:
1. Fetch an instruction (that would be a byte indicating which operation)
2. Find the function that handles this instruction (that would be lookup in
a table)
3. Call the function (here I refer to the stack handling, of passing and
returning parameters and return addresses...)
4. [ Here goes the instruction computing, made by the fetched function ]
5. Some cleanup (I think nothing really expensive)
6. Loop. Go back to 1 and fetch the next instruction.
Ok. Am I right here or I'm missing something really dumb?
If it's this way, what is so expensive here that makes 4 instructions so
much slower than 1 if the 4 together make the same thing as the 1? Compared
to what an `add' function would tipically do, testing the argument types,
and possibly converting things to bigints, or even a `concat' function
having to allocate memory and copy possibly big blocks of bytes, I don't see
what's the problem with some CPU cycles to push the parameters to a stack...
Of course, there is probably something very dumb I'm missing here. Please
point it to me.
- Branden
