[RFC] removing library NCI signatures from core

[Andrew Whitworth]

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.

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.

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 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.

Ideally, I think we all can agree that the long term plans are for
nci_thunk_gen to go away in favor of a proper frame builder. Also, as
I alluded to above, I don't think NCI supports all the features that
we need for Pmc2c methods anyway. NCI should stay the system that
provides a gateway to native code libraries, and PCC should stay the
system that allows passing control flow in the Parrot way (with
argument and return options, multiple return values, values stored in
Parrot registers, access to a Parrot context, etc).

--Andrew Whitworth