PowerPC and AIX support #10055

bencz · 2018-03-28T17:35:00Z

After some research, I checked that the .net core has no supported for PowerPC or AIX ... Are there plans to implement support for the Power architecture and the AIX operating system?

janvorli · 2018-03-28T18:42:12Z

The largest amount of work is always in adding support for a new architecture to the JIT. We have JIT for arm, arm64, x86 and x64 architectures. There are currently no plans on adding new architectures support, but nothing prevents the community from starting such an effort.

ghost · 2018-03-28T19:10:53Z

@janvorli, based on your experience, when aarch and aarch64 support were added, is there any rough checklist to support more architectures like ppc64le, mips64 etc. and generally RISC? There is also https://github.com/NETMF/netmf-interpreter by Microsoft, which has similar spectrum of support, perhaps convergence with that project will yield broader reach for CoreCLR. Not sure how feasible is the convergence with netmf, though.

janvorli · 2018-03-28T20:38:28Z

@kasper3 coreclr contains an interpreter too (disabled by default), but it hasn't been turned on or tested for a very long time. I just remember someone made coreclr compile without errors when the FEATURE_INTERPRETER is enabled and there were some attempts to use it by someone from the community.

As for new architectures, a coarse checklist (in an arbitrary order) would be :

ASM helpers
Thunks (e.g. the shuffle thunk for delegates) generated as machine code
Processor context related stuff in stack walking, thread suspension and exception handling.
Calling convention related code, like the arg iterator, interop, ... The more complex the calling convention, the more work is needed. Structs passed in registers is an example of such a complexity.
JIT - this is the largest amount of work.
Unwind info for the new architectures. For the existing ones, we use Windows unwind info format for the JITted code, for architectures that windows don't support, it would need to be designed from scratch.
GC info format may need to be updated for the new architectures.
If these architectures are big endian, there might be changes needed due to that.
Possibly other stuff I've forgotten to mention

As for AIX, it is hard to tell how much surprises it would bring. I have no idea how much it differs from Linux.

mattwarren · 2018-03-29T14:48:27Z

@kasper3 I wrote a post about the interpreter that you might find useful, see The .NET IL Interpreter.

But as @janvorli mentioned, work was done to make it easier to enable (so you can ignore that part of the post) see dotnet/coreclr#11188 and dotnet/coreclr#11252

ghost · 2018-03-29T15:41:07Z

@janvorli, @mattwar, thanks, didn't knew about interpreter feature. For the basic interpreter to work in an antoconfig manner, we could probably integrate coreclr interpreter with the qemu assembly transpilation component https://github.com/qemu/qemu/tree/47d3b60858d90ac8a0cc3a72af7f95c96781125a/target, in order to run some code on non-supported architectures (slow version). Gradually, the full support can be added starting from ASM helpers from Jan's list. I am not sure how feasible is Xassembly-to-Yassembly ops transpilation using qemu? Maybe that component alone can be compiled as an independent libasmconv (named after libiconv) from qemu sources for such experimentations (not for production usage).

ghuntley · 2018-03-29T20:46:14Z

I would love see a power on Linux bringup. AIX isn't worth the engineering cycles tho - see my thread on twitter. https://twitter.com/GeoffreyHuntley/status/979453657472053248?s=19

NattyNarwhal · 2018-08-30T17:44:08Z

for the audience at home, if you want .NET on AIX or i, I maintain the Mono port for that - somewhat of a WIP, but it compiles all the way through and passes more tests than I expected

afxgroup · 2019-01-18T11:10:41Z

a Powerpc port would be really great 👍

turabek · 2019-03-20T10:22:37Z

We also want to run our Core Banking Application on Power PC Processors PPC64LE. May I know from .net core team is this on your roadmap? When this will be possible?

ghuntley · 2019-04-12T15:44:02Z

It's not on their roadmap @turabek

There are currently no plans on adding new architectures support, but nothing prevents the community from starting such an effort.

bencz · 2019-05-11T18:17:28Z

Is it not possible to use the JIT used in the .net of xbox?
Or rather use it as a starter?

xiangzhai · 2019-05-16T13:39:39Z

Hi @mattwarren

@kasper3 I wrote a post about the interpreter that you might find useful, see The .NET IL Interpreter.

Thanks for your great blog The .NET IL Interpreter.

