On Mon, May 02, 2005 at 12:24:04AM +0100, Dave Mitchell wrote: > On Sun, May 01, 2005 at 11:36:02PM +0100, Nicholas Clark wrote: > > in the common cases be able to access the PObj structure members directly. > > I may be speaking here like someone at the back who hasn't been paying > attention, but.. > > isn't the whole point of PMCs to provide encaspulation, so isn't the > ponie core directly checking flags and accessing PMCs internals just a > tad naughty?
The problem is as Aaron describes it - there's a heck of a lot of code in the perl code that is busy doing flag tests, and I doubt that all of it is going to get re-written. I'm assuming that non-Perl5 PMCs are going to behave like some sort of variant of a tied-thing to Perl 5 code, but the native scalars created in Perl 5 space are going to need to continue behaving the way they currently do. Somehow. I was still thinking that there would be encapsulation - this was more an optimisation thought for the existing Sv*() flag test macros. Currently they're all calling Parrot_PMC_get_intval_intkey() to ask the PMC for a flag's value, but that PMC method is really for getting array elements, as I understand it, and therefore isn't going to be viable once Perl 5 AVs need to start presenting an array like interface to the world, and quack the way any other Parrot PMC array type quacks. On Tue, May 03, 2005 at 09:54:40PM -0400, Aaron Sherman wrote: > On Mon, 2005-05-02 at 08:58 +0200, Leopold Toetsch wrote: > > Nicholas Clark <[EMAIL PROTECTED]> wrote: > > > > 1 bit for SVf_IOK > > > 1 bit for SVf_NOK > > > 1 bit for SVf_POK > > > 1 bit for SVf_ROK > > > > I'd not mess around with (or introduce) flag bits. The more that this > > would only cover perl5 PMCs. Presuming that the Perl5 PMCs are subtypes > > of Parrot core PMCs, I'd do ... > [... code doing a string "isa" check on the type ...] > > > The vtable functions C<isa> and C<does>, which take now a string, are a > > bit heavy-weighted and might get an extension in the log run that take > > an integer flag. > > Unless this happens, this would be a HUGE performance hit. After all, > Sv*OK is called all over the place in the Perl 5 code, including many > places where performance is an issue. This was my fear. On Wed, May 04, 2005 at 07:51:26AM +0200, Leopold Toetsch wrote: > Aaron Sherman wrote: > >On Mon, 2005-05-02 at 08:58 +0200, Leopold Toetsch wrote: > > >>The vtable functions C<isa> and C<does>, which take now a string, are a > >>bit heavy-weighted and might get an extension in the log run that take > >>an integer flag. > > > > > >Unless this happens, this would be a HUGE performance hit. After all, > >Sv*OK is called all over the place in the Perl 5 code, including many > >places where performance is an issue. > > >Here is some example P5 source from pp_pow in pp.c: > > I presume that Ponie eventually will run Parrot opcodes. pp_pow() is > like all these functions part of the perl runloop. Therefore it'll be > > infix .MMD_POW, P1, P2, P3 > > which will do a MM dispatch depending on (P1, P2). That's all. No flags > needed. Yes, I think that the plan is that eventually all the PP code gets converted into the PMCs. However there's a lot of source outside pp*.c and the SV/AV/HV/CV/GV manipulation code. > >If you're writing a compiler from scratch, I can see that being mostly > >true. However, in trying to port Perl 5 guts over to Parrot, there's a > >lot of code that relies on knowing what's going on (e.g. if a value has > >ever been a number, etc.) > > Most of the guts are called from the runloop. But there is of course XS > code that messes with SV internals. Which is the stuff we're trying to keep working unchanged. Speed-wise, I think the problem I *think* I was trying to address here was that there's a lot of XS and core code that assumes that SV flag checking is a fast operation. And as "Flag" checking isn't standard parrot vtable operation it's not going to be fast on any scalar, and as it's not a standard parrot vtable operation, all the alien types passed into the perl code aren't automatically going to report back the correct flags to say "treat me roughly like a string" or "roughly like a number" or "a reference to something else" Nicholas Clark
