Would it be possible to add a generic
32-bit versus 64-bit "version" to D ?

Currently it uses a certain CPU brand:
> version (AMD64)
> {
>     alias ulong size_t;
>     alias long ptrdiff_t;
> }
> else
> {
>     alias uint size_t;
>     alias int ptrdiff_t;
> }


It should having something more generic,
like "arch32" and "arch64" - or whatever ?
(the longer "Architecture32Bit", perhaps...
Or something equally weird but descriptive)

Like the current D "LittleEndian" and
"BigEndian" versions, which span CPUS.


It's a little tricky, since one could run
a 32-bit operating system on a 64-bit cpu.

So the "version" would have to be for the
target architecture, not for the hardware.


But it should be made something more generic.

--anders


PS. I was thinking of the "PPC64" arch...
    (as opposed to "PPC", which is 32-bit)
    Just as "X86" = 32, and "AMD64" = 64.
    (other names being "i386" and "x86_64")

Anders F Björklund wrote:
> Would it be possible to add a generic
> 32-bit versus 64-bit "version" to D ?
...
> It should having something more generic,
> like "arch32" and "arch64" - or whatever ?
> (the longer "Architecture32Bit", perhaps...
> Or something equally weird but descriptive)
> 
> Like the current D "LittleEndian" and
> "BigEndian" versions, which span CPUS.
> 
> It's a little tricky, since one could run
> a 32-bit operating system on a 64-bit cpu.
> 
> So the "version" would have to be for the
> target architecture, not for the hardware.
> 
> But it should be made something more generic.

I'd like to keep the processor-specific flags and add new generic ones, since there are likely to be different flavors of 64-bit architecture. What I'd really like is to have boolean expression evaluation in version blocks so I could write version(AMD64 || PPC64), but I can see why Walter wants to keep things simple here.


Sean

Sean Kelly wrote:

> I'd like to keep the processor-specific flags and add new generic ones, since there are likely to be different flavors of 64-bit architecture. 

Sorry, I didn't mean for any of the current flags to go away...
(on the contrary, I instead suggested adding both PPC and PPC64)

So I agree that there should be both specific and generic ones.

> What I'd really like is to have boolean expression evaluation in version blocks so I could write version(AMD64 || PPC64), but I can see why Walter wants to keep things simple here.

I wanted to have a single flag for "is the platform 64 bits",
just as there is a short cut for "is the platform big endian"

Otherwise you end up with same situation as you do in C, e.g.:
> #if defined(__arch64__) || defined(__alpha) || defined(__x86_64) ...

--anders

"Anders F Björklund" <afb@algonet.se> wrote in message news:cmqthm$19f7$1@digitaldaemon.com...
> I wanted to have a single flag for "is the platform 64 bits", just as there is a short cut for "is the platform big endian"

I don't think a generic 64 bit identifier would be that useful. AMD64 is for a specific instruction set, and is used for things like setting off inline asm. (As far as I can tell, AMD invented that instruction set and named it AMD64, so even though other CPU makers implement it, it is the AMD64 instruction set.) Win64 is for generic 64 bit Windows.

> Otherwise you end up with same situation as you do in C, e.g.:
> > #if defined(__arch64__) || defined(__alpha) || defined(__x86_64) ...

I'm very familiar with the messy consequences of this <g>, and in fact, it nearly always is goofed up. It's better to decide on a feature, and make a version identifier specific to that feature. Then it's just version(FEATURE).

In article <cmr5pu$1nfp$1@digitaldaemon.com>, Walter says...
>
>
>"Anders F Björklund" <afb@algonet.se> wrote in message news:cmqthm$19f7$1@digitaldaemon.com...
>> I wanted to have a single flag for "is the platform 64 bits", just as there is a short cut for "is the platform big endian"
>
>I don't think a generic 64 bit identifier would be that useful. AMD64 is for a specific instruction set, and is used for things like setting off inline asm. (As far as I can tell, AMD invented that instruction set and named it AMD64, so even though other CPU makers implement it, it is the AMD64 instruction set.) Win64 is for generic 64 bit Windows.

I can only think of one use for a generic 64-bit flag: type aliases.  And I really don't mind having multiple blocks if it's only to declare size_t and a few other types.


Sean

Walter wrote:

> I don't think a generic 64 bit identifier would be that useful. AMD64 is for
> a specific instruction set, and is used for things like setting off inline
> asm. (As far as I can tell, AMD invented that instruction set and named it
> AMD64, so even though other CPU makers implement it, it is the AMD64
> instruction set.) Win64 is for generic 64 bit Windows.

Okay.
(naming seems tied between "AMD64" and "x86_64", as far as I can tell)


Then the code needs to be changed to:

version (AMD64)
{
    alias ulong size_t;
    alias long ptrdiff_t;
}
else version (PPC64)
{
    alias ulong size_t;
    alias long ptrdiff_t;
}
else // X86 or PPC
{
    alias uint size_t;
    alias int ptrdiff_t;
}

Probably with Alpha and Sparc-64 later ?

> I'm very familiar with the messy consequences of this <g>, and in fact, it
> nearly always is goofed up. It's better to decide on a feature, and make a
> version identifier specific to that feature. Then it's just
> version(FEATURE).

Like version(AltiVec)? Or I guess one could go to extern(C) for that?
Implementing all the vector stuff will probably take a lot of effort...
http://www.simdtech.org/altivec


But besides pointer sizes and differences, I can't really tell of a USE
for a 32/64 bit flag. Perhaps in deciding which int size to use, or so?
(since "long" will be emulated with two "int"s, if not on a 64-bit arch)

--anders

AMD invented the x86_64,
they named it AA64, Intel created the Itanium cpus,
which emulates x86, but they use IA64, which has nothing
 to do with IA32 (x86)

- Asaf.

"Anders F Björklund" <afb@algonet.se> wrote in message news:cmrjcq$2coa$1@digitaldaemon.com...
> Walter wrote:
>
>> I don't think a generic 64 bit identifier would be that useful. AMD64 is
>> for
>> a specific instruction set, and is used for things like setting off
>> inline
>> asm. (As far as I can tell, AMD invented that instruction set and named
>> it
>> AMD64, so even though other CPU makers implement it, it is the AMD64
>> instruction set.) Win64 is for generic 64 bit Windows.
>
> Okay.
> (naming seems tied between "AMD64" and "x86_64", as far as I can tell)
>
>
> Then the code needs to be changed to:
>
> version (AMD64)
> {
>     alias ulong size_t;
>     alias long ptrdiff_t;
> }
> else version (PPC64)
> {
>     alias ulong size_t;
>     alias long ptrdiff_t;
> }
> else // X86 or PPC
> {
>     alias uint size_t;
>     alias int ptrdiff_t;
> }
>
> Probably with Alpha and Sparc-64 later ?
>
>> I'm very familiar with the messy consequences of this <g>, and in fact,
>> it
>> nearly always is goofed up. It's better to decide on a feature, and make
>> a
>> version identifier specific to that feature. Then it's just
>> version(FEATURE).
>
> Like version(AltiVec)? Or I guess one could go to extern(C) for that?
> Implementing all the vector stuff will probably take a lot of effort...
> http://www.simdtech.org/altivec
>
>
> But besides pointer sizes and differences, I can't really tell of a USE for a 32/64 bit flag. Perhaps in deciding which int size to use, or so? (since "long" will be emulated with two "int"s, if not on a 64-bit arch)
>
> --anders