https://issues.dlang.org/show_bug.cgi?id=24412

Dennis <dkorpel@live.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dkorpel@live.nl

--- Comment #1 from Dennis <dkorpel@live.nl> ---
The usual check for this is `static if (size_t.sizeof == 8)`.

--

https://issues.dlang.org/show_bug.cgi?id=24412

--- Comment #2 from Manu <turkeyman@gmail.com> ---
That would tell you if you have 64bit address space. Not the same thing.

--

https://issues.dlang.org/show_bug.cgi?id=24412

--- Comment #3 from Dennis <dkorpel@live.nl> ---
It usually is, so people tend to use it that way. Are you programming for the Nintendo 64 perhaps? :)

I'm looking how other languages check for 64-bit registers, and in C, it seems like people also query sizes of pointer / integer types, or query a specific ISA (like x86-64): https://stackoverflow.com/a/33867847/8411666

So without precedence, the name could be something like 'D_64bitRegister' or 'D_64bitArithmetic'. But what do you want to do with this information exactly? Is this to provide your own alternative 64-bit emulation when there's no 'native' 64-bit math?

Because that could be tricky: consider WebAssembly without wasm64. It has 32-bit pointers and 64-bit math instructions, but it's not an actual processor architecture: the speed depends on the execution environment, so would 'D_64bitRegister' be set in that case?

--

https://issues.dlang.org/show_bug.cgi?id=24412

--- Comment #4 from Manu <turkeyman@gmail.com> ---
> It usually is, so people tend to use it that way.

But it's not actually the same thing, and people using it that way have likely written a bug...

> Are you programming for the Nintendo 64 perhaps? :)

I do have a lifetime of experience writing software for such 64bit systems with 32bit pointers. They are a real thing that exists.

> [...] or query a specific ISA [...]

Yes, in C++ we wrangle this information ourselves from whatever material the compiler makes available to determine the facts. Everyone has such a global header file that does this wrangling. I'm specifically looking to avoid that here.

> Is this to provide your own alternative 64-bit emulation when there's no 'native' 64-bit math?

Exactly; if there are no 64bit registers, it can be the case that some alternative algorithm is superior. There do exist algorithms that only work efficiently with 64bits.

> [...] consider WebAssembly without wasm64 [...] would 'D_64bitRegister' be set in that case?

Maybe not define it for webasm since 32bit machines can run web browsers too. I
mean, you're running in a web browser; your concern about maximising
architectural perf is already forfeit.
It's difficult to imagine a case where this could be used where it's a
compatibility issue; it's basically for optimisation opportunities, and nothing
else.

--

https://issues.dlang.org/show_bug.cgi?id=24412

--- Comment #5 from Dennis <dkorpel@live.nl> ---
> It's difficult to imagine a case where this could be used where it's a compatibility issue; it's basically for optimisation opportunities, and nothing else.

Since versions are usually about compatibility (i.e. `version(HasFeatureX)
useFeatureX()`), perhaps it would be better to define a 'fast int' type in
druntime, somewhat similar to C's `int_fast32_t` or `intmax_t`, but one that
represents the largest integer type with native math instructions (excluding
SIMD). That would also generalize better to 16 and 128 bit. Would that work?

--

https://issues.dlang.org/show_bug.cgi?id=24412

--- Comment #6 from Manu <turkeyman@gmail.com> ---
I think that's over-complicating it. Version is fine.

--

https://issues.dlang.org/show_bug.cgi?id=24412

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com

--- Comment #7 from Walter Bright <bugzilla@digitalmars.com> ---
https://dlang.org/spec/version.html

Says:

```
    D_LP64      Pointers are 64 bits (command line switch -m64). (Do not
confuse this with C's LP64 model)
    D_X32       Pointers are 32 bits, but words are still 64 bits (x32 ABI)
(This can be defined in parallel to X86_64)
```

What the implementation actually does is:

```
    if (tgt.isX86_64)
    {
        VersionCondition.addPredefinedGlobalIdent("D_InlineAsm_X86_64");
        VersionCondition.addPredefinedGlobalIdent("X86_64");
    }
    else
    {
        VersionCondition.addPredefinedGlobalIdent("D_InlineAsm"); //legacy
        VersionCondition.addPredefinedGlobalIdent("D_InlineAsm_X86");
        VersionCondition.addPredefinedGlobalIdent("X86");
    }
    if (tgt.isLP64)
        VersionCondition.addPredefinedGlobalIdent("D_LP64");
    else if (tgt.isX86_64)
        VersionCondition.addPredefinedGlobalIdent("X32");
```

Note how something simple turned into a monstrosity that nobody can figure out, and the documentation is both wrong and incomplete. Sigh.

I suspect that the undocumented X32 is what Manu is looking for, but dmd never generates it. Does gdc or ldc?

--

https://issues.dlang.org/show_bug.cgi?id=24412

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ibuclaw@gdcproject.org

--- Comment #8 from Iain Buclaw <ibuclaw@gdcproject.org> ---
(In reply to Dennis from comment #1)
> The usual check for this is `static if (size_t.sizeof == 8)`.

`version(D_LP64)` would be a better alternative to that.

--

https://issues.dlang.org/show_bug.cgi?id=24412

--- Comment #9 from Iain Buclaw <ibuclaw@gdcproject.org> ---
(In reply to Walter Bright from comment #7)
> https://dlang.org/spec/version.html
> 
> Says:
> 
> ```
>     D_LP64	Pointers are 64 bits (command line switch -m64). (Do not confuse
> this with C's LP64 model)
>     D_X32	Pointers are 32 bits, but words are still 64 bits (x32 ABI) (This
> can be defined in parallel to X86_64)
> ```
Introduced by https://github.com/dlang/dlang.org/pull/175

As one comment pointed out:
"""
X32 is a specific implementation for x86-64 hardware, but the description
refers to an abstract concept
"""

Adding "x32 ABI" was the compromise, but I don't think it's explicit enough.

Pick any wiki, and the description is better:
"""
X32 is an alternative ABI for x86-64 that uses the full 64-bit x86-64
instruction and register set and 32-bit pointers and longs.
"""
https://sourceware.org/glibc/wiki/x32

"""
The x32 ABI provides 32-bit integers, long and pointers (ILP32) on Intel and
AMD 64-bit hardware
"""
https://en.wikipedia.org/wiki/X32_ABI

> Note how something simple turned into a monstrosity that nobody can figure out, and the documentation is both wrong and incomplete. Sigh.
> 
> I suspect that the undocumented X32 is what Manu is looking for, but dmd never generates it. Does gdc or ldc?
That is a typo in dmd, introduced by https://github.com/dlang/dmd/pull/12508

D_X32 is predefined by gdc on X32 targets, itself is now a deprecated ABI of X86_64.  I had and still have doubts that DMD would support such a `-target` anyway.

A more informative version identifier for it would have been X86_64_X32, but this was added at a time where brevity was preferred over clarity for some reason. Which also left in the spec D_AVX and D_AVX2 (yuck!) instead of X86_64_AVX and X86_64_AVX2.

--

https://issues.dlang.org/show_bug.cgi?id=24412

--- Comment #10 from Iain Buclaw <ibuclaw@gdcproject.org> ---
(In reply to Manu from comment #2)
> That would tell you if you have 64bit address space. Not the same thing.
```
import gcc.builtins : ___builtin_machine_int;
static if (__builtin_machine_int.sizeof == 8):
```

--