Inconsistency in CPU version symbols

[Johannes Pfau]

Am Sun, 27 Jan 2013 16:20:58 +0100
schrieb Alex Rønne Petersen <alex at 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.