Adding modifiers to NCI

[chromatic]

On Friday 26 December 2008 19:02:55 Andrew Whitworth wrote:

> On Fri, Dec 26, 2008 at 8:55 PM, chromatic <chromatic at wgz.org> wrote:

> >> # i (T) - int
> >
> > How many bits?  8?  16?  32?  64?  128?  Signed?  Unsigned?
> >
> >> # l (L) - long
> >
> > How many bits?  Signed?  Unsigned?  How about long long?
>
> I was about to say we could just take the "native" definitions for
> these, but even on the same hardware platform different compilers are
> going to define different lengths for these. Consider "T" for a
> non-INTVAL integer, with a 1, 2, 4, 8 modifier afterwards for the
> number of bytes. "T" would default to whatever the native machine size
> for "unsigned int" is, "T4" is 32 bits, "T8" is 64 bits, etc.

> Our current NCI descriptors are just as arbitrary and limited as our
> current PCC signature strings are, and we may as well expand a single
> system to overcome limitations then expand two separate systems
> separately.

For the sake of unifying the parsers of signatures of two completely different 
calling conventions with separate goals, a C signature of a form well-
understood for almost 40 years as:

	int squash_coords_to_int(uint16 x, uint16 y);

... becomes somewhat less obvious:

	Tu2 Tu2 -> T1

... and we tell all of the people writing PCC signature strings to ignore all 
of the type sizes and signedness modifiers and all of the people writing NCI 
signature strings to *know for certain* how big an INTVAL is on every 
platform, because if they accidentally leave off a number they'll get weird 
crashes and ask me to spend my day poking at code with GDB, oh and also they 
should just ignore all of the Parrot specific signature types which mean 
nothing to shared libraries which are not libparrot and which do not support 
named, slurpy, and flattening parameters in their calling conventions.

Wasn't one goal of defining and using INTVAL and FLOATVAL and STRING within 
the Parrot API to avoid the explosion of datatypes which C has suffered 
because it doesn't have a type system and encourages people to agonize over 
the position of each last byte?

-- c