[RFC] removing library NCI signatures from core

Peter Lobsinger plobsing at gmail.com
Fri Feb 26 17:59:44 UTC 2010

Here are some of the reasons why I think that methods should use NCI thunks:

pmc2c methods wind up wrapped with NCI objects anyways. This adds
complexity to the NCI pmc in order to support "raw" subs (which handle
their own PCC) as well as "thunked" subs (which delegate their PCC to
NCI thunks). Also, because the wrapping NCI pmc has more information
about thunked subs (nci signature), it can provide more information to
the rest of the system about them (arity, pcc signature).

I agree that we should standardize on a single code path. However, we
need the NCI thunks anyways, whereas the functionality to handle PCC
in pmc2c is a duplication of that found in nci_thunk_gen. If PCC's API
changes, that makes for one more place that can get forgotten to be
changed. If we make all methods thunked, we'll have less code overall
and fewer places for bugs to hide.

On Mon, Feb 22, 2010 at 6:34 PM, Andrew Whitworth <wknight8111 at gmail.com> wrote:
> On Mon, Feb 22, 2010 at 5:38 PM, Peter Lobsinger <plobsing at gmail.com> wrote:
>>> Seems you're right. pmc2c generates the pcc boilerplate and doesn't
>>> delegate to nci. I was confused by references to pmc methods in
>>> config/gen/call_list/* and the fact that pmc2c calls these functions
>>> "Parrot_${pmc_name}_nci_${method_name}".
>> Turns out even this isn't strictly true. pmc2c generates pcc
>> boilerplate for regular methods, but delegates to NCI for multis. I
>> don't know why. This should probably be changed at some point to be
>> consistent one way or the other (I'm biased towards delegating to NCI
>> for obvious reasons).
> Well, that's interesting. Personally I think we should try to
> standardize on the PCC method for a variety of reasons. Standardizing
> on a single code path lets us get rid of a lot of mode-switching cod,
> let's us focus optimization efforts on a single hotpath, and takes
> some stress off the NCI system that will give us more freedom to
> refactor and improve that system.
> What might make for a good interim measure would be to examine the
> system and see what would be needed to standardize one way or another.
> We can make a better decision once we know more.
> --Andrew Whitworth

More information about the parrot-dev mailing list