<p>On 27 Jan 2013 15:26, "Alex Rønne Petersen" <<a href="mailto:alex@lycus.org">alex@lycus.org</a>> wrote:<br>
><br>
> On 27-01-2013 10:42, Johannes Pfau wrote:<br>
>><br>
>> I started implementing all the CPU based version symbols shown on<br>
>> <a href="http://dlang.org/version.html">http://dlang.org/version.html</a> for GDC<br>
>> (<a href="https://gist.github.com/4647493">https://gist.github.com/4647493</a>), but I found some things to be<br>
>> strange:<br>
>><br>
>> Floating point:<br>
>> * Why do we have PPC_SoftFP but MIPS_SoftFloat? I'd say we should use<br>
>>    *_SoftFloat everywhere for consistency. (Except for arm where<br>
>>    SoftFP has a different meaning)<br>
><br>
><br>
> Yes. Please send a pull request.<br>
><br>
><br>
>> * Do we need the arch specific SoftFloat/HardFloat if a target only has<br>
>>    those two? Why PPC_SoftFP and PPC_HardFP, doesn't<br>
>>    version(PPC){version(D_SoftFloat) else version(D_HardFloat)} work?<br>
><br>
><br>
> 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.<br>
><br>
><br>
>> * Even for ARM, which has a third mode, we could get rid of<br>
>>    ARM_Soft and ARM_HardFP, keeping only ARM_SoftFP. Then you can do<br>
>>    this:<br>
>><br>
>> version(ARM)<br>
>> {<br>
>>      version(D_SoftFloat)<br>
>>      {//ARM_SoftFloat<br>
>>      }<br>
>>      else version(D_HardFloat)<br>
>>      {<br>
>>          version(ARM_SoftFP){}//ARM_SoftFP, special case of D_HardFloat<br>
>>          else {}//ARM_HardFP<br>
>>      }<br>
>>      else<br>
>>      {//NoFloat<br>
>>      }<br>
>> }<br>
><br>
><br>
> I think that makes it more confusing.<br>
><br>
><br>
>><br>
>> * Why do we have MIPS_NoFloat? This can be replaced by<br>
>>    version(D_SoftFloat) else version(D_HardFloat) else()<br>
>>    (looks a little ugly, but a convenience version can be defined in user<br>
>>    code)<br>
><br>
><br>
> 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.<br>
><br>
> Martin, thoughts on this?<br>
><br>
><br>
>><br>
>> * Why do we have MIPS32? No other architecture has a 32 version?<br>
><br>
><br>
> We discussed that here: <a href="https://github.com/D-Programming-Language/d-programming-language.org/pull/207#discussion_r2358525">https://github.com/D-Programming-Language/d-programming-language.org/pull/207#discussion_r2358525</a><br>

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

></p>
<p>I see this as being a bug.</p>
<p>> Why the check for INT_SIZE? Isn't it always 16 or 32 in GCC (never 64)?<br>
><br>
></p>
<p>There are __ILP64__ targets out there...</p>
<p>For D, its only useful for C compatibilty, eg:</p>
<p>version(D_ILP64)<br>
alias long c_int;<br></p>
<p>>><br>
>> * ARM64 always has a FPU. I guess it should not set any of the<br>
>>    ARM_*Float versions?<br>
><br>
><br>
> I think for convenience and least surprise, we should still set ARM_HardFP.<br>
><br>
><br>
>><br>
>> * Are D_X32 and X86_64 exclusive or does a X32 system define both?<br>
><br>
><br>
> D_X32 is a data model (like D_LP64) so it can be defined alongside X86_64.<br>
><br>
><br>
>><br>
>> * What about an ARM_Thumb2 version?<br>
><br>
><br>
> 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.<br>
><br>
></p>
<p>I seem to recall thumb being mostly 16bit systems.</p>
<p>>><br>
>> * Does Cygwin also define Windows, Win32, Win64? Posix?<br>
><br>
><br>
> I don't think anyone has ported a D compiler to Cygwin, so who knows...<br>
><br>
> 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.<br>
><br>
></p>
<p>It should define Posix and Windows. I wouldn't have thought Win32/Win64 to be required/is out of scope for the cygwin platform. <br></p>
<p>Regards<br>
Iain</p>