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