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)

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

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

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

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

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