Adding modifiers to NCI

[Allison Randal]

chromatic wrote:
> 
> I don't see how this works with C calling conventions.  It works fine for 
> Parrot calling conventions, but C calling conventions care about type, width, 
> signedness, and pointerness, and they're strictly positional.

Well, look at the syntax for NCI signatures. They define pretty much 
exactly the same items as PCC, just adding more types and using 
different syntax conventions:

# INT register stuff
# I - INTVAL
# c - char
# s - short
# i - int
# l - long

# NUM register stuff
# N - FLOATVAL
# f - float
# d - double

# STR register stuff
# S - pointer to a STRING-register
# t - character string (0-terminated)
# Buffers are not valid return parameters,
# use 'p' when the native function returns a pointer value
# b - void *
# B - void **

# PMC register stuff
# P - pointer to a PMC-register
# O - pointer to PMC-register (object)
# p - data pointer from PMC (on store into a new UnManagedStruct PMC)
# 2 - pointer to short
# 3 - pointer to int
# 4 - pointer to long

# void stuff
# v - void

# special stuff
# 0 - insert a NULL (pointer) - doesn't consume a register
# J - Parrot_Interp param
# @ - slurpy array

# callback stuff
# U - Single PMC parameter to pass into callback - user data


Shifting this syntax over to PCC-style is a trivial conversion.

> I suppose we could flip the current NCI signatures so that the return value 
> type signifier always appears at the end of the signature, prefixed with ->, 
> but even that doesn't make sense, for two reasons:
> 
> 	- C functions always have a single return type (even if that type is void)

True, but the arrow separation still makes it easier to read, and 
doesn't make it any more difficult to parse.

> 	- our current signature style matches C function signature declarations more 
> directly, where the C signature is void int int int, for example.

If it matched C function signatures exactly that would be a compelling 
reason, but it doesn't. NCI signatures have more in common with PCC 
signatures than they do with C function signatures. (First design 
principles: similar things should be similar, and different things 
should be different.)

> What value is there in attempting to unify the descriptions of two very 
> different types of calling conventions?

The biggest reason is the maintenance burden. Currently we have 3 
completely different ways of representing a call signature as a string. 
That's a big red flag of unnecessary complexity.

Another reason is code complexity. 3 different syntaxes for signatures 
means 3 different sets of routines for parsing those signatures, as well 
as the various supporting routines for each syntax. Also, using the same 
signatures in PCC and NCI will help us streamline invocations that cross 
those boundaries.

The kicker is that PCC needs to be extended to handle several low-level 
C types, to allow for more low-level methods on things like FileHandles 
(for clean subclassing). Once we start extending NCI to be more like PCC 
and extending PCC to be more like NCI, it really is time to merge the two.

Allison