At 10:15 AM 11/7/2001 -0500, Ken Fox wrote:
>Dan Sugalski wrote:
> > At 07:47 PM 11/6/2001 -0500, Ken Fox wrote:
> > >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.
> >
> > We can't do that. PMCs, even statically typed ones, can change their
> > vtables as they see fit. Also for this to be at all efficient we'd need to
> > have all the common variable types vtables be available at compile time.
> > That's not likely in the general case.
>
>Isn't this a language decision and not a Parrot decision?
No. The language is perfectly within its rights to emit a series of opcodes
for doing something long-hand instead of using the PMC version of an op,
but that's a different thing entirely. Once you emit an op that makes a
vtable call (pretty much any op with a PMC as an operand) you've handed off
contol to the interpreter and the code associated with the variables.
>It seems like Perl might have a tough time in general using non-PMC
>registers.
Probably, yup. I don't really expect them to be that heavily used, with
perhaps the exception of regular expressions for integer & string
registers, and perhaps string concatenation using the string ops.
>Is anybody working on the Perl code generator yet? I think
>the code generator might influence op implementation.
Brent Dax had babyperl working, but at some point we need to start in on
the real parser, compiler, and optimizer modules.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
