[RFC] removing library NCI signatures from core

Peter Lobsinger plobsing at gmail.com
Fri Feb 26 19:22:13 UTC 2010


On Fri, Feb 26, 2010 at 1:26 PM, Andrew Whitworth <wknight8111 at gmail.com> wrote:
> On Fri, Feb 26, 2010 at 12:59 PM, Peter Lobsinger <plobsing at gmail.com> wrote:
>> 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'm not certain I follow all this. In either case, we always need to
> have an NCI thunk and NCI PMC associated with the method, though in
> the PCC case we only need one NCI thunk with a single signature, which
> saves on code bloat. We always need the PCC signature for things like
> MMD, but we don't usually need the NCI signature to be available for
> any reason besides the NCI dispatcher itself.

What I'm getting at is that pmc2c hides information from the rest of
the system. AFAICT, you cannot obtain the PCC signature of raw/managed
methods, because the wrapping NCI pmc has no information about them.
When the wrapping NCI pmc knows the NCI signature, it can generate the
PCC signature for the function from the given NCI signature. In fact,
it must generate a pcc signature for a runtime frame builder to work
correctly.

Here's an example using arity:

.sub 'main' :main
    # malloc - thunked nci
    $P0 = loadlib ''
    $P1 = dlfunc $P0, 'malloc', 'pi'
    print "malloc type: "
    $S0 = typeof $P1
    say $S0
    print "malloc arity: "
    $I0 = $P1.'arity'()
    say $I0

    # RPA.append - raw nci
    $P0 = new 'ResizablePMCArray'
    $P1 = find_method $P0, 'append'
    print "RPA.append type: "
    $S0 = typeof $P1
    say $S0
    print "RPA.append arity: "
    $I0 = $P1.'arity'() # boom
    say $I0
.end

> Also, does the NCI dispatcher support all the argument options that
> PCC supports (:optional and :opt_flag, :named, :slurpy, etc)? Does it
> support multiple return values, including return values with option
> flags (:flat and :named)? My understanding is that NCI is a gateway
> system that converts from Parrot's calling conventions to C's calling
> conventions, and is limited to supporting the options that C functions
> support, maybe with some massaging to get things into format.

This is a point I hadn't considered. I did not know that pmc2c methods
were permitted to make use of the full gamut of PCC argument options.
But a quick ack through src/pmc shows that not only is it permitted,
it is in use. I am now convinced that using NCI thunks for methods is
not a good idea.

> If the question is about complexity in the NCI PMC when
> differentiating between subs which are "managed" (using PCC to
> pack/unpack args) and "unmanaged" (args must be passed in through the
> C function  interface), I think the better solution is to have two
> different NCI PMC types that each perform a single operation. METHODs
> in Pmc2c land could be "ManagedNCI" or "PCCMethod" or something like
> that. This gives us simpler code and some possibilities to streamline
> certain code paths with only the overhead of registering a new PMC
> type. In fact if we were smart about it, a simple PCCMethod PMC could
> cut out a lot of the unnecessary logic of the NCI dispatch mechanism.

I like the 2 pmc solution solution.


More information about the parrot-dev mailing list