Skip to content
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

Add architectures supported by Mono but not supported by CoreCLR to System.Runtime.InteropServices.Architecture #26634

Closed
NattyNarwhal opened this issue Jun 27, 2018 · 24 comments
Assignees
Labels
api-needs-work API needs work before it is approved, it is NOT ready for implementation area-System.Runtime.InteropServices runtime-mono specific to the Mono runtime
Milestone

Comments

@NattyNarwhal
Copy link
Contributor

NattyNarwhal commented Jun 27, 2018

Mono consumes this enum, but also supports architectures that aren't 32/64-bit x86/ARM; in particular, PowerPC and WebAssembly. (SPARC and MIPS are supported, but being removed for 6.0 unless someone does something otherwise.)

To bikeshed on possible values:

* WebAssembly (was added)

OSPlatform could also use other OSes, but string construction of new ones works in the meantime as CoreFX doesn't want to add API surface until CoreCLR supports the OS.

Propsoal

namespace System.Runtime.InteropServices
{
    public enum Architecture
    {
        X86,
        X64,
        Arm,
        Arm64,
+       PowerPC,
+       PowerPC64,
+       S390X,
    }
}
@jkotas
Copy link
Member

jkotas commented Jun 28, 2018

Do we really need separate values for PowerPC64 and PowerPC64LE? You can tell the difference between the two using BitConverter.IsLittleEndian property.

@NattyNarwhal
Copy link
Contributor Author

They aren't binary compatible (and usually have different calling conventions, though there BE systems with the LE calling convention) but I see where you're going.

@jkotas
Copy link
Member

jkotas commented Jun 28, 2018

Right. Windows x64 and Linux x64 are not binary compatible either, and both return X64.

@jaykrell
Copy link
Contributor

jaykrell commented Aug 13, 2018

One wonders what is the intended use of this information.

NattyNarwhal referenced this issue in NattyNarwhal/mono Aug 14, 2018
	* For ProcessArchitecture, use the DllMap arch of the runtime.

	* For OSArchitecture, make an educated guess combining
	  ProcessArchitecture and Environment.Is64BitOperatingSystem.

	* For non-Intel/ARM architectures, (supported by Mono and not
	  on the chopping block are PPC32/64, z, and WebAssembly)
	  please dogpile onto dotnet/corefx#30706.
