www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - 32-bit / 64-bit cpu version()

reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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")
Nov 09 2004
parent reply Sean Kelly <sean f4.ca> writes:
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
Nov 09 2004
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Nov 09 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"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).
Nov 09 2004
next sibling parent Sean Kelly <sean f4.ca> writes:
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
Nov 09 2004
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Nov 09 2004
parent "Asaf Karagila" <kas1 netvision.net.il> writes:
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
Nov 09 2004