Thread overview
Proposal: c_int
Jan 06, 2006
Thomas Kuehne
Jan 06, 2006
Sean Kelly
Jan 06, 2006
Thomas Kuehne
Jan 06, 2006
Sean Kelly
January 06, 2006
Problem:

On 64-bit Windows systems "int" is defined as "std.stdint.int32_t".
On 64-bit Unix systems "int" is defined as "std.stdint.int64_t"
(64-bit mode) or "std.stdint.int32_t" (32-bit mode).

All C bindings would have to write their own kludges to evade those problems. The current problem is that those kludges can't be written in D. No, "version(X86_64)" isn't sufficent.

The situation is the same for "unsigned int", "long", "unsigned long", "long long" and "unsigned long long".

Implementing at least on of the suggestions below would allow a "pure D" soultion.

Suggestion: 1/3
Define size_t and ptrdiff_t as true D types directly in the compiler
and add the following snipplet to std.stdint:

> version(Win32){
>     alias int32_t c_int;
> }else version(Win64){
>     alias int32_t c_int;
> }else version(Windows){
>     static assert(0);
> }else{
>     alias ptrdiff_t c_int;
> }

Suggestion: 2/3
Define D_BITS_PER_C_INT_32 or D_BITS_PER_C_INT_64 as predefined versions
in the compiler and add the following to std.stdint:

> version(D_BITS_PER_C_INT_32){
>     alias int32_t c_int;
> }else version(D_BITS_PER_C_INT_64){
>     alias int64_t c_int;
> }else{
>     static assert(0);
> }

Suggestion: 3/3
Enhance "version" so, that a version can have a numerical value
and define "version[D_BITS_PER_C_INT=32" or "version[D_BITS_PER_C_INT=64"
inside the compiler and add the following to std.stdint:

> version(D_BITS_PER_C_INT == 32){
>      alias int32_t c_int;
> }version(D_BITS_PER_C_INT == 64){
>      alias int64_t c_int;
> }else{
>      static assert(0);
> }

Suggestion 3 seems to be the most powerfull one and might solve other common implementation problems too.

Thomas


January 06, 2006
Thomas Kuehne wrote:

> On 64-bit Windows systems "int" is defined as "std.stdint.int32_t".
> On 64-bit Unix systems "int" is defined as "std.stdint.int64_t" (64-bit mode) or "std.stdint.int32_t" (32-bit mode).

For what it is worth, on PPC64 "int" is 32 bits and "long" is 64 bits.
I believe the same is true in the AMD64 arch ABI for Linux, as well ?

(I think the programming model is called LP64 ?)
See http://developer.apple.com/macosx/64bit.html

This still means that ints can no longer hold pointers, for instance...
(nor can it hold the length of a pointer, need to use size_t for that)


Side note:
I think it would be nice if there was a short D name to use for
"largest hardware implemented integer size", for loops and such ?
(since "int" is always 32 bits and "size_t" is hard to pronounce)

Like the current variable-size "real" type for floating point ?
Too bad that the natural name for such a thing is already taken...
Then again I haven't benchmarked, maybe 32-bit is just as "fast" ?

Just thinking about something that would be 32 bits on a 32-bit
machine and 64 bits on a 64-bit machine (i.e. in 64 bit mode) ?

--anders


PS. Another fun change is that "bool" is now back at 1 byte, from 4.
    (change in the Mac OS X ppc ABI that was, from 32-bit to 64-bit)

    On the X86->X64 side, one noteworthy change is that "long double"
    is now 16 bytes in size instead of 12 (but still *using* just 10)
January 06, 2006
Thomas Kuehne wrote:
> 
> On 64-bit Windows systems "int" is defined as "std.stdint.int32_t".
> On 64-bit Unix systems "int" is defined as "std.stdint.int64_t" (64-bit mode) or "std.stdint.int32_t" (32-bit mode).
> 
> All C bindings would have to write their own kludges to evade those
> problems. The current problem is that those kludges can't be written in D.

*sigh* I'd forgotten about this.  I'd be happy to update the C headers in Ares with whatever method seems appropriate.


Sean
January 06, 2006
Anders F Björklund wrote:
> Thomas Kuehne wrote:
> 
>> On 64-bit Windows systems "int" is defined as "std.stdint.int32_t".
>> On 64-bit Unix systems "int" is defined as "std.stdint.int64_t" (64-bit mode) or "std.stdint.int32_t" (32-bit mode).
> 
> For what it is worth, on PPC64 "int" is 32 bits and "long" is 64 bits.
> I believe the same is true in the AMD64 arch ABI for Linux, as well ?

Hrm... I think that's actually correct.  I don't know of any platforms offhand where the size of 'int' are changing--it was 'long' that was the issue.  This should improve things considerably, though it will mean more work modifying the headers as a search-replace isn't possible.  I'm of a mind to just create an alias for each size type to address this: c_int, c_long, etc.  I wish I'd done that at the outset.


Sean
January 06, 2006
Anders F Björklund schrieb am 2006-01-06:
> Thomas Kuehne wrote:
>
>> On 64-bit Windows systems "int" is defined as "std.stdint.int32_t".
>> On 64-bit Unix systems "int" is defined as "std.stdint.int64_t"
>> (64-bit mode) or "std.stdint.int32_t" (32-bit mode).
>
> For what it is worth, on PPC64 "int" is 32 bits and "long" is 64 bits. I believe the same is true in the AMD64 arch ABI for Linux, as well ?
>
> (I think the programming model is called LP64 ?)
> See http://developer.apple.com/macosx/64bit.html

Right, please replace "int" with "long" in my posting.

> Side note:
> I think it would be nice if there was a short D name to use for
> "largest hardware implemented integer size", for loops and such ?
> (since "int" is always 32 bits and "size_t" is hard to pronounce)
>
> Like the current variable-size "real" type for floating point ?

Sounds usefull.

>      On the X86->X64 side, one noteworthy change is that "long double"
>      is now 16 bytes in size instead of 12 (but still *using* just 10)

Don't tell me they wasted 3/8 of the storage to be compatible with old binaries and have a decent alignment...

Thomas


January 06, 2006
Thomas Kuehne wrote:

>>     On the X86->X64 side, one noteworthy change is that "long double"
>>     is now 16 bytes in size instead of 12 (but still *using* just 10)
> 
> Don't tell me they wasted 3/8 of the storage to be compatible with old
> binaries and have a decent alignment...

You got it... 2 bytes "wasted" on X86, and 6 bytes on X64.

Read about it in: http://gcc.fyxm.net/summit/2003/Porting%20to%2064%20bit.pdf

--anders
January 06, 2006
Thomas Kuehne wrote:

>>I think it would be nice if there was a short D name to use for
>>"largest hardware implemented integer size", for loops and such ?
>>(since "int" is always 32 bits and "size_t" is hard to pronounce)
>>
>>Like the current variable-size "real" type for floating point ?
> 
> Sounds usefull.

Wonder if it makes a difference, though ? It doesn't on PowerPC,
since the PPC is a 64-bit architecture with a 32-bit subset...

Perhaps it does on X86, but I would imagine that being able to
quickly handle 32-bit integers would be a pretty high priority ?

--anders