[API Proposal]: Add architecture PPC64le to Architecture enum

[Sapana-Khemkar]

Background and motivation

All architectures, whether officially Microsoft supported or not, need to exist within the System.Runtime.InteropServices.Architecture enum. We want to introduce a new community-supported architecture ppc64le.
The implementation PR is #68809

API Proposal

namespace System.Runtime.InteropServices
{
    public enum Architecture
    {
        X86 = 0,
        X64 = 1,
        Arm = 2,
        Arm64 = 3,
        Wasm = 4,
        S390x = 5,
        LoongArch64 = 6,
        Armv6 = 7,
+       PPC64le = 8,
    }
}

API Usage

 case Architecture.PPC64le:
    Assert.Equal(Architecture.PPC64le, processArch);
    break;

Alternative Designs

No response

Risks

No response

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Background and motivation

All architectures, whether officially Microsoft supported or not, need to exist within the System.Runtime.InteropServices.Architecture enum. We want to introduce a new community-supported architecture ppc64le.
The implementation PR is #67378

API Proposal

namespace System.Runtime.InteropServices
{
    public enum Architecture
    {
        X86 = 0,
        X64 = 1,
        Arm = 2,
        Arm64 = 3,
        Wasm = 4,
        S390x = 5,
        LoongArch64 = 6,
        Armv6 = 7,
+     POWERPC64 = 8,

    }
}

API Usage

 case Architecture.POWERPC64:
                    Assert.Equal(Architecture.POWERPC64, processArch);
                     break;

Alternative Designs

No response

Risks

No response

Author:	Sapana-Khemkar
Assignees:	-
Labels:	api-suggestion, area-System.Runtime.InteropServices, untriaged
Milestone:	-

[MichalStrehovsky]

Why all caps? The architecture seems to be referred to as PowerPC everywhere, not POWERPC (e.g. wikipedia: https://en.wikipedia.org/wiki/PowerPC).

[Sapana-Khemkar]

Why all caps? The architecture seems to be referred to as PowerPC everywhere, not POWERPC (e.g. wikipedia: https://en.wikipedia.org/wiki/PowerPC).

Agree. Changed

[AaronRobinsonMSFT]

@Sapana-Khemkar Thanks for the suggestion. It would be helpful to elaborate on the goals of adding this and how it would be supported. Is this the first step in providing community support for PowerPC? This is a non-trivial process and understanding how this would occur would be helpful.

[tannergooding]

Should this be PowerPC or PowerPCFP (or some variation that indicates PowerPC + Floating Point support). They are considered different by the PE file format: https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#machine-types

[akoeplinger]

Or PowerPC64LE to make it clear it's the little endian version.

[MichalStrehovsky]

Should this be PowerPC or PowerPCFP (or some variation that indicates PowerPC + Floating Point support). They are considered different by the PE file format: https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#machine-types

We don't represent float support in Architecture.Arm - what makes PowerPC64 special in this respect?

Or PowerPC64LE to make it clear it's the little endian version.

We don't represent endianness in Architecture.Arm - what makes PowerPC64 special in this respect?

[tannergooding]

We don't represent float support in Architecture.Arm - what makes PowerPC64 special in this respect?

Other architectures/ABIs are differentiating, including the PE file format. That may or may not be important when considering the Architecture enum. It's a consideration that should be made.

[akoeplinger]

We don't represent endianness in Architecture.Arm - what makes PowerPC64 special in this respect?

While Arm technically can run in big-endian mode, practically all implementations and ports are for little-endian (e.g. there's no big-endian Linux support) so the distinction is less important.

PowerPC on the other hand shipped as primarily big-endian for much of its lifetime while the little-endian ppc64le is a relatively recent addition which I think might warrant the distinction in the enum name.