Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

orthogonalize MIPS version identifiers #207

Merged
merged 1 commit into from

5 participants

@MartinNowak
Collaborator

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
Collaborator

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

@alexrp alexrp commented on the diff
version.dd
@@ -266,16 +266,15 @@ version($(I identifier)) // add in version code if version
$(TR $(TD $(B PPC_HardFP)) $(TD The PowerPC hard float ABI))
$(TR $(TD $(B PPC64)) $(TD The PowerPC architecture, 64-bit))
$(TR $(TD $(B IA64)) $(TD The Itanium architecture (64-bit)))
- $(TR $(TD $(B MIPS)) $(TD The MIPS architecture, 32-bit))
+ $(TR $(TD $(B MIPS)) $(TD The MIPS architecture))
@alexrp Collaborator
alexrp added a note

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

@MartinNowak Collaborator

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 Collaborator
alexrp added a note

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 Collaborator

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.

@klickverbot Collaborator

@dawgfoto: +1

@alexrp Collaborator
alexrp added a note

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 Collaborator
donc added a note

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
version.dd
((10 lines not shown))
$(TR $(TD $(B MIPS_N32)) $(TD The MIPS N32 ABI))
- $(TR $(TD $(B MIPS_N32_SoftFP)) $(TD The MIPS N32 soft float ABI))
- $(TR $(TD $(B MIPS_N32_HardFP)) $(TD The MIPS N32 hard float ABI))
- $(TR $(TD $(B MIPS64)) $(TD The MIPS architecture, 64-bit))
- $(TR $(TD $(B MIPS64_SoftFP)) $(TD The MIPS N64 soft float ABI))
- $(TR $(TD $(B MIPS64_HardFP)) $(TD The MIPS N64 hard float ABI))
+ $(TR $(TD $(B MIPS_O64)) $(TD The MIPS O64 ABI))
+ $(TR $(TD $(B MIPS_N64)) $(TD The MIPS N64 ABI))
+ $(TR $(TD $(B MIPS_EABI)) $(TD The MIPS EABI ABI))
@alexrp Collaborator
alexrp added a note

-ABI

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@alexrp
Collaborator

See comments, otherwise LGTM.

@alexrp
Collaborator

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

@jpf91 jpf91 referenced this pull request in D-Programming-GDC/GDC
Closed

predefined version identifiers for MIPS #39

@ibuclaw
Collaborator

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

@alexrp
Collaborator

@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
Collaborator

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.

@alexrp alexrp merged commit d69bc7d into D-Programming-Language:master
@ibuclaw
Collaborator
@alexrp
Collaborator

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

@ghost Unknown referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@ghost Unknown referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@ghost Unknown referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@ghost Unknown referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Dec 9, 2012
  1. @MartinNowak
This page is out of date. Refresh to see the latest.
Showing with 9 additions and 8 deletions.
  1. +9 −8 version.dd
View
17 version.dd
@@ -266,16 +266,17 @@ version($(I identifier)) // add in version code if version
$(TR $(TD $(B PPC_HardFP)) $(TD The PowerPC hard float ABI))
$(TR $(TD $(B PPC64)) $(TD The PowerPC architecture, 64-bit))
$(TR $(TD $(B IA64)) $(TD The Itanium architecture (64-bit)))
- $(TR $(TD $(B MIPS)) $(TD The MIPS architecture, 32-bit))
+ $(TR $(TD $(B MIPS)) $(TD The MIPS architecture))
@alexrp Collaborator
alexrp added a note

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

@MartinNowak Collaborator

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 Collaborator
alexrp added a note

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 Collaborator

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.

@klickverbot Collaborator

@dawgfoto: +1

@alexrp Collaborator
alexrp added a note

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 Collaborator
donc added a note

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
+ $(TR $(TD $(B MIPS32)) $(TD The MIPS architecture, 32-bit))
+ $(TR $(TD $(B MIPS64)) $(TD The MIPS architecture, 64-bit))
$(TR $(TD $(B MIPS_O32)) $(TD The MIPS O32 ABI))
- $(TR $(TD $(B MIPS_O32_SoftFP)) $(TD The MIPS O32 soft float ABI))
- $(TR $(TD $(B MIPS_O32_HardFP)) $(TD The MIPS O32 hard float ABI))
$(TR $(TD $(B MIPS_N32)) $(TD The MIPS N32 ABI))
- $(TR $(TD $(B MIPS_N32_SoftFP)) $(TD The MIPS N32 soft float ABI))
- $(TR $(TD $(B MIPS_N32_HardFP)) $(TD The MIPS N32 hard float ABI))
- $(TR $(TD $(B MIPS64)) $(TD The MIPS architecture, 64-bit))
- $(TR $(TD $(B MIPS64_SoftFP)) $(TD The MIPS N64 soft float ABI))
- $(TR $(TD $(B MIPS64_HardFP)) $(TD The MIPS N64 hard float ABI))
+ $(TR $(TD $(B MIPS_O64)) $(TD The MIPS O64 ABI))
+ $(TR $(TD $(B MIPS_N64)) $(TD The MIPS N64 ABI))
+ $(TR $(TD $(B MIPS_EABI)) $(TD The MIPS EABI))
+ $(TR $(TD $(B MIPS_NoFloat)) $(TD The MIPS $(B no-float) ABI))
+ $(TR $(TD $(B MIPS_SoftFloat)) $(TD The MIPS $(B soft-float) ABI))
+ $(TR $(TD $(B MIPS_HardFloat)) $(TD The MIPS $(B hard-float) ABI))
$(TR $(TD $(B SPARC)) $(TD The SPARC architecture, 32-bit))
$(TR $(TD $(B SPARC_V8Plus)) $(TD The SPARC v8+ ABI))
$(TR $(TD $(B SPARC_SoftFP)) $(TD The SPARC soft float ABI))
Something went wrong with that request. Please try again.