dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
14.7k stars 4.59k forks source link

PowerPC and AIX support #10055

Open bencz opened 6 years ago

bencz commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 6 years ago

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

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 commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

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 commented 5 years ago

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 commented 5 years ago

a Powerpc port would be really great 👍

turabek commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

xiangzhai commented 5 years ago

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 https://github.com/dotnet/coreclr/pull/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 https://github.com/dotnet/coreclr/pull/20470 So is it able to enable Interpreter at master now?

Thanks, Leslie Zhai

mattwarren commented 5 years ago

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 commented 5 years ago

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 https://github.com/dotnet/coreclr/pull/11252

to11mtm commented 4 years ago

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 commented 4 years ago

Do you also plan to support PPC 32 bits ?

aix1 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

upvote

mihaimyh commented 4 years ago

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

neosaldina commented 4 years ago

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

llebout commented 4 years ago

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

danmoseley commented 4 years ago

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

neosaldina commented 4 years ago

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

neosaldina commented 4 years ago

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?

tmds commented 4 years ago

@janvorli @danmosemsft Mono requires interpreting for some platforms, and .NET Core and mono runtimes are coming closer together. Could we be moving in a direction where there is a production-grade .NET interpreter that can be built from source?

Though it would not perform as a good as a JIT, it would reduce the effort significantly to port .NET.

danmoseley commented 4 years ago

@marek-safar

NattyNarwhal commented 4 years ago

Mono interpreter requires per-platform trampolines, generated by the JIT. There was work from me and @lewurm to use the C based (but must be pregenerated) trampolines that WebAssembly uses (no JIT there) and fixing up the interpreter more, including making them endian and 64-bit pointer safe, but it wasn't complete.

I'm also still not clear on the whole .NET 5/Mono integration story and how exactly Mono comes into play with dotnet and actually building it. The portability story on the Core side of thing seems really ambiguous in general to me and reads as a lower priority, while Mono has traditionally picked up the slack there.

marek-safar commented 4 years ago

Mono interpreter is already part of this repo and there is ongoing effort to make it stable and supported (see #32754 for example).

@NattyNarwhal someone will need to make an effort to build relevant runtime packages of dotnet/runtime for such platforms. It's something the community can do and .NET team can help with in-terms of landing the changes or advising on the required changes.

tmds commented 4 years ago

Thanks @NattyNarwhal @marek-safar . It's good to know mono interpreter is in the repo, and you'll help community to get it working on unsupported platforms. Are there important limitations, besides speed, you are aware of?

marek-safar commented 4 years ago

It depends on how weird is the new platform but in general, there should not be anything that cannot be changed.

tappehl commented 2 years ago

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?

Hi, please reach out to me if this is still of interest. Things are happening with IBM and I would like to get in contact with ISV's interested in this.. mail torbjorn@builtonpower.com thanks

neosaldina commented 2 years ago

Any news about this ? I saw that @nealef migrated the Mono JIT for s390x to run .net on mainframe.. i can be possible to do this with ppc64 and ppc64le ?

aix1 commented 2 years ago

Hi

I know there are some work ongoing, and now some more “votes” for this.

The one I know working mostly on this now is another IBM Champion named Torbjörn Appehl, @.***

Check with him 😊

Have a good one

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.comhttp://www.ikea.com/

[signature_780672469]

From: neosaldina @.> Reply to: dotnet/runtime @.> Date: Tuesday, 30 November 2021 at 17:39 To: dotnet/runtime @.> Cc: Stephan Åkeborg @.>, Comment @.***> Subject: Re: [dotnet/runtime] PowerPC and AIX support (#10055)

Any news about this ? I saw that @nealefhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnealef&data=04%7C01%7Cstephan.akeborg2%40ingka.ikea.com%7Cae14d13ea5334a47975608d9b41ffa55%7C720b637a655a40cf816af22f40755c2c%7C0%7C0%7C637738871701333021%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=hfFd0X%2Fyxu8YJ9eLSOlH%2FIKmg3rB1S14S%2B79f8gpxGQ%3D&reserved=0 migrated the Mono JIT for s390x to run .net on mainframe.. i can be possible to do this with ppc64 and ppc64le ?

— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2Fruntime%2Fissues%2F10055%23issuecomment-982811873&data=04%7C01%7Cstephan.akeborg2%40ingka.ikea.com%7Cae14d13ea5334a47975608d9b41ffa55%7C720b637a655a40cf816af22f40755c2c%7C0%7C0%7C637738871701342978%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=q7%2BYllrY%2FGCH%2B3%2FAOF8F5fRtZUnXDxLR7Z%2BMeIwqywU%3D&reserved=0, or unsubscribehttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAH46N6BLKC5WSIPQEKEHOO3UOT437ANCNFSM4K5WE7UQ&data=04%7C01%7Cstephan.akeborg2%40ingka.ikea.com%7Cae14d13ea5334a47975608d9b41ffa55%7C720b637a655a40cf816af22f40755c2c%7C0%7C0%7C637738871701342978%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=pERUUmWWouOQKi12WCVaPycfp8E1J2Ukd5RAZyy5Yxk%3D&reserved=0. Triage notifications on the go with GitHub Mobile for iOShttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04%7C01%7Cstephan.akeborg2%40ingka.ikea.com%7Cae14d13ea5334a47975608d9b41ffa55%7C720b637a655a40cf816af22f40755c2c%7C0%7C0%7C637738871701352946%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=f9%2BjQTp8puPn6BUqPHMZ5R4j4HD6k%2FDddq5SzSfEkmE%3D&reserved=0 or Androidhttps://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04%7C01%7Cstephan.akeborg2%40ingka.ikea.com%7Cae14d13ea5334a47975608d9b41ffa55%7C720b637a655a40cf816af22f40755c2c%7C0%7C0%7C637738871701352946%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=FXh5wnXv1UGwtyWySHQjgHRdxAeiUH31lYmgJdy6g5Y%3D&reserved=0.

tappehl commented 2 years ago

Hi, is still of interest? IBM recently ported .NET 6 to s390 and I am on a crusade to make it happen on Power architecture as well :)

bencz commented 2 years ago

Absolutely yes! The good thing about using the Mono backend, as it was done with the s390, is that this port for ppc will also be compatible with older platforms, such as p5, p6 and p7

Sapana-Khemkar commented 2 years ago

@all, we have started work on porting .net on ppc64le. Major PRs has been merged to runtime repository. There are three issues on which we are currently working https://github.com/dotnet/runtime/issues/71080 https://github.com/dotnet/runtime/issues/71079 https://github.com/dotnet/runtime/pull/71189

If anyone has any suggestions/input on these issues please update.

neosaldina commented 2 years ago

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

afxgroup commented 2 years ago

Even a ppc32be would be great :)

Sapana-Khemkar commented 2 years ago

@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 https://github.com/dotnet/runtime/issues/71080 and https://github.com/dotnet/runtime/issues/71079

Sapana-Khemkar commented 2 years ago

Even a ppc32be would be great :)

thats yet not in plan. currently only ppc64le is planned

neosaldina commented 2 years ago

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

Sapana-Khemkar commented 2 years ago

@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 commented 2 years ago

To avoid confusion

ppc64 = big endian ppc64el = little endian

Please avoid using non-standard nomenclature

aix1 commented 1 year ago

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.comhttp://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 GitHubhttps://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 unsubscribehttps://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 commented 1 year ago

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 commented 1 year ago

😊, 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.comhttp://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 GitHubhttps://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 unsubscribehttps://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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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!!