Inconsistency in CPU version symbols

Alex Rønne Petersen alex at lycus.org
Sun Jan 27 07:20:58 PST 2013


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 at alexrp.com / alex at lycus.org
http://lycus.org


More information about the Digitalmars-d mailing list