Simon Cozens wrote:
> On Mon, Nov 05, 2001 at 11:35:53PM -0500, Ken Fox wrote:
> > IMHO Perl is getting
>
> Interesting construction. :)
Yeah, that should have been a disclaimer. I've heard static typing
proposed, but nothing appears finalized about anything yet. Something
like static typing might even be a bolt-on module if it doesn't make
the core.
> > some static typing ability, so it should be able
> > to emit bytecode that doesn't go through the PMC vtable.
>
> Yes, but that's fundamentally different from inlining vtable methods
> in the runops loop, which is what you were originally suggesting.
> I'm now unsure what you're actually getting at.
If the guts of a vtable implementation are ripped out and given an
op, isn't that inlining a PMC method? There doesn't seem much point
in replacing a dynamic vtable offset with a constant vtable offset.
The method really needs to be inlined -- either by copying the code
or by calling the implementation directly.
For example, if you have a length op, the generic one would
dispatch through a vtable: (hand waving pseudo code)
op_length:
integer[pc[1]] = pmc[pc[2]]->vtable.length(pmc[pc[2]]);
pc += 3;
goto *pc;
the inlined one should be:
op_length_array:
if (pmc[pc[2]]->type == PERL_ARRAY) {
integer[pc[1]] = ((Perl_Array *)pmc[pc[2]])->length;
pc += 3;
goto *pc;
}
else {
goto op_length;
}
It's probably naive to think that "static" typing is going to be
reliable enough to eliminate the type check. Hopefully branch
prediction will be nearly 100% accurate though.
This code would be horrible to implement and maintain by hand though.
It would be very cool if there was an option to unroll PMC methods
into inlined ops based on profiling example code. Perl might even send
enough type information to Parrot that Parrot could do some strength
reduction on its own (and replace generic PMC ops with inlined PMC
ops).
- Ken
