I started implementing all the CPU based version symbols shown on http://dlang.org/version.html for GDC (https://gist.github.com/4647493), but I found some things to be strange:

Floating point:
* Why do we have PPC_SoftFP but MIPS_SoftFloat? I'd say we should use
  *_SoftFloat everywhere for consistency. (Except for arm where
  SoftFP has a different meaning)
* Do we need the arch specific SoftFloat/HardFloat if a target only has
  those two? Why PPC_SoftFP and PPC_HardFP, doesn't
  version(PPC){version(D_SoftFloat) else version(D_HardFloat)} work?
* Even for ARM, which has a third mode, we could get rid of
  ARM_Soft and ARM_HardFP, keeping only ARM_SoftFP. Then you can do
  this:

version(ARM)
{
    version(D_SoftFloat)
    {//ARM_SoftFloat
    }
    else version(D_HardFloat)
    {
        version(ARM_SoftFP){}//ARM_SoftFP, special case of D_HardFloat
        else {}//ARM_HardFP
    }
    else
    {//NoFloat
    }
}

* Why do we have MIPS_NoFloat? This can be replaced by
  version(D_SoftFloat) else version(D_HardFloat) else()
  (looks a little ugly, but a convenience version can be defined in user
  code)

* Why do we have MIPS32? No other architecture has a 32 version?


Questions:
* D_LP64 docs say it means 64bit pointers. GDC currently checks for
  "INT_SIZE == 32 && LONG_INT_SIZE == 64 && POINTER_SIZE == 64" which
  matches the C definition of LP64. This would not match ILP64/SILP64
  for example, so what is D_LP64 supposed to mean?

* ARM64 always has a FPU. I guess it should not set any of the
  ARM_*Float versions?

* Are D_X32 and X86_64 exclusive or does a X32 system define both?

* What about an ARM_Thumb2 version?

* Does Cygwin also define Windows, Win32, Win64? Posix?

Minor doc problems:
ARM: the docs should say AArch32 not AArch32:A32, that's my fault, I'll
file a pull request.
ARM64: AArch64 instead of AArch64:A64

On 2013-01-27 10:42, Johannes Pfau wrote:

> Questions:
> * D_LP64 docs say it means 64bit pointers. GDC currently checks for
>    "INT_SIZE == 32 && LONG_INT_SIZE == 64 && POINTER_SIZE == 64" which
>    matches the C definition of LP64. This would not match ILP64/SILP64
>    for example, so what is D_LP64 supposed to mean?	

Looking at the source code, by default LP64 is set if sizeof(size_t) == 8. The the -m32/64 flags can override this.

On Windows that name is kind of misleading. On Windows the correct data models seems to be LLP64.

http://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models

-- 
/Jacob Carlborg

