digitalmars.D - Could we get a LP64 version identifier?
- Jacob Carlborg (4/4) Jan 25 2009 Could we get a LP64 version identifier? I know that you can use this cod...
- Frits van Bommel (4/9) Jan 25 2009 Shouldn't that be "static if ((void*).sizeof == long.sizeof)" or just
- Jacob Carlborg (3/12) Jan 25 2009 Yeah that would also work. In D both long and int have a fixed size,
- Jacob Carlborg (2/15) Jan 25 2009 Actually I now saw that D already has a D_LP64 version identifier.
- Frits van Bommel (5/19) Jan 26 2009 [1]: Hey, x86 technically has 6-byte pointers if you count segments as
- Walter Bright (3/6) Jan 26 2009 It does, but I know of no compiler that supports that (C, C++, or any
- Frits van Bommel (23/30) Jan 27 2009 I never said they were very useful to treat as such. I was just making
- Joel C. Salomon (8/15) Jan 27 2009 Shouldn=E2=80=99t most (ancient) 16-bit x86 compilers have support for =...
- Walter Bright (7/19) Jan 27 2009 The 16 bit compilers (like Digital Mars C++ for DOS) do have such
- Peter C. Chapin (7/13) Jan 29 2009 FWIW, Open Watcom supports far (48 bit) pointers in 32 bit code.
- Walter Bright (7/10) Feb 07 2009 Back in the bad old DOS days, the 8 bit CPM computers suffered a similar...
- Denis Koroskin (6/11) Jan 25 2009 version (X86) {
- Jacob Carlborg (3/20) Jan 25 2009 Win64 and all non X86 32bit versions would fall in the else statement.
- Denis Koroskin (2/21) Jan 25 2009 Hm.. you are right.
- Denis Koroskin (3/8) Jan 25 2009 http://www.digitalmars.com/d/2.0/version.html
- Jacob Carlborg (2/17) Jan 25 2009 It's also in D1: http://www.digitalmars.com/d/1.0/version.html
- Walter Bright (3/9) Jan 25 2009 Yeah, I agree, and it's already in both for the next update. It'll be
- Jacob Carlborg (7/18) Jan 26 2009 Are you saying that D_LP64 isn't implemented in the current version?
- Frits van Bommel (6/25) Jan 26 2009 I just tried it. D_LP64 isn't set on my GDC, yet (void*).sizeof is 8.
- Walter Bright (4/7) Jan 26 2009 The point of that is to ensure that the D_ name space is reserved for
- Jacob Carlborg (2/10) Jan 27 2009 Ok thanks.
- Frits van Bommel (3/11) Jan 27 2009 I figured as much, and probably should have mentioned that for
- Jacob Carlborg (2/29) Jan 27 2009 Ok thanks. I guess I still have to use "static if"
- Daniel Keep (16/35) Jan 27 2009 Or, do this:
-
Walter Bright
(2/8)
Jan 26 2009
I forgot that it was already in
. - bearophile (4/11) Jan 27 2009 16 free bits suggest various possible usages, for example the length for...
- Don (4/16) Jan 27 2009 They're not free bits. Those bits are in the segment registers, not in
- Frits van Bommel (5/14) Jan 27 2009 It's not that there are 16 extra bits available, it's that technically
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
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
Frits van Bommel wrote:Jacob Carlborg wrote:Yeah that would also work. In D both long and int have a fixed size, therefore should all three ways work.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)
Jan 25 2009
Jacob Carlborg <doobnet gmail.com> Jacob Carlborg wrote:Frits van Bommel wrote:Actually I now saw that D already has a D_LP64 version identifier.Jacob Carlborg wrote:Yeah that would also work. In D both long and int have a fixed size, therefore should all three ways work.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)
Jan 25 2009
Jacob Carlborg wrote:Frits van Bommel wrote:Nitpicking now: There could be a platform with 5-7 byte pointers[1], orJacob Carlborg wrote:Yeah that would also work. In D both long and int have a fixed size, therefore should all three ways work.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)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
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
Walter Bright wrote:Frits van Bommel wrote: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.[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 27 2009
Walter Bright wrote:Frits van Bommel wrote:=20[1]: Hey, x86 technically has 6-byte pointers if you count segments as=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 Salomonpart 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.
Jan 27 2009
Joel C. Salomon wrote: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. DMC++ still supports 16 bit targets, but frankly, about 1 person a year gets it for that purpose. 16 bits is dead, dead, dead.Frits van Bommel wrote: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.[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 27 2009
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
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
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
Denis Koroskin wrote:On Sun, 25 Jan 2009 15:32:33 +0300, Jacob Carlborg <doobnet gmail.com> wrote: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.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
On Sun, 25 Jan 2009 17:30:38 +0300, Jacob Carlborg <doobnet gmail.com> wrote:Denis Koroskin wrote:Hm.. you are right.On Sun, 25 Jan 2009 15:32:33 +0300, Jacob Carlborg <doobnet gmail.com> wrote: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.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
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
Denis Koroskin wrote:On Sun, 25 Jan 2009 15:32:33 +0300, Jacob Carlborg <doobnet gmail.com> wrote:It's also in D1: http://www.digitalmars.com/d/1.0/version.htmlCould 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
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
Walter Bright wrote: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.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 26 2009
Jacob Carlborg wrote:Walter Bright wrote: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).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.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 26 2009
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
Walter Bright wrote:Frits van Bommel wrote:Ok thanks.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 27 2009
Walter Bright wrote:Frits van Bommel wrote:I figured as much, and probably should have mentioned that for clarification.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 27 2009
Frits van Bommel wrote:Jacob Carlborg wrote:Ok thanks. I guess I still have to use "static if"Walter Bright wrote: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).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.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 27 2009
Jacob Carlborg wrote:Frits van Bommel wrote: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. -- DanielJacob Carlborg wrote:Ok thanks. I guess I still have to use "static if"Walter Bright 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).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]
Jan 27 2009
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
Walter Bright:Frits van Bommel:16 free bits suggest various possible usages, for example the length for small strings/arrays, halving the size of the array struct. Bye, bearophile[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 27 2009
bearophile wrote:Walter Bright: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.Frits van Bommel:16 free bits suggest various possible usages, for example the length for small strings/arrays, halving the size of the array struct. Bye, bearophile[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 27 2009
bearophile wrote:Walter Bright: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).Frits van Bommel:16 free bits suggest various possible usages, for example the length for small strings/arrays, halving the size of the array struct.[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 27 2009