www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Could we get a LP64 version identifier?

reply Jacob Carlborg <doobnet gmail.com> writes:
Could we get a LP64 version identifier? I know that you can use this code:

"static if ((void*).sizeof > int.sizeof)"

to do the same but that's not particular clear that the programmer wants 
to check for LP64. If so, I hope we could get it in D1 also.
Jan 25 2009
next sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Jacob Carlborg wrote:
 Could we get a LP64 version identifier? I know that you can use this code:
 
 "static if ((void*).sizeof > int.sizeof)"
Shouldn't that be "static if ((void*).sizeof == long.sizeof)" or just "static if ((void*).sizeof == 8)"? (Note that in D long.sizeof is guaranteed to be 8)
 to do the same but that's not particular clear that the programmer wants 
 to check for LP64. If so, I hope we could get it in D1 also.
Jan 25 2009
parent reply Jacob Carlborg <doobnet gmail.com> writes:
Frits van Bommel wrote:
 Jacob Carlborg wrote:
 Could we get a LP64 version identifier? I know that you can use this 
 code:

 "static if ((void*).sizeof > int.sizeof)"
Shouldn't that be "static if ((void*).sizeof == long.sizeof)" or just "static if ((void*).sizeof == 8)"? (Note that in D long.sizeof is guaranteed to be 8)
Yeah that would also work. In D both long and int have a fixed size, therefore should all three ways work.
Jan 25 2009
next sibling parent Jacob Carlborg <doobnet gmail.com> writes:
Jacob Carlborg wrote:
 Frits van Bommel wrote:
 Jacob Carlborg wrote:
 Could we get a LP64 version identifier? I know that you can use this 
 code:

 "static if ((void*).sizeof > int.sizeof)"
Shouldn't that be "static if ((void*).sizeof == long.sizeof)" or just "static if ((void*).sizeof == 8)"? (Note that in D long.sizeof is guaranteed to be 8)
Yeah that would also work. In D both long and int have a fixed size, therefore should all three ways work.
Actually I now saw that D already has a D_LP64 version identifier.
Jan 25 2009
prev sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Jacob Carlborg wrote:
 Frits van Bommel wrote:
 Jacob Carlborg wrote:
 Could we get a LP64 version identifier? I know that you can use this 
 code:

 "static if ((void*).sizeof > int.sizeof)"
Shouldn't that be "static if ((void*).sizeof == long.sizeof)" or just "static if ((void*).sizeof == 8)"? (Note that in D long.sizeof is guaranteed to be 8)
Yeah that would also work. In D both long and int have a fixed size, therefore should all three ways work.
Nitpicking now: There could be a platform with 5-7 byte pointers[1], or
 8-byte pointers, so "> int.sizeof" != "== long.sizeof".
[1]: Hey, x86 technically has 6-byte pointers if you count segments as part of the pointer (which would be mostly useless on currently popular operating systems though).
Jan 26 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Frits van Bommel wrote:
 [1]: Hey, x86 technically has 6-byte pointers if you count segments as 
 part of the pointer (which would be mostly useless on currently popular 
 operating systems though).
It does, but I know of no compiler that supports that (C, C++, or any other), and code that needs to deal with that tends to be assembler.
Jan 26 2009
next sibling parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Walter Bright wrote:
 Frits van Bommel wrote:
 [1]: Hey, x86 technically has 6-byte pointers if you count segments as 
 part of the pointer (which would be mostly useless on currently 
 popular operating systems though).
It does, but I know of no compiler that supports that (C, C++, or any other), and code that needs to deal with that tends to be assembler.
I never said they were very useful to treat as such. I was just making conversation :P. Segment registers are still used though, in very special cases: - TLS via fs/gs:<ptr> is probably the only case most programmers will ever see in their compiled code, since this is probably the only case ever generated by any 32+ bit compilers directly from a high-level language (i.e. unless an (inline) assembler is used). - The VESA (v3) protected mode interface[1] involves calling 16-bit protected-mode code located in the BIOS. It requires a data table to be set with some 16-bit protected mode segments pointing to BIOS and video memory before calling it. Also, calling the 16-bit code in itself requires setting segment registers to 16-bit segments. These are only 32-bit total though, since it uses only 16 bits for the pointer values. Still, this is used from 32-bit code. - OS kernels use different segments than user-level code because of protection flags (and in case of x86-64, yet others to run 32-bit user-level programs). These tend to overlap each other though, having the same data at each accessible address. [1] This allows writing a "generic" driver for a large variety of video cards that supports more resolutions than VGA. IIRC x86-64 doesn't allow 16-bit protected mode anymore once you're in 64-bit mode, but for 32-bit x86 at least this is rather nice.
Jan 27 2009
prev sibling parent reply "Joel C. Salomon" <joelcsalomon gmail.com> writes:
Walter Bright wrote:
 Frits van Bommel wrote:
 [1]: Hey, x86 technically has 6-byte pointers if you count segments as=