On 27-01-2013 10:42, Johannes Pfau wrote:
> I started implementing all the CPU based version symbols shown on
> http://dlang.org/version.html for GDC
> (https://gist.github.com/4647493), but I found some things to be
> strange:
>
> Floating point:
> * Why do we have PPC_SoftFP but MIPS_SoftFloat? I'd say we should use
>    *_SoftFloat everywhere for consistency. (Except for arm where
>    SoftFP has a different meaning)

Yes. Please send a pull request.

> * Do we need the arch specific SoftFloat/HardFloat if a target only has
>    those two? Why PPC_SoftFP and PPC_HardFP, doesn't
>    version(PPC){version(D_SoftFloat) else version(D_HardFloat)} work?

The intention was that the arch-specific ones should be used to make ABI and architecture-specific decisions while the D_* ones should be used as a general flag indicating whether an FPU exists at all.

> * Even for ARM, which has a third mode, we could get rid of
>    ARM_Soft and ARM_HardFP, keeping only ARM_SoftFP. Then you can do
>    this:
>
> version(ARM)
> {
>      version(D_SoftFloat)
>      {//ARM_SoftFloat
>      }
>      else version(D_HardFloat)
>      {
>          version(ARM_SoftFP){}//ARM_SoftFP, special case of D_HardFloat
>          else {}//ARM_HardFP
>      }
>      else
>      {//NoFloat
>      }
> }

I think that makes it more confusing.

>
> * Why do we have MIPS_NoFloat? This can be replaced by
>    version(D_SoftFloat) else version(D_HardFloat) else()
>    (looks a little ugly, but a convenience version can be defined in user
>    code)

I am guessing MIPS_NoFloat is for targets where not even soft float exists. But we don't actually support such targets, so this should probably be removed.

Martin, thoughts on this?

>
> * Why do we have MIPS32? No other architecture has a 32 version?

We discussed that here: https://github.com/D-Programming-Language/d-programming-language.org/pull/207#discussion_r2358525

>
>
> Questions:
> * D_LP64 docs say it means 64bit pointers. GDC currently checks for
>    "INT_SIZE == 32 && LONG_INT_SIZE == 64 && POINTER_SIZE == 64" which
>    matches the C definition of LP64. This would not match ILP64/SILP64
>    for example, so what is D_LP64 supposed to mean?	

D is specifically designed to not care about targets where word size != pointer size. That is, size_t.sizeof must == (void*).sizeof. It can probably work on such targets, though, so long as D_LP64 is only set when both of those are 64.

Why the check for INT_SIZE? Isn't it always 16 or 32 in GCC (never 64)?

>
> * ARM64 always has a FPU. I guess it should not set any of the
>    ARM_*Float versions?

I think for convenience and least surprise, we should still set ARM_HardFP.

>
> * Are D_X32 and X86_64 exclusive or does a X32 system define both?

D_X32 is a data model (like D_LP64) so it can be defined alongside X86_64.

>
> * What about an ARM_Thumb2 version?

Are Thumb1 systems still relevant today? I'm not too familiar with Thumb, so forgive my ignorance here. If we still do need to care about Thumb1, then OK.

>
> * Does Cygwin also define Windows, Win32, Win64? Posix?

I don't think anyone has ported a D compiler to Cygwin, so who knows...

I'd certainly expect it to define the first 3, but not sure about the last one... Probably not, though, as a lot of D code assumes Windows and Posix are mutually exclusive.

>
> Minor doc problems:
> ARM: the docs should say AArch32 not AArch32:A32, that's my fault, I'll
> file a pull request.
> ARM64: AArch64 instead of AArch64:A64
>

OK.

-- 
Alex Rønne Petersen
alex@alexrp.com / alex@lycus.org
http://lycus.org

On 27 Jan 2013 15:26, "Alex Rønne Petersen" <alex@lycus.org> wrote:
>
> On 27-01-2013 10:42, Johannes Pfau wrote:
>>
>> I started implementing all the CPU based version symbols shown on http://dlang.org/version.html for GDC (https://gist.github.com/4647493), but I found some things to be strange:
>>
>> Floating point:
>> * Why do we have PPC_SoftFP but MIPS_SoftFloat? I'd say we should use
>>    *_SoftFloat everywhere for consistency. (Except for arm where
>>    SoftFP has a different meaning)
>
>
> Yes. Please send a pull request.
>
>
>> * Do we need the arch specific SoftFloat/HardFloat if a target only has
>>    those two? Why PPC_SoftFP and PPC_HardFP, doesn't
>>    version(PPC){version(D_SoftFloat) else version(D_HardFloat)} work?
>
>
> The intention was that the arch-specific ones should be used to make ABI
and architecture-specific decisions while the D_* ones should be used as a general flag indicating whether an FPU exists at all.
>
>
>> * Even for ARM, which has a third mode, we could get rid of
>>    ARM_Soft and ARM_HardFP, keeping only ARM_SoftFP. Then you can do
>>    this:
>>
>> version(ARM)
>> {
>>      version(D_SoftFloat)
>>      {//ARM_SoftFloat
>>      }
>>      else version(D_HardFloat)
>>      {
>>          version(ARM_SoftFP){}//ARM_SoftFP, special case of D_HardFloat
>>          else {}//ARM_HardFP
>>      }
>>      else
>>      {//NoFloat
>>      }
>> }
>
>
> I think that makes it more confusing.
>
>
>>
>> * Why do we have MIPS_NoFloat? This can be replaced by
>>    version(D_SoftFloat) else version(D_HardFloat) else()
>>    (looks a little ugly, but a convenience version can be defined in user
>>    code)
>
>
> I am guessing MIPS_NoFloat is for targets where not even soft float
exists. But we don't actually support such targets, so this should probably be removed.
>
> Martin, thoughts on this?
>
>
>>
>> * Why do we have MIPS32? No other architecture has a 32 version?
>
>
> We discussed that here:
https://github.com/D-Programming-Language/d-programming-language.org/pull/207#discussion_r2358525
>
>
>>
>>
>> Questions:
>> * D_LP64 docs say it means 64bit pointers. GDC currently checks for
>>    "INT_SIZE == 32 && LONG_INT_SIZE == 64 && POINTER_SIZE == 64" which
>>    matches the C definition of LP64. This would not match ILP64/SILP64
>>    for example, so what is D_LP64 supposed to mean?
>
>
> D is specifically designed to not care about targets where word size !=
pointer size. That is, size_t.sizeof must == (void*).sizeof. It can probably work on such targets, though, so long as D_LP64 is only set when both of those are 64.
>

I see this as being a bug.

> Why the check for INT_SIZE? Isn't it always 16 or 32 in GCC (never 64)?
>
>

There are __ILP64__ targets out there...

For D, its only useful for C compatibilty, eg:

version(D_ILP64)
alias long c_int;

>>
>> * ARM64 always has a FPU. I guess it should not set any of the
>>    ARM_*Float versions?
>
>
> I think for convenience and least surprise, we should still set
ARM_HardFP.
>
>
>>
>> * Are D_X32 and X86_64 exclusive or does a X32 system define both?
>
>
> D_X32 is a data model (like D_LP64) so it can be defined alongside X86_64.
>
>
>>
>> * What about an ARM_Thumb2 version?
>
>
> Are Thumb1 systems still relevant today? I'm not too familiar with Thumb,
so forgive my ignorance here. If we still do need to care about Thumb1, then OK.
>
>

I seem to recall thumb being mostly 16bit systems.

>>
>> * Does Cygwin also define Windows, Win32, Win64? Posix?
>
>
> I don't think anyone has ported a D compiler to Cygwin, so who knows...
>
> I'd certainly expect it to define the first 3, but not sure about the
last one... Probably not, though, as a lot of D code assumes Windows and Posix are mutually exclusive.
>
>

It should define Posix and Windows. I wouldn't have thought Win32/Win64 to be required/is out of scope for the cygwin platform.

Regards
Iain

Am Sun, 27 Jan 2013 16:14:19 +0000
schrieb Iain Buclaw <ibuclaw@ubuntu.com>:

> >
> > Are Thumb1 systems still relevant today? I'm not too familiar with Thumb,
> so forgive my ignorance here. If we still do need to care about Thumb1, then OK.
> >
> >
> 
> I seem to recall thumb being mostly 16bit systems.

Really? AFAIK ARM has always been 32bit or more. Thumb only limits instruction size to 16bit, the registers are still 32bit.

Am Sun, 27 Jan 2013 16:20:58 +0100
schrieb Alex Rønne Petersen <alex@lycus.org>:

> 
> > * Do we need the arch specific SoftFloat/HardFloat if a target only
> > has those two? Why PPC_SoftFP and PPC_HardFP, doesn't
> >    version(PPC){version(D_SoftFloat) else version(D_HardFloat)}
> > work?
> 
> The intention was that the arch-specific ones should be used to make ABI and architecture-specific decisions while the D_* ones should be used as a general flag indicating whether an FPU exists at all.

OK I can live with that reasoning.

> 
> >
> > * Why do we have MIPS_NoFloat? This can be replaced by
> >    version(D_SoftFloat) else version(D_HardFloat) else()
> >    (looks a little ugly, but a convenience version can be defined
> > in user code)
> 
> I am guessing MIPS_NoFloat is for targets where not even soft float exists. But we don't actually support such targets, so this should probably be removed.
> 
> Martin, thoughts on this?

I don't think it's important whether we support NoFloat targets. But either way NoFloat is generic, so it should either be D_NoFloat or no NoFloat at all, I don't see a reason for architecture specific NoFloat.

Also NoFloat isn't necessary at all, as you can do:
version(D_SoftFloat)
else version(D_HardFloat)
else
   //NoFloat

> 
> >
> > * Why do we have MIPS32? No other architecture has a 32 version?
> 
> We discussed that here: https://github.com/D-Programming-Language/d-programming-language.org/pull/207#discussion_r2358525

I can understand that reasoning, but we should either have it for all architectures or for none. Having 32bit versions only for MIPS is inconsistent.

> >
> >
> > Questions:
> > * D_LP64 docs say it means 64bit pointers. GDC currently checks for
> >    "INT_SIZE == 32 && LONG_INT_SIZE == 64 && POINTER_SIZE == 64"
> > which matches the C definition of LP64. This would not match
> > ILP64/SILP64 for example, so what is D_LP64 supposed to
> > mean?
> 
> D is specifically designed to not care about targets where word size != pointer size. That is, size_t.sizeof must == (void*).sizeof.

Pointers and size_t can have equal sizes even on non LP64 systems, see this table: http://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models

> It can probably work on such targets, though, so long as D_LP64 is only set when both of those are 64.
> 
> Why the check for INT_SIZE? Isn't it always 16 or 32 in GCC (never
> 64)?

