GSoC NCI Purposed Improvements

[John Harrison]

On Tue, May 25, 2010 at 2:50 PM, Andy Dougherty <doughera at lafayette.edu>wrote:

> On Mon, 24 May 2010, John Harrison wrote:
>
> > My GSoC is getting underway with improvements to the NCI system. After
> > reading over the current work and suggestions for the NCI system I have
> come
> > up with the following suggestions/improvements to the current system.
> >
>
> > Base Data Types:
>
> >     s = short - 16 bit
> >     l = long - 32 bit
> >     i = int
> >     q = long long - 64 bit
>
> I think these specific type-size mappings will be confusing, at best, on
> systems where those C data types are of different sizes.  For example,
> it is perfectly legal to have a system where short, int, and long are
> all 64 bit.  I think if you want to specify a particular size, you might
> be best off including that explicitly in the name, e.g. something like
> i16, i32, or i64, as you suggest below, and leave the 's', 'i', and 'l'
> to simply mean the native type, whatever that size might be.
>

Thats not strictly true. According the C standard, short, long, long long
and char all have defined limits (in <limits.h>

But also, I left int un qualified for a reason. I said I'd like to support a
postfix definitions of "i#" or in a regex /i\d+/ where the digit is the
size. So standard sizes could be defined as i8, i16, i32, i64, i128... etc.

Also, I am aware they may not all fit in an INTVAL, but I'll figure out how
I'll deal with that later. For now, I wanted to have a solid definition of
the work I am going to be doing before I got started.

I also stole what I think is a pretty good idea from Perl 5's pack function.
If you use ! with type, it will use your system definition of the type
instead of the built in ones I am defining.


> Also, beware that not all integral types will necessarily fit in
> parrot's INTVAL.
>
> --
>    Andy Dougherty              doughera at lafayette.edu
>



---
John Harrison
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.parrot.org/pipermail/parrot-dev/attachments/20100525/d3e6d682/attachment.html>