=20
 part of the pointer (which would be mostly useless on currently=20
 popular operating systems though).
=20 It does, but I know of no compiler that supports that (C, C++, or any=20 other), and code that needs to deal with that tends to be assembler.
Shouldn=E2=80=99t most (ancient) 16-bit x86 compilers have support for =E2= =80=9Cnear=E2=80=9D=20 and =E2=80=9Cfar=E2=80=9D pointers? Seems this should just require some u= pdating of that=20 concept. =E2=80=94Joel Salomon
Jan 27 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Joel C. Salomon wrote:
 Walter Bright wrote:
 Frits van Bommel wrote:
 [1]: Hey, x86 technically has 6-byte pointers if you count segments 
 as part of the pointer (which would be mostly useless on currently 
 popular operating systems though).
It does, but I know of no compiler that supports that (C, C++, or any other), and code that needs to deal with that tends to be assembler.
Shouldn’t most (ancient) 16-bit x86 compilers have support for “near” and “far” pointers? Seems this should just require some updating of that concept.
The 16 bit compilers (like Digital Mars C++ for DOS) do have such support. Just not the 32 bit ones (which the 6 byte pointers would be). It could be added to DMC for 32 bits, but there is no point to it because there's no demand for it. DMC++ still supports 16 bit targets, but frankly, about 1 person a year gets it for that purpose. 16 bits is dead, dead, dead.
Jan 27 2009
parent reply "Peter C. Chapin" <pcc482719 gmail.com> writes:
Walter Bright wrote:

 The 16 bit compilers (like Digital Mars C++ for DOS) do have such
 support. Just not the 32 bit ones (which the 6 byte pointers would be).
 It could be added to DMC for 32 bits, but there is no point to it
 because there's no demand for it.
FWIW, Open Watcom supports far (48 bit) pointers in 32 bit code. However, since the feature sees almost no use it is probably buggy.
 DMC++ still supports 16 bit targets, but frankly, about 1 person a year
 gets it for that purpose. 16 bits is dead, dead, dead.
There is a community of 16 bit DOS users out there. Some of those folks are using 16 bit x86 devices in small embedded systems. It's a small community to be sure, but not zero sized. Peter
Jan 29 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Peter C. Chapin wrote:
 There is a community of 16 bit DOS users out there. Some of those folks
 are using 16 bit x86 devices in small embedded systems. It's a small
 community to be sure, but not zero sized.
Back in the bad old DOS days, the 8 bit CPM computers suffered a similar fate. The CPM programmers were a bit upset that their computers, software, expertise, was no longer wanted. They were also upset that their dev tools were no longer being developed, but understood that was because none of the CPM programmers wanted to pay any money for them. All the software for CPM had reverted to free and essentially abandoned.
Feb 07 2009
prev sibling next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Sun, 25 Jan 2009 15:32:33 +0300, Jacob Carlborg <doobnet gmail.com> wrote:

 Could we get a LP64 version identifier? I know that you can use this  
 code:

 "static if ((void*).sizeof > int.sizeof)"

 to do the same but that's not particular clear that the programmer wants  
 to check for LP64. If so, I hope we could get it in D1 also.
version (X86) { ... } else { ... }
Jan 25 2009
parent reply Jacob Carlborg <doobnet gmail.com> writes:
Denis Koroskin wrote:
 On Sun, 25 Jan 2009 15:32:33 +0300, Jacob Carlborg <doobnet gmail.com> 
 wrote:
 
 Could we get a LP64 version identifier? I know that you can use this 
 code:

 "static if ((void*).sizeof > int.sizeof)"

 to do the same but that's not particular clear that the programmer 
 wants to check for LP64. If so, I hope we could get it in D1 also.
version (X86) { ... } else { ... }
Win64 and all non X86 32bit versions would fall in the else statement. Actually I now saw that D already has a D_LP64 version identifier.
Jan 25 2009
parent "Denis Koroskin" <2korden gmail.com> writes:
On Sun, 25 Jan 2009 17:30:38 +0300, Jacob Carlborg <doobnet gmail.com> wrote:

 Denis Koroskin wrote:
 On Sun, 25 Jan 2009 15:32:33 +0300, Jacob Carlborg <doobnet gmail.com>  
 wrote:

 Could we get a LP64 version identifier? I know that you can use this  
 code:

 "static if ((void*).sizeof > int.sizeof)"

 to do the same but that's not particular clear that the programmer  
 wants to check for LP64. If so, I hope we could get it in D1 also.
