Dan Sugalski wrote:
>
> At 05:02 PM 2/3/2001 +0100, Edwin Steiner wrote:
> >Might this be madness? (BRAINSTORMS AHEAD!):
>
> Generally, yes. :)
>
> The vtable stuff won't be exposed outside the core. This means embedding
> programs and extensions will *not* be using it. Generally speaking, it'll
> be opcode functions only that'll be hitting the vtables.
>
> While I'm not hugely averse to some macro-ization, I don't think this is a
> spot worth that much mental effort, at least not for individual vtable
> calls, which will probably be looking like:
>
> PMC->vtable[ADD][UTF_32](DEST, PMC1, PMC2);
>
> Also, as a sort of side thing, don't expect the vtables for each type to be
> all that different, if at all. Conceptually I'm not sure it's worth trying
> to segregate them out to scalar, hash, array, and list vtable types. (Plus
> we get a minor benefit in that if they all have an identical set of vtable
> slots things won't go bang really badly if an incorrect PMC slps in somewhere)
Will it be like this?:
[frontend, bytecode compiler]
These know about $,@,%,(),... syntax and semantics and use this
knowledge to choose the right opcodes for the job.
Perl data used for the parser's or compiler's own purposes is handled like
in extending/embedding code (opaque PMCs, function call API).
This part generates ->-+
|
======== bytecode (independent from vtable layout) ========
|
is executed by -<-+
|
[core]
Every value is a PMC, which is a pointer to a
struct {
vtable_t * vtable;
void * data;
void * gc_data;
}
(The name PMC is a bit misleading for this non-opaque
thing, though.)
Not many checks about 'type of value'. The right opcodes just
"happen to be called", the remaining cases are handled by virtual
function dispatch.
+ opcode functions: know about vtable layout
+ data type implementations (bodies of virtual functions): know about
vtables and stuff pointed to by data
+ GC: knows about gc_data, obviously
+ implementation of function call API for extensions/embedding apps
and for other parts of perl:
(wrappers for opcode and virtual functions, convenience functions)
implements ->-+
|
======== API of function calls (with opaque PMC args) ========
|
+->-use->-+
|
[extensions, embedding apps, parser, compiler, ...]
every value is an opaque PMC
Thanks for dealing with the obvious(?) for the community's
learning experience. (If you have read so far :)
How is it handled, when an extension implements a new data type (in C)?
Will there be something wrapped around the vtables, which provides
a tie-like callback facility, so the new data type implementation
doesn't need to know about vtables?
-Edwin
