-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[API Proposal]: Add public Architecture enum value for LoongArch64 #63042
Comments
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. |
Marking as ready for review & blocking since implementation for the arch is ready. |
Yes, it should be included in the Machine enum. The Machine enum is meant to mirror the Windows PE spec. I have edited the proposal above. |
namespace System.Runtime.InteropServices
{
public enum Architecture
{
// Existing:
// X86
// X64
// Arm
// Arm64
// Wasm
// S390x
LoongArch64,
}
}
namespace System.Reflection.PortableExecutable
{
public enum Machine : ushort
{
// Existing:
// Alpha
// Alpha64
// AM33
// Amd64
// Arm
// Arm64
// ArmThumb2
// Ebc
// I386
// IA64
// M32R
// MIPS16
// MipsFpu
// MipsFpu16
// PowerPC
// PowerPCFP
// SH3
// SH3Dsp
// SH3E
// SH4
// SH5
// Thumb
// Tricore
// Unknown
// WceMipsV2
LoongArch32 = 0x6232,
LoongArch64 = 0x6264
}
} |
@terrajobst @jkotas @AaronRobinsonMSFT As discussed in API review, we're likely to become an IANA-like registry of these architectures. We should strongly consider publishing formal criteria by which new entries can be added to this enum. Who would have ownership of defining & publishing such criteria? |
We have a high-level guide for what it takes to create CoreCLR port at: https://github.com/dotnet/runtime/blob/main/docs/design/coreclr/botr/guide-for-porting.md We have number of places that require boilerplate changes for new architecture: build scripts, Arcade repo, RID graph, public architecture enum, etc. We expect people working on new ports to do these changes roughly in order. For example, if somebody starts the port by adding the architecture to managed public surface, we will kindly ask them to start with the build scripts first. Our contribution guidelines encourage new ports: https://github.com/dotnet/runtime/blob/main/CONTRIBUTING.md#contributing-ports. We do not have a formal criteria for starting new ports and I do not think we need one. Anybody with enough motivation can start a new port and we will be happy to work with them. |
@shushanhf The enum values has been approved and you can update in your PR. |
I'm OK with that bar being "hey, we're actively working on a port to <architecture X> and thus request an addition to the architecture enums". That bar seems sufficiently high and I don't see a lot of evidence that would suggest this might result in API pollution. In order to keep things simple for all involved parties, I'm OK with approving these APIs as we go, without asking people to finish their port first because as @jkotas suggests some of these enums are part of the infrastructure that is used to target these architectures. Please note that there are other examples, such as RID entries and TFMs in NuGet. The situation there is similar, e.g. we recentally added nanoFramework as a TFM. I think we're doing us and the community a service by having a relatively straight-forward process for requesting additions in order to unblock community forks. The alternative would be to invest in decentralized mechanisms (like what we'd like to do with the RID graph) but that's not always workable. Does this make sense? |
Thanks. |
Closing since the implementation is merged. |
Background and motivation
Developers from Loongnix are going to add support for a new architecture LoongArch64 to .NET. The enums for architectures should be extended to support it. The implementation PR is #62888.
Since it's also defined in Windows PE spec, an enum value for PE machine type could also be added.
API Proposal
namespace System.Runtime.InteropServices { public enum Architecture { X86, X64, Arm, Arm64, Wasm, S390x, + LoongArch64, } }
API Usage
Code can check if they are running on LoongArch64 architecture.
Alternative Designs
LoongArch32 is also defined in Windows PE spec. Do we need to include it too?
Risks
No response
The text was updated successfully, but these errors were encountered: