[M3devel] rant -- Why has 64 bit integer support been so hard?

Darko darko at darko.org
Sat Aug 11 17:26:44 CEST 2007


INTEGER in M3 is much more abstract than C, you can use it largely  
without thinking about what size it is, or at least you should.  
Portability and simplicity are other benefits you get with M3  
compared to C++.

On 11/08/2007, at 5:15 PM, Tony Hosking wrote:

> I think you have reasonably illustrated just why C/C++ is such a  
> mess.  In M3 we have "BITS n FOR ..." to get appropriately sized  
> things, equivalent to C/C++ char, short, long, long long.  The  
> split between INTEGER and LONGINT is unfortunate perhaps, but  
> represents an explicit signal to programmers that INTEGER and  
> LONGINT have different underlying representations, which is in the  
> spirit of Modula-3's existing type system.   Perhaps we should be  
> explicit in the C type mappings for M3 by writing:
>
> char = BITS 8 FOR ...
> short = BITS 16 FOR ...
> int = BITS 32 FOR ...
> long_long = BITS 64 FOR ...
>
> On Aug 11, 2007, at 10:26 AM, j k wrote:
>
>> I know, like, the point of Modula-3 is to not be like C or C++ and  
>> to revisit everything in them, but..really?
>>
>> Windows programming in C and C++ has had this solved reasonable  
>> for MANY YEARS.
>> Other folks solved it similarly even longer ago, though I would  
>> claim Windows's
>> approach has been successfully applied to more code -- that is,  
>> all of Windows, and then some.
>>
>> Windows C/C++ is flawed here, but not in a too terrible way.
>> In particular, Windows C/C++ has too many names for the same  
>> types, with various
>> flimsy rationale, mostly "style" and "history".
>>
>> All you need is the following:
>>
>>   signed and unsigned integer types that are exactly 8 bits in size
>>   signed and unsigned integer types that are exactly 16 bits in size
>>   signed and unsigned integer types that are exactly 32 bits in size
>>   signed and unsigned integer types that are exactly 64 bits in size
>>   signed and unsigned integer types that are exactly the size of a  
>> pointer
>>
>>  10 integer types total, named something like:
>>    INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64,  
>> size_t or UINT_PTR, ptrdiff_t or INT_PTR
>>
>>  The types "int" and "long" and unsigned thereof NEVER changed size.
>>  Where people were using them for pointer sized things, you would  
>> do a simple transform to port to 64 bit:
>>    int => INT => INT_PTR
>>    unsigned => UINT => UINT_PTR
>>    DWORD => DWORD_PTR
>>
>>   convert to the upper case types if not there, and append "_PTR"
>>
>>  The existing types size_t and ptrdiff_t did change size.
>>   If someone really needed 32 bit types there, you'd have to  
>> change your code.
>>
>>  Windows has more than that for historical and stylistics reasons  
>> -- upper case types,
>>    lowercase types, types that "favor" being unsigned int or  
>> unsigned long.
>>
>>  Some of it is C's fault -- the "short" and "long" stuff seems all  
>> unnecessary.
>>
>>  C 9x adds in "fast" and "small" types
>>     types that are the smallest type that is at least a certain  
>> size, I think
>>     types that are the fastest type that are at least a certain  
>> size, I think
>>      the idea here being that if 64 bit integers are "faster" than  
>> 32 bit integers, then "fast32" might be 64 bits
>>
>>  In reality, I think the 10 types are confusing enough, but  
>> necessary, C9x multiplies out
>>    beyond necessity. Yeah, obviously, they seem like maybe you  
>> might want them, but
>>    it's just too many times imho. Imho 8, 16, and 32 bit integers  
>> must remain efficient
>>    to use on all forseeable processors, since tons of code uses  
>> them, and people should not
>>    will not be pushed to widen everything across the board. Yeah,  
>> 64K and 4GB limits are
>>    mostly stupid these days and they very often should be widened,  
>> but folks can do that
>>    "slowly" on their own, managing compatibilit themselves -- like  
>> where binary file i/o is used.
>>
>>   Why has this been so hard in Modula-3?
>>
>>   Is it that "Word" is widely used and has been pointer sized?
>>   Or that INTEGER has been widely used and sometimes assumed to be  
>> pointer sized?
>>
>>   Is it that Sparc64 (?) and 64 bit Alpha have existed for a long  
>> time but
>>     weren't done right and there is some legacy we are stuck with??
>>
>>   Do "subrange" types make it all confusing?
>>
>>   Or merely the assignment rules among the non subrange integer  
>> types?
>>
>>  I have not paid particularly close attention; it just has always  
>> surprised me
>>    that it was difficult to work out what to do.
>>
>>  I guess it is all moot now, the issues have been worked out and  
>> the feature is there. Good.
>>
>>  I am skeptical that the name "LONGINT" is good. I am skeptical  
>> that the slightly
>>   abstracted C names "short", "int", "long" are a useful abstraction.
>>   I think you really want the 10 base types I first listed.
>>
>> btw, even the types that are same size as a pointer are overused  
>> in C/C++.
>> You don't need them for as much pointer arithmetic as people use.  
>> You can use "char*" for that.
>> They are useful for array indices though, the result of wcslen,  
>> sizeof(), etc.
>>
>> File sizes should always be UINT64..
>>
>>      - Jay
>>
>> Recharge--play some free games. Win cool prizes too! Play It!
>




More information about the M3devel mailing list