version (X86) { ... } else { ... }
Win64 and all non X86 32bit versions would fall in the else statement. Actually I now saw that D already has a D_LP64 version identifier.
Hm.. you are right.
Jan 25 2009
prev sibling next sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Sun, 25 Jan 2009 15:32:33 +0300, Jacob Carlborg <doobnet gmail.com> wrote:

 Could we get a LP64 version identifier? I know that you can use this  
 code:

 "static if ((void*).sizeof > int.sizeof)"

 to do the same but that's not particular clear that the programmer wants  
 to check for LP64. If so, I hope we could get it in D1 also.
http://www.digitalmars.com/d/2.0/version.html D_LP64 - Pointers are 64 bits
Jan 25 2009
parent Jacob Carlborg <doobnet gmail.com> writes:
Denis Koroskin wrote:
 On Sun, 25 Jan 2009 15:32:33 +0300, Jacob Carlborg <doobnet gmail.com> 
 wrote:
 
 Could we get a LP64 version identifier? I know that you can use this 
 code:

 "static if ((void*).sizeof > int.sizeof)"

 to do the same but that's not particular clear that the programmer 
 wants to check for LP64. If so, I hope we could get it in D1 also.
http://www.digitalmars.com/d/2.0/version.html D_LP64 - Pointers are 64 bits
It's also in D1: http://www.digitalmars.com/d/1.0/version.html
Jan 25 2009
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jacob Carlborg wrote:
 Could we get a LP64 version identifier? I know that you can use this code:
 
 "static if ((void*).sizeof > int.sizeof)"
 
 to do the same but that's not particular clear that the programmer wants 
 to check for LP64. If so, I hope we could get it in D1 also.
Yeah, I agree, and it's already in both for the next update. It'll be D_LP64.
Jan 25 2009
parent reply Jacob Carlborg <doobnet gmail.com> writes:
Walter Bright wrote:
 Jacob Carlborg wrote:
 Could we get a LP64 version identifier? I know that you can use this 
 code:

 "static if ((void*).sizeof > int.sizeof)"

 to do the same but that's not particular clear that the programmer 
 wants to check for LP64. If so, I hope we could get it in D1 also.
Yeah, I agree, and it's already in both for the next update. It'll be D_LP64.
Are you saying that D_LP64 isn't implemented in the current version? Because I noticed that it was already listed in the documentation: http://www.digitalmars.com/d/1.0/version.html When I tried to set the D_LP64 version with GDC it said: "Error: version identifier 'D_LP64' is reserved and cannot be set" and GDC is quite old now. But perhaps it's only reserved and not implemented yet.
Jan 26 2009
next sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Jacob Carlborg wrote:
 Walter Bright wrote:
 Jacob Carlborg wrote:
 Could we get a LP64 version identifier? I know that you can use this 
 code:

 "static if ((void*).sizeof > int.sizeof)"

 to do the same but that's not particular clear that the programmer 
 wants to check for LP64. If so, I hope we could get it in D1 also.
Yeah, I agree, and it's already in both for the next update. It'll be D_LP64.
Are you saying that D_LP64 isn't implemented in the current version? Because I noticed that it was already listed in the documentation: http://www.digitalmars.com/d/1.0/version.html When I tried to set the D_LP64 version with GDC it said: "Error: version identifier 'D_LP64' is reserved and cannot be set" and GDC is quite old now. But perhaps it's only reserved and not implemented yet.
I just tried it. D_LP64 isn't set on my GDC, yet (void*).sizeof is 8. So it doesn't work yet. Some testing shows that all DMD-frontend based compilers (i.e. DMD, GDC and LDC) seem to produce that error message for any version identifier starting with "D_" (Including "D_" itself).
Jan 26 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Frits van Bommel wrote:
 Some testing shows that all DMD-frontend based compilers (i.e. DMD, GDC 
 and LDC) seem to produce that error message for any version identifier 
 starting with "D_" (Including "D_" itself).
The point of that is to ensure that the D_ name space is reserved for predefined version identifiers. This check is done in VersionCondition::checkPredefined() in cond.c.
Jan 26 2009
next sibling parent Jacob Carlborg <doobnet gmail.com> writes:
Walter Bright wrote:
 Frits van Bommel wrote:
 Some testing shows that all DMD-frontend based compilers (i.e. DMD, 
 GDC and LDC) seem to produce that error message for any version 
 identifier starting with "D_" (Including "D_" itself).
The point of that is to ensure that the D_ name space is reserved for predefined version identifiers. This check is done in VersionCondition::checkPredefined() in cond.c.
Ok thanks.
Jan 27 2009
prev sibling parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Walter Bright wrote:
 Frits van Bommel wrote:
 Some testing shows that all DMD-frontend based compilers (i.e. DMD, 
 GDC and LDC) seem to produce that error message for any version 
 identifier starting with "D_" (Including "D_" itself).
