On Fri, Feb 26, 2010 at 12:59 PM, Peter Lobsinger <[email protected]> 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 _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