akoeplinger referenced this issue in mono/mono Aug 20, 2018
…on (#10088)

* For ProcessArchitecture, use the DllMap arch of the runtime.

* For OSArchitecture, make an educated guess combining ProcessArchitecture and Environment.Is64BitOperatingSystem.

* For non-Intel/ARM architectures, (supported by Mono and not on the chopping block are PPC32/64, z, and WebAssembly) please dogpile onto dotnet/corefx#30706.
@borgdylan
Copy link
Contributor

@jkotas w.r.t PPC64 and PPC64LE: They are different CPU architectures not different operating systems. Linux runs on both and requires different code to handle them.

@jaykrell
Copy link
Contributor

Its an ABI perhaps. What does anyone do with this information?

@joshfree
Copy link
Member

joshfree commented Mar 4, 2019

@jeffschwMSFT

@jkoritzinsky jkoritzinsky self-assigned this Apr 12, 2019
@jkoritzinsky
Copy link
Member

Based on the discussion above, these are the new API's that are being proposed:

namespace System.Runtime.InteropServices
{
    public enum Architecture
    {
        X86,
        X64,
        Arm,
        Arm64,
+       PowerPC,
+       PowerPC64,
+       S390X,
+       WebAssembly
    }
}

@joshfree @terrajobst can we get this on the API Review schedule?

@NattyNarwhal
Copy link
Contributor Author

It looks good to me, but the only nitpick I have is LE and BE for ppc64 are different, unless API consumers also check IsLittleEndian. (That's not even going into ELFv1 and ELFv2, which are not dependent on endianness, but a runtime should abstract that.)

@jaykrell
Copy link
Contributor

Sparc? Mips? 32bit s390? Ia64? Mipsv? Sh? What is anyone supoosed to do with this information anyway?

@terrajobst
Copy link
Member

In general, we're OK with extending that set. But a couple of thoughts:

  • Is WebAssembly the official name of the instruction set?
  • What real device is S390X used in? We shouldn't just add some random hardware unless it's meaningful.
  • This is an enum. We should coordinate the change with Mono to make sure we don't use mimatching numbers.

@jkoritzinsky, do you want to help with that?

@jaykrell
Copy link
Contributor

S390X is real IBM mainframe architecture.

@jkoritzinsky
Copy link
Member

Re Mono coordination: Mono uses our implemention from the shared partition, so whatever we pick will match them when they consume it.

I'll go verify what the official name of the WebAssembly instruction set is.

@jkoritzinsky
Copy link
Member

The only name I can find on the WebAssembly website is WebAssembly.

@fnawratil
Copy link

fnawratil commented Apr 23, 2019

@jkoritzinsky is right. In section "Scope" of the WebAssembly Spec it is clearly defined as a virtual ISA.

@jkoritzinsky
Copy link
Member

To ensure there is proper discussion of the various names, and competing priorities, we are going to push this out of .NET Core 3.0 and consider in a later release.

@msftgits msftgits transferred this issue from dotnet/corefx Jan 31, 2020
@msftgits msftgits added this to the 5.0 milestone Jan 31, 2020
@maryamariyan maryamariyan added the untriaged New issue has not been triaged by the area owner label Feb 23, 2020
@jeffschwMSFT jeffschwMSFT removed the untriaged New issue has not been triaged by the area owner label Feb 24, 2020
@AaronRobinsonMSFT
Copy link
Member

@jkoritzinsky Seems like we added Wasm at 3b4c5a5. Do we have plans for the others?

@jkoritzinsky
Copy link
Member

I don't believe we have plans for the others at the moment. With the addition of Wasm, we cover all of the architectures that we support in .NET 5. I know that S390X is supported on mono/mono, but I don't believe the dotnet/runtime build of Mono supports it.

@akoeplinger
Copy link
Member

I know that S390X is supported on mono/mono, but I don't believe the dotnet/runtime build of Mono supports it.

It's not built at the moment but I don't see why it wouldn't work as it's just another architecture for the JIT. The bigger task is getting the BCL aware of the new architectures (which extends into arcade, nuget, msbuild, etc...).

It'd be nice if we had some documented way how to do that, e.g. there seems to also be some activity on the MIPS front: #4234

@jkotas jkotas added the runtime-mono specific to the Mono runtime label Jun 8, 2020
@marek-safar marek-safar modified the milestones: 5.0, Future Jun 12, 2020
@marek-safar
Copy link
Contributor

WebAssembly was added

@neman
Copy link

neman commented Oct 14, 2020

Quote from @terrajobst

In general, we're OK with extending that set. But a couple of thoughts:

  • What real device is S390X used in? We shouldn't just add some random hardware unless it's meaningful.

s390x is successor of IBM System/360 instruction set architecture, which is used since 60's. 390 is 3rd generation
I am not an expert in this field, but our client is using s390x based mainframe (z14 is a microprocessor), so I did some research.

As a consequence, our product, based on .net core and docker Linux images, can not be deployed, and it is a complete failure of our product working everywhere, cross platform and so on.

It would be great if s390x could be supported!

@bencz
Copy link

bencz commented Feb 5, 2021

@neman Look this: https://github.com/dotnet/runtimelab/tree/feature/s390x

@michaldobrodenka
Copy link

ARMv6 via MonoVM. I have to support many (like thousand) legacy ARMv6 devices via old mono. I would really like to switch to net6.

I not feeling like a leading this project, but definitely I would like to help if needed.

@jkotas
Copy link
Member

jkotas commented May 9, 2022

S390 and WebAssembly was added. PPC is tracked by #67428

@jkotas jkotas closed this as completed May 9, 2022
@ghost ghost locked as resolved and limited conversation to collaborators Jun 9, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
api-needs-work API needs work before it is approved, it is NOT ready for implementation area-System.Runtime.InteropServices runtime-mono specific to the Mono runtime
Projects
None yet
Development

No branches or pull requests