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