Open bencz opened 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.
@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.
@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.
@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
@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).
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
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
a Powerpc port would be really great 👍
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?
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.
Is it not possible to use the JIT used in the .net of xbox? Or rather use it as a starter?
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
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
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
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.
Do you also plan to support PPC 32 bits ?
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.
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
upvote
Any plans for AIX support? Lots of us are using AIX servers.
Is there any plan to start implementing the JIT for ppc, ppc64 or ppc64el ?
I also would like to run .NET Core on ppc64le. My workstation system runs Fedora with Linux.
There remains no plan for Microsoft support of AIX, but community work is welcome - FreeBSD has made contributions in this way.
Okay, Microsoft may not have plans to support AIX, but what about PowerPC ( ppc, ppc64 and ppc64le ) ?
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?
@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.
@marek-safar
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.
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.
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?
It depends on how weird is the new platform but in general, there should not be anything that cannot be changed.
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
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 ?
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.
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 :)
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
@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.
@Sapana-Khemkar Cool!!! Did you perform any tests on support for ppc64be?
Even a ppc32be would be great :)
@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
Even a ppc32be would be great :)
thats yet not in plan. currently only ppc64le is planned
@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 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
To avoid confusion
ppc64 = big endian ppc64el = little endian
Please avoid using non-standard nomenclature
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: @.***>
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
😊, 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: @.***>
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...
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
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!!
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?