orthogonalize MIPS version identifiers

[MartinNowak]

The old identifiers suffered from combinatorial explosion. The new ones are closely modeled after gcc options and predefines and are thus less cumbersome to work with when porting headers.

gdc options	version identifiers
-mabi=32	MIPS,MIPS32,MIPS_O32,MIPS_SoftFloat
-mabi=64 -mhard-float	MIPS,MIPS64,MIPS_N64,MIPS_HardFloat
-mabi=eabi -mgp64 -mno-abicalls	MIPS,MIPS64,MIPS_EABI,MIPS_SoftFloat

[MartinNowak]

also see the corresponding GDC pull D-Programming-GDC/gdc#39

[alexrp]

Why remove the 32-bit? Remember, the 32-bit and 64-bit identifiers are mutually exclusive (as with X86 and X86_64).

[MartinNowak]

It's supposed to be always defined, even for MIPS64. This is similar to __mips__ in C and GNU handling them both under the same architecture.
Having separate Identifiers for 32/64 is extremely unhandy and forced me to add boilerplate version = AnyMIPS everywhere.

[alexrp]

But on the other hand it will be confusing to D programmers. Because X86 is not defined on X86_64, people write code like this:

version (X86)
{
    32-bit x86 code ...
}
else version (X86_64)
{
    64-bit x86 code ...
}

The equivalent code for MIPS would then be wrong.

I get your point about boilerplate but consistency is more important IMHO.

As an alternative, we could have MIPS, MIPS32, and MIPS64. That approach still suffers from the consistency issue but not as much.

[MartinNowak]

OK, I'll add the complementary MIPS32.

The X86 approach is equally flawed. One third of the version = statements in druntime join X86_64 and X86. Keeping the current approach doesn't scale, think of this module with 10 more architectures.

We also need orthogonal subsets rather than specialized sets (MIPS_N32_SoftFP) because nesting version blocks performs an intersection where the latter requires a join.

[dnadlinger]

@dawgfoto: +1

[alexrp]

I don't necessarily think the way X86 and X86_64 work is flawed, but I do think our version system is flawed in any case. The fact that we don't support logical and/or in them is very silly and many people have complained about this, but Walter in particular calls it "too complex" even though there are real use cases... /rant

(I'm not against the changes to the FP ABI identifiers in any way, by the way.)

[donc]

My proposal in bug 7417 would fix the version system without causing the complexity problems. In fact it would reduce complexity.

[alexrp]

See comments, otherwise LGTM.

[alexrp]

Also, is the MIPS EABI a separate ABI from O32 and friends?

[ibuclaw]

Out of curiosity, why does each target have it's own _HardFP/_SoftFP, isn't the generic D_HardFloat/D_SoftFloat identifiers enough?

[alexrp]

@ibuclaw The original reason was that those two don't cover all the possible ABIs used on various archs (e.g. ARM has 3 FP ABIs). In the case of MIPS, though, they may be enough and we could consider getting rid of the MIPS-specific ones.

[MartinNowak]

isn't the generic D_HardFloat/D_SoftFloat identifiers enough

Those don't seem to suffice.
On MIPS you have -mno-float which drops software emulation. So someone could need MIPS_NoFloat to select an integer arithmetic fallback.
On ARM there is -mfloat-abi=softfp which uses the software ABI with a hardware FPU.

[ibuclaw]

isn't the generic D_HardFloat/D_SoftFloat identifiers enough

Those don't seem to suffice.
On MIPS http://gcc.gnu.org/onlinedocs/gcc/MIPS-Options.html you have
-mno-float which drops software emulation. So someone could need
MIPS_NoFloat to select an integer arithmetic fallback.
On ARM http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html there is
-mfloat-abi=softfp which uses the software ABI with a hardware FPU.

Yes, but in what situation would the front end language / programmer need
to know that?

[alexrp]

It would be relevant if you're writing inline assembly, for instance.