But as @janvorli mentioned, work was done to make it easier to enable (so you can ignore that part of the post) see dotnet/coreclr#11188 and dotnet/coreclr#11252

But when I migrated to the master dotnet/coreclr#24513 Interpreter seems not work:

Histogram of method executions:
   # of execs   |   # meths (%)    |   cum % | % cum execs
   -------------------------------------------------------
            0   |       0 ( -nan%) |   -nan% |   -nan%
            1   |       0 ( -nan%) |   -nan% |   -nan%
            2   |       0 ( -nan%) |   -nan% |   -nan%
            3   |       0 ( -nan%) |   -nan% |   -nan%
            4   |       0 ( -nan%) |   -nan% |   -nan%
            5   |       0 ( -nan%) |   -nan% |   -nan%
            6   |       0 ( -nan%) |   -nan% |   -nan%
            7   |       0 ( -nan%) |   -nan% |   -nan%
            8   |       0 ( -nan%) |   -nan% |   -nan%
            9   |       0 ( -nan%) |   -nan% |   -nan%
           10   |       0 ( -nan%) |   -nan% |   -nan%

For methods sorted in ascending # of executions order, cumulative % of executions:

Total number of calls from interpreted code: 0.
    Also, 0 are intrinsics; 0 of these are not currently handled intrinsically.
    Of these, 0 to potential property getters (0 of these dead simple), 0 to setters.
    Of the dead simple getter calls, 0 have been short-circuited.

Token resolutions by category:
Category     |  opportunities  |   calls   |      %
---------------------------------------------------
   Undefined |               0 |         0 |   0.00%
 Constrained |               0 |         0 |   0.00%
      NewObj |               0 |         0 |   0.00%
      NewArr |               0 |         0 |   0.00%
     LdToken |               0 |         0 |   0.00%
       LdFtn |               0 |         0 |   0.00%
   LdVirtFtn |               0 |         0 |   0.00%
    SFldAddr |               0 |         0 |   0.00%
      LdElem |               0 |         0 |   0.00%
        Call |               0 |         0 |   0.00%
       LdObj |               0 |         0 |   0.00%
       StObj |               0 |         0 |   0.00%
       CpObj |               0 |         0 |   0.00%
     InitObj |               0 |         0 |   0.00%
      IsInst |               0 |         0 |   0.00%
   CastClass |               0 |         0 |   0.00%
    MkRefAny |               0 |         0 |   0.00%
   RefAnyVal |               0 |         0 |   0.00%
      Sizeof |               0 |         0 |   0.00%
      StElem |               0 |         0 |   0.00%
         Box |               0 |         0 |   0.00%
       Unbox |               0 |         0 |   0.00%
    UnboxAny |               0 |         0 |   0.00%
       LdFld |               0 |         0 |   0.00%
      LdFldA |               0 |         0 |   0.00%
       StFld |               0 |         0 |   0.00%
   FindClass |               0 |         0 |   0.00%
   Exception |               0 |         0 |   0.00%

No printf in the Interpreter::ExecuteMethod or Interpreter::Terminate:

