At 02:01 PM 4/25/2001 -0300, Branden wrote:
>At 11:34 AM 25/04/2001 -0400, Dan Sugalski wrote:
>>At 11:01 AM 4/25/2001 -0300, Branden wrote:
>>>2) Anyway, even resizing vtables we would need some more indirection to
>>>determine in which position of the vtable is which operator.
>>
>>No. Each operator goes in a fixed position in the vtable, and it's the
>>same for each table. Anything else is nasty, error prone, and slow.
>
>Well, isn't the idea supporting adding new operators on run-time? That
>cannot be done without having a table that maps the operator to the
>position the operator has in the table...
Sure, and it's a table the parser keeps. By the time the bytecode is
generated, the absolute vtable location will be known.
>If the distinction of compile-time and run-time matters, we have to
>remember that Perl allows run-time to occur inside compile-time (through
>BEGIN and END blocks) and also allows compile-time to occur inside
>run-time (through eval). Tables would potentially have to be updated while
>the program is running, because the change could be done inside of an eval.
Yes, I'm aware of that. In the single-thread case it's pretty much
irrelevant. We *know* the state of the interpreter, and we can mess with
the vtables all we want, as long as offsets of known entries don't change.
That's fine. (Though I, for one, wouldn't mind drawing a sharp line between
compilation time and runtime, and forbidding a bunch of stuff at runtime
(like messing with vtables) or compile time (like starting threads))
>>The other thing to consider is whether a vtable method is needed at all,
>>or if what's really needed is another opcode. The opcode table will also
>>be extendable and overridable, though it shares the same issues of thread
>>safety as the vtables do.
>
>This guy is starting to scare me...
Good, then my work is done. :)
Seriously, I don't see why this should be a scary thing. So, the opcode
table's extendable. So what? It'll make language X mode simpler, for some
value of X, if that language can load in its own set of extended opcodes.
Perhaps someone'll want to do functional programming with the Parrot
runtime, and it makes the most sense from a speed and parser simplicity
standpoint to treat certain activities as atomic things and emit a single
bytecode for them. Extending the opcode table makes sense there.
Think of it this way. Vtable extensions are for extensions to data access.
Opcode extensions are more for extensions to control flow. Both make sense,
but there's not really much overlap. And while you can do each with lots of
wrapper code and no help from the parser or runtime, they become easier if
that help is available.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