No, there are data models with INT_SIZE=64 and LP64 usually doesn't include those. See the wikipedia table.

But these data models are only important when interfacing with C, so I'd say make D_LP64 mean pointers are 64 bit (longpointer, 64bit).

For c_long, c_ulong, c_int, c_uint just add built in types gcc.builtins.__builtin_clong and make c_long an alias.

> 
> >
> > * ARM64 always has a FPU. I guess it should not set any of the
> >    ARM_*Float versions?
> 
> I think for convenience and least surprise, we should still set ARM_HardFP.
> 
I have no strong opinion here, but I'd prefer 'clear' behavior.


> 
> >
> > * What about an ARM_Thumb2 version?
> 
> Are Thumb1 systems still relevant today? I'm not too familiar with Thumb, so forgive my ignorance here. If we still do need to care about Thumb1, then OK.

We basically need it to detect non-thumb. As ARM is also set for thumb code you have to do this:

version(ARM)
{
    version(Thumb1)
    version(Thumb2)
    else //No Thumb
}

We could also make Thumb mean 'any' thumb.

On 27 January 2013 17:17, Johannes Pfau <nospam@example.com> wrote:

> Am Sun, 27 Jan 2013 16:14:19 +0000
> schrieb Iain Buclaw <ibuclaw@ubuntu.com>:
>
> > >
> > > Are Thumb1 systems still relevant today? I'm not too familiar with Thumb,
> > so forgive my ignorance here. If we still do need to care about Thumb1, then OK.
> > >
> > >
> >
> > I seem to recall thumb being mostly 16bit systems.
>
> Really? AFAIK ARM has always been 32bit or more. Thumb only limits instruction size to 16bit, the registers are still 32bit.
>


Learn something new every day. :)

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';