diff --git a/src/vm/interpreter.cpp b/src/vm/interpreter.cpp
index b4b18cb..53ae5c2 100644
--- a/src/vm/interpreter.cpp
+++ b/src/vm/interpreter.cpp
@@ -1878,6 +1878,7 @@ void Interpreter::DoMonitorExitWork()
 
 void Interpreter::ExecuteMethod(ARG_SLOT* retVal, __out bool* pDoJmpCall, __out unsigned* pJmpCallToken)
 {
+    printf("DEBUG: %s:%d\n", __FILE__, __LINE__);
 #if INTERP_DYNAMIC_CONTRACTS
     CONTRACTL {
         THROWS;
@@ -6511,6 +6512,7 @@ CORINFO_CLASS_HANDLE Interpreter::GetTypedRefClsHnd(CEEInfo* info)
 
 void Interpreter::Initialize()
 {
+    printf("DEBUG: %s:%d\n", __FILE__, __LINE__);
     assert(!s_initialized);
 
     s_InterpretMeths.ensureInit(CLRConfig::INTERNAL_Interpret);
@@ -6553,6 +6555,7 @@ void Interpreter::InitializeCompilerStatics(CEEInfo* info)
 
 void Interpreter::Terminate()
 {
+    printf("DEBUG: %s:%d\n", __FILE__, __LINE__);
     if (s_initialized)
     {
         s_methodCacheLock.Destroy();

As comment mentioned:

// If we failed to jit, then fall back to the primary Jit.

AltJIT just fall back to primary JIT, but not Interpreter?
How to force fall back to interpreter? By hacking set ret to CORJIT_SKIPPED:

diff --git a/src/vm/jitinterface.cpp b/src/vm/jitinterface.cpp
index 502b5ad..0be76f6 100644
--- a/src/vm/jitinterface.cpp
+++ b/src/vm/jitinterface.cpp
@@ -12145,6 +12145,7 @@ CorJitResult invokeCompileMethodHelper(EEJitManager *jitMgr,
 
     bool isInterpreterStub   = false;
     bool interpreterFallback = (s_InterpreterFallback.val(CLRConfig::INTERNAL_InterpreterFallback) != 0);
+    printf("DEBUG: interpreterFallback: %d\n", interpreterFallback);
 
     if (interpreterFallback == false)
     {
@@ -12169,6 +12170,8 @@ CorJitResult invokeCompileMethodHelper(EEJitManager *jitMgr,
                                           nativeSizeOfCode);
     }
 
+    // Force fall back to interpreter
+    //ret = CORJIT_SKIPPED;
     if (interpreterFallback == true)
     {
         // If we're doing an "import_only" compilation, it's for verification, so don't interpret.

And I found that AArch64 Remove unnecessary interpreter fallback dotnet/coreclr#20470 So is it able to enable Interpreter at master now?

Thanks,
Leslie Zhai

mattwarren · 2019-05-16T14:18:36Z

I've not used the Interpreter since I wrote that post, so my memory is a bit hazy! But which (if any) environment variables have you set? See https://mattwarren.org/2017/03/30/The-.NET-IL-Interpreter/#Enabling%20the%20Interpreter and scroll down to the table of 'Host Configuration Knobs' for a bit more info. Or see https://github.com/dotnet/coreclr/blob/master/Documentation/project-docs/clr-configuration-knobs.md#interpreter-configuration-knobs.

From what I remember, you need to at least set the Interpret value to the method(s) you want to have interpreted

xiangzhai · 2019-05-16T14:36:32Z

I've not used the Interpreter since I wrote that post, so my memory is a bit hazy! But which (if any) environment variables have you set? See https://mattwarren.org/2017/03/30/The-.NET-IL-Interpreter/#Enabling%20the%20Interpreter and scroll down to the table of 'Host Configuration Knobs' for a bit more info. Or see https://github.com/dotnet/coreclr/blob/master/Documentation/project-docs/clr-configuration-knobs.md#interpreter-configuration-knobs.

From what I remember, you need to at least set the Interpret value to the method(s) you want to have interpreted

Set:

$ export | grep COMPlus
declare -x COMPlus_DumpInterpreterStubs="1"
declare -x COMPlus_Interpret="Main"
declare -x COMPlus_InterpreterFallback="1"
declare -x COMPlus_InterpreterPrintPostMortem="1"
declare -x COMPlus_TraceInterpreterEntries="1"
declare -x COMPlus_TraceInterpreterIL="1"
declare -x COMPlus_TraceInterpreterVerbose="1"

HHH, perhaps because this dotnet/coreclr#11252

to11mtm · 2019-08-29T22:09:48Z

Another Upvote, but I want to speak very specifically;

POWER Architecture would be huge for .NET for a number of reasons, including the existence of open, auditable platforms and the open-sourcing of the ISA and reference designs.

But really, the security angle is where I see a big win.

YohanSciubukgian · 2019-09-04T14:56:02Z

Do you also plan to support PPC 32 bits ?

aix1 · 2019-09-19T11:39:27Z

Upvote; applications that uses .NET is restricted to our x86 only and for their high demands on Performance and RAS we need the .NET core parts on ppc64le.

rickswah · 2019-09-23T16:10:32Z

One more Upvote! there is a lot of PPC64LE and PPC64 server around the world using just Java or PHP for the main systems.. the world need .net for PowerPC!!! @NattyNarwhal do a really good job on Mono Project... but, there is some diffs. from .net core

Tustra · 2019-09-23T17:40:09Z

upvote

mihaimyh · 2019-10-15T10:47:02Z

Any plans for AIX support? Lots of us are using AIX servers.

neosaldina · 2019-12-20T08:42:37Z

Is there any plan to start implementing the JIT for ppc, ppc64 or ppc64el ?

llebout · 2019-12-24T19:20:04Z

I also would like to run .NET Core on ppc64le. My workstation system runs Fedora with Linux.

danmoseley · 2020-02-28T17:54:14Z

There remains no plan for Microsoft support of AIX, but community work is welcome - FreeBSD has made contributions in this way.

neosaldina · 2020-03-13T17:32:19Z

Okay, Microsoft may not have plans to support AIX, but what about PowerPC ( ppc, ppc64 and ppc64le ) ?

neosaldina · 2020-03-13T17:37:31Z

I know that the Mono project has a system to host sites made in ASP.Net and ASP.Net MVC, if I'm not mistaken this project is called XSP ... the last time I tested it on ppc64, an error occurred when I tried to open the site...
@NattyNarwhal you are supporting Mono for ppc, can you tell if XSP is working correctly on ppc64 for ASP.Net MVC?

Sapana-Khemkar · 2022-07-26T04:34:49Z

@Sapana-Khemkar Cool!!! Did you perform any tests on support for ppc64be?

yes we are running runtime library tests. You can find the azure pipeline here Currently two test cases are failing. For which issue has been already raised #71080 and #71079

I don't understand, will this port work on ppc64be?

Sorry. I thought you are asking about ppc64le tests.
ppc64be we are not testing

archanox · 2022-07-26T08:40:46Z

To avoid confusion

ppc64 = big endian
ppc64el = little endian

Please avoid using non-standard nomenclature

aix1 · 2022-08-12T06:03:02Z

Isn’t it pp64le? /S Stephan Åkeborg Systems Engineer Digital Compute Platforms IKEA IT AB Sjögatan 1 / Box 803, SE-252 25 / 251 98 Helsingborg, Sweden Mobile: +46 (0)706 11 11 98 ***@***.******@***.***> Web: www.IKEA.com<http://www.ikea.com/> [signature_1007945694] [IBM Champion 2022] From: Erwin de Haan ***@***.***> Reply to: dotnet/runtime ***@***.***> Date: Friday, 12 August 2022 at 02:14 To: dotnet/runtime ***@***.***> Cc: Stephan Åkeborg ***@***.***>, Comment ***@***.***> Subject: Re: [dotnet/runtime] PowerPC and AIX support (#10055) To avoid confusion ppc64 = big endian ppc64el = little endian Please avoid using non-standard nomenclature Arguably there is no standard, it’s all over the place even within OS families (Linux distros for example). It’s whatever you are used to. Be it le or el. — Reply to this email directly, view it on GitHub<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2Fruntime%2Fissues%2F10055%23issuecomment-1212609688&data=05%7C01%7Cstephan.akeborg2%40ingka.ikea.com%7C84df18470f9947f5aa5008da7bf79583%7C720b637a655a40cf816af22f40755c2c%7C0%7C0%7C637958600554769734%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xn%2F77dEK5PoAZCpw5%2BGWBKa7mPPpyb5K8dcmxXS8OsY%3D&reserved=0>, or unsubscribe<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAH46N6BEXTFCXW76HG5B3HLVYWJNHANCNFSM4K5WE7UQ&data=05%7C01%7Cstephan.akeborg2%40ingka.ikea.com%7C84df18470f9947f5aa5008da7bf79583%7C720b637a655a40cf816af22f40755c2c%7C0%7C0%7C637958600554769734%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=dRB%2Frx3mGqwkqrb1qAma%2FeKZsqfoIRUND8MvRK8%2BfZ0%3D&reserved=0>. You are receiving this because you commented.Message ID: ***@***.***>

tappehl · 2022-08-12T06:42:57Z

Please avoid using non-standard nomenclature

Yeah, it was a bit irony "Please avoid using non-standard nomenclature" and then using the wrong nomenclature :-D

aix1 · 2022-08-12T06:50:09Z

😊, to early after vacation 😉 /S Stephan Åkeborg Systems Engineer Digital Compute Platforms IKEA IT AB Sjögatan 1 / Box 803, SE-252 25 / 251 98 Helsingborg, Sweden Mobile: +46 (0)706 11 11 98 ***@***.******@***.***> Web: www.IKEA.com<http://www.ikea.com/> [signature_926445412] [IBM Champion 2022] From: Torbjorn Appehl ***@***.***> Reply to: dotnet/runtime ***@***.***> Date: Friday, 12 August 2022 at 08:43 To: dotnet/runtime ***@***.***> Cc: Stephan Åkeborg ***@***.***>, Comment ***@***.***> Subject: Re: [dotnet/runtime] PowerPC and AIX support (#10055) Please avoid using non-standard nomenclature Yeah, it was a bit irony "Please avoid using non-standard nomenclature" and then using the wrong nomenclature :-D — Reply to this email directly, view it on GitHub<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2Fruntime%2Fissues%2F10055%23issuecomment-1212782227&data=05%7C01%7Cstephan.akeborg2%40ingka.ikea.com%7C537210f44aed44cbeb1708da7c2dedcb%7C720b637a655a40cf816af22f40755c2c%7C0%7C0%7C637958833945849261%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Jzv0fAL7In25eivnZpgmQOWV5C7lrgPqQdIN7lK4FhY%3D&reserved=0>, or unsubscribe<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAH46N6G7HHOM7KVJ7WNR3OLVYXW77ANCNFSM4K5WE7UQ&data=05%7C01%7Cstephan.akeborg2%40ingka.ikea.com%7C537210f44aed44cbeb1708da7c2dedcb%7C720b637a655a40cf816af22f40755c2c%7C0%7C0%7C637958833945849261%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7wKEANPRBH0zrnlZ3qegqo%2FypMzoepRT%2B8Ge%2Fdikmyw%3D&reserved=0>. You are receiving this because you commented.Message ID: ***@***.***>

archanox · 2022-08-12T11:12:02Z

Please avoid using non-standard nomenclature

Yeah, it was a bit irony "Please avoid using non-standard nomenclature" and then using the wrong nomenclature :-D

You guys are terrible at this. It's ppc64el, mips64el, armel...

Roman-Blinkov · 2022-08-12T11:17:40Z

Anyone want to edit Wikipedia?
https://en.m.wikipedia.org/wiki/Ppc64
ppc64le is a pure little-endian mode that has been introduced with the POWER8

Update: our hero must update not Wikipedia only but IBM pages similar to this: https://www.ibm.com/docs/en/cloud-private/3.1.1?topic=requirements-supported-operating-systems-platforms

tappehl · 2022-08-12T17:08:58Z

Please avoid using non-standard nomenclature

Yeah, it was a bit irony "Please avoid using non-standard nomenclature" and then using the wrong nomenclature :-D

You guys are terrible at this. It's ppc64el, mips64el, armel...

Not terrible, but I'll give you that both are accepted. In the IBM Power world LE is the most common expression though (as in Little Endian and not Endian Little (?)
https://www.ibm.com/support/pages/just-faqs-about-little-endian
"by Jeff Scheel, IBM Linux on Power Chief Engineer
As promised, here is my first blog post on little endian or "LE" as we call it."

But let's focus on the cool thing, .NET IS COMING TO POWER!!

afxgroup · 2022-08-14T07:10:48Z

Ok.. but why is it impossible to port .NET to PPC32BE? It is so hard?

bencz · 2022-08-14T07:38:08Z

Ok.. but why is it impossible to port .NET to PPC32BE? It is so hard?

I believe it is a problem of interests, IBM has already "killed" the Power64 B.E, the 32-bit version, IBM has buried it a long time ago and has even "decomposed"....

afxgroup · 2022-08-14T09:21:25Z

But there are some different alive PPC BE platforms in the world. Not only IBM. I don't know the effort to implement the changes to see the big endian version alive but if someone points the main files to change we can give it a try. And even Mono is working on PPC32

bkeys · 2022-08-28T22:42:02Z

Please avoid using non-standard nomenclature

Yeah, it was a bit irony "Please avoid using non-standard nomenclature" and then using the wrong nomenclature :-D

You guys are terrible at this. It's ppc64el, mips64el, armel...

Not terrible, but I'll give you that both are accepted. In the IBM Power world LE is the most common expression though (as in Little Endian and not Endian Little (?) https://www.ibm.com/support/pages/just-faqs-about-little-endian "by Jeff Scheel, IBM Linux on Power Chief Engineer As promised, here is my first blog post on little endian or "LE" as we call it."

But let's focus on the cool thing, .NET IS COMING TO POWER!!

@tappehl Could you expound on the last part of this post? Is there any efforts on the part of IBM to get .NET working on ppc64le?

tappehl · 2022-08-29T04:59:15Z

Yes @bkeys as you can see above, Sapana is involved in the project... It was ported to IBM Mainframe last year, and I did some magic behind the scenes when I heard Power was not involve in that project. Now there is another project going on :)

bkeys · 2022-09-02T20:10:39Z

@tappehl is there a loose timeline/broad estimate you think it will take until we have initial .NET support for POWER? I looked at the pull requests and it's really good news.

tappehl · 2022-09-03T06:22:21Z

@tappehl is there a loose timeline/broad estimate you think it will take until we have initial .NET support for POWER? I looked at the pull requests and it's really good news.

I cannot tell, but for s390 it was released with the last version of .NET..

kevincrans · 2022-09-08T21:20:56Z

Some years ago NXP was still creating powerpc, but I don't know if they still make them and the 68k based coldfire, they indirectly bought a piece Motorola from the AIM: Apple IBM Motorola alliance, if u didn't know.

kevincrans · 2022-09-17T22:39:16Z

I learned more, NXP stopped support (I like this Philips related company, but disappointing), meaning our hope lays with libre-soc and IBM. I do have to say, I like AIX support, but since macOS is already supported, only the arch has to be ported first.

tappehl · 2022-09-23T06:06:50Z

We also want to run our Core Banking Application on Power PC Processors PPC64LE. May I know from .net core team is this on your roadmap? When this will be possible?

Please reach out to me at torbjorn.appehl@ibm.com or torbjorn@builtonpower.com

janani66 · 2022-09-23T12:44:48Z

Enablement for ppc64le is in the upstream .NET7 and .NET8 ( main ) branches -- this is for the mono runtime engine and not CoreCLR. Testing continues. CI/CD pipelines are being run on ppc64le machines too.

bkeys · 2022-09-23T13:31:25Z

Enablement for ppc64le is in the upstream .NET7 and .NET8 ( main ) branches -- this is for the mono runtime engine and not CoreCLR. Testing continues. CI/CD pipelines are being run on ppc64le machines too.

That is great news! But mono has been available in the Fedora repositories for some time now with ppc64le architecture:
https://koji.fedoraproject.org/koji/rpminfo?rpmID=25347685
I know mono joined the .net foundation but can you explain to those less informed such as myself what this means for ppc64le users?
Is there plans to have ppc64le in the coreclr at some point?

janani66 · 2022-09-23T14:14:33Z

The current work is to get the mono engine in .NET7 working on ppc64le. CoreCLR will be targeted after the current .NET7 enablement for ppc64le is complete.

bencz · 2023-01-10T06:06:48Z

Now that IBM has released .net core 7, with support for ppc64le, how to install it on an Ubuntu or Debian server?

Sapana-Khemkar · 2023-01-10T06:49:15Z

Now that IBM has released .net core 7, with support for ppc64le, how to install it on an Ubuntu or Debian server?

We have to cross build tarball on Ubuntu 18.04/20.04 x86. I am working on blog for the same. I will link once it is published.

lehrbua · 2023-01-10T07:13:03Z

Now that IBM has released .net core 7, with support for ppc64le, how to install it on an Ubuntu or Debian server?

What about AIX ?

bkeys · 2023-01-10T16:12:05Z

Now that IBM has released .net core 7, with support for ppc64le, how to install it on an Ubuntu or Debian server?

Where does it say that .NET has ppc64le support?

nealef · 2023-01-10T16:14:40Z

Now that IBM has released .net core 7, with support for ppc64le, how to install it on an Ubuntu or Debian server?

Where does it say that .NET has ppc64le support?

https://www.itjungle.com/2022/11/09/ibm-and-microsoft-bring-net-to-power-after-all/

janani66 · 2023-01-10T16:21:16Z

Enablement for ppc64le is in the upstream .NET7 and .NET8 ( main ) branches -- this is for the mono runtime engine and not CoreCLR. Testing continues. CI/CD pipelines are being run on ppc64le machines too.

That is great news! But mono has been available in the Fedora repositories for some time now with ppc64le architecture: https://koji.fedoraproject.org/koji/rpminfo?rpmID=25347685 I know mono joined the .net foundation but can you explain to those less informed such as myself what this means for ppc64le users? Is there plans to have ppc64le in the coreclr at some point?

Differences between the previous available mono and the .NET7 based mono on ppc64le are explained by this post: https://www.linkedin.com/pulse/whats-difference-net-7-mono-paul-chapman/

Sapana-Khemkar · 2023-01-16T04:57:27Z

Blog on how to cross compile .NET7 for ppc64le https://community.ibm.com/community/user/powerdeveloper/blogs/sapana-khemkar/2023/01/13/cross-build-dotnet7-on-x86-ibm-power

neosaldina · 2023-06-14T14:40:57Z

Well, looks nice!!
This port is for ppc64le...

How complex would it be to make it compatible with ppc64?

msftgits transferred this issue from dotnet/coreclr Jan 31, 2020

msftgits added this to the Future milestone Jan 31, 2020

maryamariyan added the untriaged New issue has not been triaged by the area owner label Feb 26, 2020

danmoseley added os-unsupported OS which is not officially supported and removed untriaged New issue has not been triaged by the area owner labels Feb 28, 2020

alexrp mentioned this issue Apr 25, 2023

Add a linux-ppc64le toolset vezel-dev/zig-toolsets#23

Closed

PowerPC and AIX support #10055

PowerPC and AIX support #10055

Comments

bencz commented Mar 28, 2018

janvorli commented Mar 28, 2018

ghost commented Mar 28, 2018

janvorli commented Mar 28, 2018

mattwarren commented Mar 29, 2018

ghost commented Mar 29, 2018 • edited by ghost Loading

ghuntley commented Mar 29, 2018

NattyNarwhal commented Aug 30, 2018

afxgroup commented Jan 18, 2019

turabek commented Mar 20, 2019

ghuntley commented Apr 12, 2019

bencz commented May 11, 2019

xiangzhai commented May 16, 2019

mattwarren commented May 16, 2019

xiangzhai commented May 16, 2019

to11mtm commented Aug 29, 2019

YohanSciubukgian commented Sep 4, 2019

aix1 commented Sep 19, 2019

rickswah commented Sep 23, 2019

Tustra commented Sep 23, 2019

mihaimyh commented Oct 15, 2019

neosaldina commented Dec 20, 2019

llebout commented Dec 24, 2019

danmoseley commented Feb 28, 2020

neosaldina commented Mar 13, 2020

neosaldina commented Mar 13, 2020

Sapana-Khemkar commented Jul 26, 2022

archanox commented Jul 26, 2022

aix1 commented Aug 12, 2022 via email

tappehl commented Aug 12, 2022

aix1 commented Aug 12, 2022 via email

archanox commented Aug 12, 2022

Roman-Blinkov commented Aug 12, 2022 • edited Loading

tappehl commented Aug 12, 2022

afxgroup commented Aug 14, 2022

bencz commented Aug 14, 2022

afxgroup commented Aug 14, 2022 • edited Loading

bkeys commented Aug 28, 2022

tappehl commented Aug 29, 2022

bkeys commented Sep 2, 2022

tappehl commented Sep 3, 2022

kevincrans commented Sep 8, 2022 • edited Loading

kevincrans commented Sep 17, 2022

tappehl commented Sep 23, 2022

janani66 commented Sep 23, 2022

bkeys commented Sep 23, 2022 • edited Loading

janani66 commented Sep 23, 2022

bencz commented Jan 10, 2023

Sapana-Khemkar commented Jan 10, 2023

lehrbua commented Jan 10, 2023

bkeys commented Jan 10, 2023

nealef commented Jan 10, 2023

janani66 commented Jan 10, 2023 • edited Loading

Sapana-Khemkar commented Jan 16, 2023

neosaldina commented Jun 14, 2023

ghost commented Mar 29, 2018 •

edited by ghost

Loading

Roman-Blinkov commented Aug 12, 2022 •

edited

Loading

afxgroup commented Aug 14, 2022 •

edited

Loading

kevincrans commented Sep 8, 2022 •

edited

Loading

bkeys commented Sep 23, 2022 •

edited

Loading

janani66 commented Jan 10, 2023 •

edited

Loading