The point of that is to ensure that the D_ name space is reserved for predefined version identifiers. This check is done in VersionCondition::checkPredefined() in cond.c.
I figured as much, and probably should have mentioned that for clarification.
Jan 27 2009
prev sibling parent reply Jacob Carlborg <doobnet gmail.com> writes:
Frits van Bommel wrote:
 Jacob Carlborg wrote:
 Walter Bright wrote:
 Jacob Carlborg wrote:
 Could we get a LP64 version identifier? I know that you can use this 
 code:

 "static if ((void*).sizeof > int.sizeof)"

 to do the same but that's not particular clear that the programmer 
 wants to check for LP64. If so, I hope we could get it in D1 also.
Yeah, I agree, and it's already in both for the next update. It'll be D_LP64.
Are you saying that D_LP64 isn't implemented in the current version? Because I noticed that it was already listed in the documentation: http://www.digitalmars.com/d/1.0/version.html When I tried to set the D_LP64 version with GDC it said: "Error: version identifier 'D_LP64' is reserved and cannot be set" and GDC is quite old now. But perhaps it's only reserved and not implemented yet.
I just tried it. D_LP64 isn't set on my GDC, yet (void*).sizeof is 8. So it doesn't work yet. Some testing shows that all DMD-frontend based compilers (i.e. DMD, GDC and LDC) seem to produce that error message for any version identifier starting with "D_" (Including "D_" itself).
Ok thanks. I guess I still have to use "static if"
Jan 27 2009
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Jacob Carlborg wrote:
 Frits van Bommel wrote:
 Jacob Carlborg wrote:
 Walter Bright wrote:
 Jacob Carlborg wrote:
 Could we get a LP64 version identifier? I know that you can use
 this code:

 "static if ((void*).sizeof > int.sizeof)"

 to do the same but that's not particular clear that the programmer
 wants to check for LP64. If so, I hope we could get it in D1 also.
[snip]
Some testing shows that all DMD-frontend based compilers (i.e. DMD, GDC and LDC) seem to produce that error message for any version identifier starting with "D_" (Including "D_" itself).
Ok thanks. I guess I still have to use "static if"
Or, do this: module platform; // Or call it whatever enum { HAS_LP64 = ((void*).sizeof > int.sizeof) } Then, in your source: import platform : HAS_LP64; static if( HAS_LP64 ) { ... } I've done this a few times when I had several traits that I wanted to compile against, and didn't want to have the tests all over the place. -- Daniel
Jan 27 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Jacob Carlborg wrote:
 Are you saying that D_LP64 isn't implemented in the current version? 
 Because I noticed that it was already listed in the documentation: 
 http://www.digitalmars.com/d/1.0/version.html
 When I tried to set the D_LP64 version with GDC it said: "Error: version 
 identifier 'D_LP64' is reserved and cannot be set" and GDC is quite old 
 now. But perhaps it's only reserved and not implemented yet.
I forgot that it was already in <g>.
Jan 26 2009
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:
 Frits van Bommel:
 [1]: Hey, x86 technically has 6-byte pointers if you count segments as 
 part of the pointer (which would be mostly useless on currently popular 
 operating systems though).
It does, but I know of no compiler that supports that (C, C++, or any other), and code that needs to deal with that tends to be assembler.
16 free bits suggest various possible usages, for example the length for small strings/arrays, halving the size of the array struct. Bye, bearophile
Jan 27 2009
next sibling parent Don <nospam nospam.com> writes:
bearophile wrote:
 Walter Bright:
 Frits van Bommel:
 [1]: Hey, x86 technically has 6-byte pointers if you count segments as 
 part of the pointer (which would be mostly useless on currently popular 
 operating systems though).
It does, but I know of no compiler that supports that (C, C++, or any other), and code that needs to deal with that tends to be assembler.
16 free bits suggest various possible usages, for example the length for small strings/arrays, halving the size of the array struct. Bye, bearophile
They're not free bits. Those bits are in the segment registers, not in the pointer registers. Only the OS can change the segment registers. And it's a slow operation.
Jan 27 2009
prev sibling parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
bearophile wrote:
 Walter Bright:
 Frits van Bommel:
 [1]: Hey, x86 technically has 6-byte pointers if you count segments as 
 part of the pointer (which would be mostly useless on currently popular 
 operating systems though).
It does, but I know of no compiler that supports that (C, C++, or any other), and code that needs to deal with that tends to be assembler.
16 free bits suggest various possible usages, for example the length for small strings/arrays, halving the size of the array struct.
It's not that there are 16 extra bits available, it's that technically to specify a memory location you need to specify 16 more bits in one of a couple special registers. In practice though, these are pretty much always the same (or equivalent, at least).
Jan 27 2009