[perl #60048] [BUG] [MMD] CGP Does Not Work with PCC Runcore Reentry

Will Coleda via RT parrotbug-followup at parrotcode.org
Wed Dec 24 01:31:40 UTC 2008


On Thu Oct 23 22:59:45 2008, allison at perl.org wrote:
> chromatic (via RT) wrote:
> >
> > Several tests fail with the CGP runcore (parrot -C) when
> multidispatch
> > re-enters bytecode -- in specific, anything that calls into
> src/pic.c from
> > Parrot_pcc_invoke_sub_from_sig_object causes failures.
> >
> > The problem appears to be that CGP's PIC tries to poke into the
> bytecode
> > directly to find get_params and similar opcodes, while parameter-
> passing
> > information is in a context after
> Parrot_pcc_invoke_sub_from_sig_object.
> >
> > One workaround is to enforce the use of the normal runcore only for
> calls back
> > into Parrot from Parrot_pcc_invoke_sub_from_sig_object, but that's
> just a
> > workaround.  A better solution is to fix the PIC code to look in the
> > appropriate place in the context for return values.  That seems like
> a good
> > task for the calling conventions branch.
> 
> I've been debating whether src/pic.c should be removed entirely. It's
> a
> swodge of code that only gives a tiny speedup for 4 opcodes: 'infix',
> 'get_params', 'set_args', and 'set_returns'. And the 'infix' opcode
> has
> been deprecated and will be removed in the calling conventions branch
> (it was a nasty hack for the old MMD system). And it's not even really
> the right speedup for 'get_params', 'set_args', and 'set_returns'.
> 
> There are also a pile of old, nasty MMD functions that should be
> deleted
> and are only called from src/pic.c.
> 
> Allison
> 

I created a branch (remove_pic) to remove src/pic.c; This led to the removal of pic.ops, and 
changes in imc, packfile... lots of references to PIC.

chromatic mentioned on #parrot that if we remove PIC, we're going to break all the 
predereferenced runcores. After some discussion, this probably means ripping out:

16:42 <@chromatic> Everything other than the default core, the nearly-useless 
                   profiling core, and the gc-debug core.

So, I vote we update the deprecation notice in trunk to include the runcores (which means 
delaying the removal until post-0.9.0), and then I can continue the mayhem and destruction 
that has begun in the branch.

Comments?

-- 
Will "Coke" Coleda


More information about the parrot-dev mailing list