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.

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).

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).

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>.

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.

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.

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.

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"

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

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.