On Tue, May 25, 2010 at 2:50 PM, Andy Dougherty <[email protected]>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 [email protected] > --- John Harrison
_______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
