Runtime: MIPS32 and MIPS64 support

[ghost]

Apple brought 64-bit support to ARM in 2011. Other vendors (Nvidia, Qualcomm) are bringing 64-bit ARM architecture in 2015.

However, MIPS has 64-bit support since 1999 1992. Linux and old Windows Mobile and Windows CE operating systems support MIPS for long time. But Windows 10 for _everything_ doesn't support MIPS! We definitely live in the world of monopoly..

Would be really handy if CoreCLR and CoreFX folks along with microframework (https://github.com/NETMF/netmf-interpreter) continue to support for MIPS32 and 64 architectures for the love of technology widespread in open world.

Love for MIPS

Thank you.

[OtherCrashOverride]

I don't believe its an issue of ideology that MIPS is excluded, rather, its an issue of pragmatism: there are no customers targeting MIPS hardware.

CoreCLR is open source. There is nothing preventing Imagination Technologies (the owners of MIPS) from adding support for their processors to it. Imagination Tech is a large company with plenty of financial resources. There is no need for them to depend on "technological welfare" for support of their products.

[ghost]

there are no customers targeting MIPS hardware.

I suspect that you missed (not really) the news (anymore) that Android is supported on MIPS and there are MIPS based tablets running Android and the development is still ongoing of such devices.

[OtherCrashOverride]

Let me expand that a bit:
there are no [Microsoft] customers targeting MIPS hardware.

I am all for MIPS support. I am simply pointing out that current lack of support is not due to any evil agenda. Further more, MIPS support is not dependent on Microsoft. Anyone, including Imagination Tech, can add it. You should email or post to their forums your interest in using CoreCLR on devices containing their product.

[ghost]

there are no [Microsoft] customers targeting MIPS hardware.

How can you be so sure about that? I am a Microsoft customer and I own a MIPS-based tablet and would love to run .NET apps on my device.

You should email or post to their forums your interest in using CoreCLR on devices containing their product.

You are mistaken. This is not how it works.

[jakesays-old]

@jasonwilliams200OK I'm guessing a Microsoft customer in this context means a product group within Microsoft. Also, can you explain how 'it' works?

[kangaroo]

@jasonwilliams200OK is 100% correct. Thats not how it works. How it works is if people are particularly passionate about a new platform or architecutre, they should submit pull requests. I'm happy to review any and all PRs for MIPS support. I have a MIPS box in the garage that I can validate on.

[benpye]

I'm guessing there isn't really any documentation on the process of doing JIT bringup on a new platform? MIPS would certainly be interesting, but I'm guessing not something MS would want to invest time in since it's not really targeted by any of their products. I'm not too sure what would have to be done to get the JIT working on a new architecture, from the current code base, though it would be impressive if done as a community project.

[terrajobst]

@kangaroo and @jasonwilliams200OK are correct. This is an open source project. It's by definition a collaboration with various individuals as well as companies. The code base you currently see is the actual product code that the CLR group at Microsoft produced over last 15 years. It's obviously based on the business interests that Microsoft had in the past.

As far as our future interest and thus investment goes: we already announced that we're going to support this runtime on non-Microsoft platforms. But pragmatically speaking, we (even though that may be hard to believe for some folks) don't have infinite resources to "simply" support CoreCLR everywhere. We do, however, want to work with others to port the code to more platforms. Our level of commitment will certainly vary based on roadmap, priorities, and overlap with other projects we're already working on.

That being said, it doesn't mean that we wouldn't accept PRs for platforms that Microsoft currently isn't interested in. It simply means that the community has to provide folks that are willing to maintain the architecture to a degree that it makes sense to be part of this repository. Not only is this pattern an option -- it's highly desired!

We know for a fact that .NET is much bigger than just Microsoft. So please keep the suggestions for ports coming. There are many highly skilled and passionate people that care and are willing to collaborate -- as @kangaroo just proved by offering code reviews as well as validation.

[zezba9000]

I posted a suggestion in the .NET Foundation forums about Open Sourcing key parts of .NET Compact that has already has run on MIPS, PPC, ect for years: http://forums.dotnetfoundation.org/t/open-source-net-compact-runtime/1190

I think being able to use it as references source would greatly help the efforts of this topic. If i'm right you might consider voicing this suggestion as well :)

Even if it ended up not helping much couldn't hurt anything to have it available.

[OtherCrashOverride]

@kangaroo and @jasonwilliams200OK are correct.

Not only is this pattern an option -- it's highly desired! [http://blogs.msdn.com/b/dotnet/archive/2015/07/14/first-net-port-award.aspx]

There are many highly skilled and passionate people that care and are willing to collaborate -- as @kangaroo just proved by offering code reviews as well as validation.

Marcia, Marcia, Marcia!

(Sorry, @kangaroo , couldn't resist. :wink: )
(For those not familiar with the reference: https://www.youtube.com/watch?v=w2fXs3bf-p0 "The Brady Bunch: Marcia, Marcia, Marcia! ")

[xied75]

For the record: https://en.wikipedia.org/wiki/Loongson
The 3A2000 model CPU is on sell on a mini-itx motherboard http://www.lemote.com/html/product/miniitx/2015/1230/28.html
The performance is on par of Intel Ivy-Bridge generation.

And it runs Java, Go, Ruby...

[ghost]

@xied75, I started with Debian Jesse (MIPS) running on qemu-mips and converted AT&T .S assembly code in CoreCLR repo to its MIPS counterpart. There are couple of SIMD instructions which are different in (and some inherently not required by) MIPS which need some serious MIPS assembly darkarts which i lack.. If you have affluent knowledge about MIPS assembly, do contribute! :)

More on the devices; there are many interesting devices posted on their blog https://imgtec.com/blog/, most of them are SOC board, arduinos, and internet of things kinda solutions. And now there is even an All-in-one PC: http://www.pcworld.com/article/3040528/computers/this-russian-all-in-one-desktop-is-just-weird-enough-to-be-interesting.html --happened just around the 25th anniversary of 64-bit MIPS architecture and 35th year overall. :wink:

[benpye]

First step would be to get PAL working on MIPS, that should be fairly easy. Getting the JIT on MIPS would be quite a bit of work, I guess there is the interpreter fallback, which would be useful during bring up, but it would probably make sense to wait for RyuJIT to work well on x86 or ARM before trying to get another 32-bit platform working. I know there is MIPS64 but I'm pretty sure it'd a strict superset so a MIPS32 port seems to make more sense.

[ghost]

@benpye, thanks! :)

For the first step:

• should we only configure cmake under PAL?
• can we run PAL tests as well without building JIT?
• any further advice on getting the JIT interpreter fallback up and running?

[benpye]

PAL and the PAL tests are pretty much standalone, they will work without the rest of coreclr. You will have to modify the top level CMakefile somewhat, I'd look through for the ARM defines and add suitable ones for MIPS. You could make it so that for MIPS only PAL was built.

To get the JIT up and running you'd have to ask @dotnet/jit-contrib , there is https://github.com/dotnet/coreclr/blob/master/Documentation/botr/porting-ryujit.md but it's a pretty high level overview. A community JIT port would certainly be very impressive.

[xied75]

@jasonwilliams200OK I did a search on source:

root@da1f6193b184:~/github/coreclr# find . -name "*.s"

Only managed to find two .s files?

./src/pal/tests/palsuite/composite/synchronization/nativecs_interlocked/sparcinterloc.s
./src/pal/tests/palsuite/composite/synchronization/nativecs_interlocked/hpitinterlock.s

Do we still somehow need to convert this first?

@benpye Something I can do as a small enough task?

[ghost]

@xied75, try with capital .S. Building PAL on MIPS is the first step, which shouldn't require this conversion.

[benpye]

Porting PAL is reasonably straight forward, most of the architecture
specific files are in
https://github.com/dotnet/coreclr/tree/master/src/pal/src/arch though there
are various defines and ifdefs that may need updating.
https://github.com/dotnet/coreclr/blob/master/src/pal/src/exception/seh-unwind.cpp
has a lot of architecture specific code too. If you have more specific
questions I can try and give pointers from what I remember with porting PAL
to ARM.

On Tue, 23 Aug 2016, 16:50 Dong Xie, [email protected] wrote:

@jasonwilliams200OK https://github.com/jasonwilliams200OK I did a
search on source:

root@da1f6193b184:~/github/coreclr# find . -name "*.s"

Only managed to find two .s files?

./src/pal/tests/palsuite/composite/synchronization/nativecs_interlocked/sparcinterloc.s
./src/pal/tests/palsuite/composite/synchronization/nativecs_interlocked/hpitinterlock.s

Do we still somehow need to convert this first?

@benpye https://github.com/benpye Something I can do as a small enough
task?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/coreclr/issues/969#issuecomment-241779501, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAbA_-1MBcwd8ghAilgBbOqE78y-mgieks5qixacgaJpZM4EU3NU
.

[ghost]

Oh I was just converting the vm layer, there is also assembly code in PAL! Good luck to me.. :(

[d0apga]

do you have some good news about MIPS support?

[geffzhang]

Any new developments?

[ievdokdm]

any updates on MIPS support?
I need it to run on MIPS 24Kc processor

[myFirstway]

any updates on MIPS support?

[zezba9000]

@myFirstway @ievdokdm I'm working on a project (in early stages) to solve issues like this more quickly: https://github.com/reignstudios/IL2X

I can compile on MIPS right now but the runtime needs a lot more work done before its ready for general use.

[mms-]

Was about to use .Net Core for our embedded app, but this is a show stopper. On top of ARM32 and soon ARM64 we need MIPS support and that requirement doesn't seem to be changing anytime soon. Go and Rust do support MIPS.

[liujianm]

any updates on MIPS support?

[ibbcall]

any updates on MIPS support?

[BruceForstall]

Microsoft currently has no plans or work in progress to support MIPS. Of course, we would be willing to accept external contributions towards that goal as appropriate. Note that it is, certainly, a significant amount of work to port .NET Core to a new platform.

[theaoqi]

We (Loongson) are trying to port .NET Core (2.1 now, then will update to master) to MIPS64 and have just started this work recently. @liujianm @ibbcall

[am11]

@theaoqi, just FYI, the master branch builds with GCC as well as Clang, while release/2.1 only builds with Clang. I am using master for SmartOS (Solaris) amd64 port work. :)

[redfox105]

We (Loongson) are trying to port .NET Core (2.1 now, then will update to master) to MIPS64 and have just started this work recently. @liujianm @ibbcall

Is there a release plan?

[theaoqi]

@theaoqi, just FYI, the master branch builds with GCC as well as Clang, while release/2.1 only builds with Clang. I am using master for SmartOS (Solaris) amd64 port work. :)

Thanks! I didn't know that and will consider this:)

[theaoqi]

We (Loongson) are trying to port .NET Core (2.1 now, then will update to master) to MIPS64 and have just started this work recently. @liujianm @ibbcall

Is there a release plan?

Not yet. Although we have some experience with porting OpenJDK to MIPS64, but we are not familiar with .NET. This is huge work, I cannot give a plan now.

[zhengwb]

We (Loongson) are trying to port .NET Core (2.1 now, then will update to master) to MIPS64 and have just started this work recently. @liujianm @ibbcall

It is recommended to do this based on the latest version.

[liujianm]

We (Loongson) are trying to port .NET Core (2.1 now, then will update to master) to MIPS64 and have just started this work recently. @liujianm @ibbcall

Thank you for the good news.
We want to run .netcore application on MIPS64(Loongson).
Hope to support in the latest version(3.0 will be released in September).
Looking forward to your good news.

[myFirstway]

We (Loongson) are trying to port .NET Core (2.1 now, then will update to master) to MIPS64 and have just started this work recently. @liujianm @ibbcall

Is there a release plan?

Not yet. Although we have some experience with porting OpenJDK to MIPS64, but we are not familiar with .NET. This is huge work, I cannot give a plan now.

What's the progress now?

[kchanlee]

Looking forward to seeing .Net Core running on Loongson! @theaoqi Could you share the progress?

[theaoqi]

The code base was upgraded to 3.0. Hello World and serveral tests in coreclr can run on MIPS64 now. @kchanlee @myFirstway @liujianm

[BruceForstall]

@theaoqi It appears you are not pushing MIPS-related changes back to GitHub (or at least, not back to master)?

Are you using the interpreter, or are you porting RyuJIT?

Is there an overall MIPS porting plan documented here, in the coreclr repo?

Please be aware of the repository consolidation plan described here: https://github.com/dotnet/coreclr/issues/27549

[theaoqi]

@theaoqi It appears you are not pushing MIPS-related changes back to GitHub (or at least, not back to master)?

Not open souce yet :(

Are you using the interpreter, or are you porting RyuJIT?

We skipped the interpreter and are porting JIT now. We found that interpreter doesn't work very well even on x86.

Is there an overall MIPS porting plan documented here, in the coreclr repo?

No.

Please be aware of the repository consolidation plan described here: dotnet/coreclr#27549

Thank you very much for the information. I will be continuing concern over this issue. We plan to release 3.x (maybe 3.1) then catch up master. For 3.x, the repository consolidation doesn't affect us, right?

[BruceForstall]

For 3.x, the repository consolidation doesn't affect us, right?

That's correct. The released product and servicing branches will remain as-is.

We skipped the interpreter and are porting JIT now. We found that interpreter doesn't work very well even on x86.

Interesting. We've found in the past that using the interpreter allows us to bring up an architecture faster, or at least allows people to work in parallel, so everyone is not waiting on the JIT port to make progress. It's true that we haven't kept the interpreter building and being tested recently, so it has probably degraded. At one point it would successfully run well over 95% of our outerloop tests.

[theaoqi]

We skipped the interpreter and are porting JIT now. We found that interpreter doesn't work very well even on x86.

Interesting. We've found in the past that using the interpreter allows us to bring up an architecture faster, or at least allows people to work in parallel, so everyone is not waiting on the JIT port to make progress. It's true that we haven't kept the interpreter building and being tested recently, so it has probably degraded. At one point it would successfully run well over 95% of our outerloop tests.

Maybe we should do some research and test about interpreter again as our knowledge about coreclr and code quality are growing. Is pure interpreter supposed to work? Or dose it have to be interpreter and jit mixed? @xiangzhai may give more details.

[BruceForstall]

Is pure interpreter supposed to work?

It should. However, it is not being actively tested right now, so I don't know how much "bit rot" needs to be repaired.

During bring-up, you do need to set a few variables, e.g.:

COMPlus_InterpreterDoLoopMethods=1   // allow the interpreter to run on functions with loops
COMPlus_GCgen0size=9999999 // prevent the GC from running very often; useful for bring-up

Check the other COMPlus_Interpret* variables in src\inc\clrconfigvalues.h -- some others might be necessary or useful.

[xiangzhai]

Hi @BruceForstall

Please look at this issue https://github.com/dotnet/coreclr/issues/24824 about TOTALLY disable JIT.

Thanks,
Leslie Zhai

[xiangzhai]

\cc @QiaoVanke

[whuanle]

What is the current progress?I will soon have a MIPS server ,I need to run .NET Core programs.

[theaoqi]

What is the current progress?I will soon have a MIPS server ,I need to run .NET Core programs.

please see https://github.com/dotnet/coreclr/issues/969#issuecomment-550129085

[jinyuttt]

@theaoqi How is the situation? Is it possible to develop and deploy the project? Is there any progress and plan? Can you also provide your email? My account information has my email

[theaoqi]

@theaoqi How is the situation?

We are still working on the MIPS port. More than 9000 tests in coreclr has passed on MIPS (near 9700 in total). Our current main problems are GC and some others. We will use various COMPlus_* parameters to do more tests next, and will try some other tests such as the ones in corefx. Our codebase is 3.0 at present. We plan to release 3.1 first (3.0 may be skipped), and then catch up master in dotnet/runtime.

Is it possible to develop and deploy the project?

Do you mean .NET Core applications? I think yes. We wish to release .NET Core MIPS port this year, but I can't promise. Before the GA version, we may release some EA builds or RCs for test.

Is there any progress and plan?

As mentioned above. However, we hope to hear opinions and suggestions, and the plan is subject to change.

Can you also provide your email? My account information has my email

[email protected]

Thanks.

[xiangzhai]

Hi,

FlightFinder sample is just able to work for MIPS64 now :)

# CoreFX && AspNetCore ALLIN1
export CORE_LIBRARIES=/home/loongson/corefx-3.1-Linux.mips64.Debug
# Optimization Disabled
export COMPlus_JITMinOpts=1
./bin/Product/Linux.mips64.Release/corerun /home/loongson/aspnet-samples/samples/aspnetcore/blazor/FlightFinder/FlightFinder.Server/bin/Debug/netcoreapp3.1/FlightFinder.Server.dll --urls http://10.2.5.91:5000

Cheers! 🍷 @theaoqi @QiaoVanke @jkotas @BruceForstall @janvorli

We need some open source aspnet projects or samples much more complex than FlightFinder to test CoreCLR for MIPS64.

Thanks,
Leslie Zhai

[BruceForstall]

@xiangzhai Congratulations on the good progress!

Do you have any plan to open source your work and merge it back into the master branch?

[xiangzhai]

Hi @BruceForstall

Yes, we will open source ASAP! And we will migrate to 5.x (the master) branch.

Cheers,
Leslie Zhai

[xiangzhai]

Hi @BruceForstall

Do you have any plan to open source your work and merge it back into the master branch?

There is a trivial issue when try to migrate to 5.x (the master) branch. Please review it.

Thanks,
Leslie Zhai

[xiangzhai]

Hi @BruceForstall

I found that LLDB+diagnostics often be used for hunting GC issues, but I have no idea why LLDB hang for ARM64 and MIPS64 https://github.com/dotnet/runtime/issues/37405 Please give me some hints.

Thanks,
Leslie Zhai

[theaoqi]

We're excited to announce that our CoreCLR MIPS64 Port has been open-sourced. #38069

[geffzhang]

@theaoqi It's a great moment. Congratulations on the progress!

[theaoqi]

Early Access (EA) Build of MIPS64 Port has been released. Feel free to provide any feedback.

[lmcdougald]

Is this a MIPS64-only port or is MIPS32 also supported?

[xiangzhai]

Is this a MIPS64-only port or is MIPS32 also supported?

MIPS64R2 only

[xied75]

@lmcdougald Just curious, as of today, what would be the typical/target MIPS32 solution/platform/CPU you have in mind?

[lmcdougald]

Maybe it's unrealistic due to how old its kernel is, but I have an Imagination Technology Creator CI20 that I haven't used too recently that I'd be happy to build on and test my code/apps against. It's probably the most common MIPS development board in the US. It never got upstreamed though as far as I know and uses kernel 3.18, so not exactly worth porting to unless there's other MIPS32 targets people care about.

Given the timing of the original issue (about a month after the CI20 launched), that's probably the board the original poster has as well.

[xied75]

@lmcdougald Thanks a lot for the detailed answer. I agree with you. I believe the community would be willing to do the porting if there is a current popular hardware that's easy to get hands on. Until that's clear for the MIPS32 (as in "which" board), I guess the case needs to be rested for now. Another thought, for someone who might get interested at a random time space, using the MIPS64R2 port as a base could be helpful, there got to be lots shared in common.

[lmcdougald]

To be clear, it’s still easy to get the Creator CI20. ImgTech really thought they were going to compete at the same scale as ARM in smartphones and tablets, and produced tons of these boards. New CI20 boards can be purchased for a bit over MSRP. However, there’s no compelling story for the MIPS32 platform beyond novelty in the consumer space ever since MIPS and ImgTech split up.

[zezba9000]

Some Tesla cars use MIPS. Its been more than a novelty for a long time.
I don't think runtimes should be hard to port unless they're trying to re-invent the wheel as is the case with the .NET JIT instead of it using LLVM. Sadly when .NET Core started it wasn't based on more portable asm code gens that have been around for years like LLVM. Not to mention how much better this is for AOT.

[lmcdougald]

.NET IL has existed longer than LLVM, so that’s a pretty weird critique.

Consumer MIPS32 processors are a novelty. They have not shipped for years in any general purpose computing products beyond a few tablets (and maybe one or two poorly-selling phones) around the same time as the CI20 board. That makes them a novelty in the consumer space. There’s tons of automotive platforms with very obscure hardware and software.

The MIPS64 port is nearing completion from the sounds of it. If any new consumer products use MIPS, they hopefully will use MIPS64.

[JakeSays]

@zezba9000 there was an attempt at using llvm as an aot backend for .net core. The project was called LLILC. Apparently LLVM would have required too many changes to work right or something like that.

But more importantly LLVM makes for a poor JIT as it is relatively show at generating code, and JIT support is not considered as a primary use case for LLVM.

[JakeSays]

@lmcdougald lol that's a very good point.

[zezba9000]

I'm just venting but...

@lmcdougald ".NET IL has existed longer than LLVM, so that’s a pretty weird critique."
-- That has nothing to do with IL but rather assembly code gen from that IL (you can do this with almost anything). LLVM has been around a lot longer than .NET Core was the point.

"Consumer MIPS32 processors are a novelty."
-- I understand MS only cares about what they only care about.. (pointless re-inventing of the wheel with everything is a pattern in the .NET world & it frustrates a lot of ppl not just me). I think this is a day-1 design flaw as it clearly requires people to re-invent a lot of what LLVM already does better from what I know.

@JakeSays "The project was called LLILC. Apparently LLVM would have required too many changes to work right or something like that."
-- Point is .NET Core should have started with LLVM IMO then this wouldn't have been an issue and AOT would have been a lot better which has been a big problem with .NET for years.

"But more importantly LLVM makes for a poor JIT"
-- Then improve LLVM instead of re-creating a worse version of it. So much wasted time.

[JakeSays]

@zezba9000 Microsoft already had excellent JIT technology - switching to LLVM would be re-inventing the wheel. .net core was not a green field project. it was based on an existing runtime (the silverlight clr, actually), with existing JIT's, etc.

[BruceForstall]

You can read about the LLILC project journey and challenges here: https://github.com/dotnet/llilc/blob/master/Documentation/llilc-at-six-months.md. There are many engineering challenges that would need to be overcome for LLILC to approach the benefits of the .NET JIT, and it wasn't clear that it was even possible to get there even with extraordinary effort. At the time when LLILC was being actively invested in, .NET didn't have tiered compilation, which might change the calculus somewhat, at least for higher tiers (throughput might be less of an issue). But LLVM was still missing many fundamentals for .NET codegen.

[reflectronic]

There is a reason why Microsoft ditched JIT64. It was based off of the VC++ optimizing compiler backend, in a similar way to using LLVM. If they could not "fix" their own product, then saying "just fix LLVM" won't work either.

[zezba9000]

@JakeSays The original CF fork of .NET runtime supported MIPS, SPARC, ARM, PPC (I think), big-endian, etc, etc. Silverlight was a fork of CF... everything was a fork instead of just improving a single runtime & platform & independent UI framework lol (Mono did all the work MS was forced into accepting was needed). It took what MS 10-15 years for them to finally realize no one else was doing it the way they were. Sometimes I just want to pull my hair out thinking about how much MS denied the relevancy of Mono for so long. Designing a runtime to fix only short term problems will bite you in the a**... something Mono understood. If only MS had backed that 10 years ago...

@BruceForstall "But LLVM was still missing many fundamentals for .NET codegen."
-- Really then why does Mono support it in JIT and AOT?

[JakeSays]

@zezba9000 microsoft develops products to meet the needs of their customers at a particular point in time. each of the runtime forks that you complain about met different needs at different times. furthermore, you cannot assume they were forks. more than likely they were all from the same code base, just built differently for different use cases (just look for FEATURE_* defines). it is entirely possible that .net core is the first real fork.

Mono is a totally different implementation of .net. it had different goals, etc. Also it took mono a very long time to get llvm support to function reliably.

[zezba9000]

@reflectronic And yet again MS makes .NET Native (a crazy fast AOT) but o wait! Thats right its based off VC++ backend instead of LLVM. Not only does it not run on anything but Windows, it only supports WinRT LOL. This strategy of solving things as if everything is a short term problem only relevant in the Windows eco system MS deems relevant in some narrow cash grab vision at the time is beyond frustrating at this point.

Meanwhile I just watch every other AOT lang able to target just about anything new within a couple weeks or month its sad.

[JakeSays]

@zezba9000 name one runtime environment that has been retargeted and ready for production in under a month.

[zezba9000]

@JakeSays Nim, Rust langs. Those compile to C89 & LLVM.
Portable & fast as hell.

[JakeSays]

@zezba9000 you also need to consider timelines. .net native was developed long before llvm was usable as a reliable jit platform, as jit has never been a priority of llvm. matter of fact, it was the result of an experiment by Lattner just to see if it would work.

Your comparison of llvm and microsoft's jit/aot solutions isn't valid.

[JakeSays]

@zezba9000 those languages were built on top of llvm from the ground up (or at least rust was). again, not at all a valid comparison. microsoft has a huge investment in .net (in the billions). why would you expect them to start from scratch just to take advantage of llvm?

[zezba9000]

@JakeSays ".net native was developed long before llvm was usable as a reliable jit platform"
-- That sentence doesn't make any sense. .NET Native is AOT and there is no JIT. LLVM was around way before .NET Native was made.

Also again LLVM used for JIT argument is ONLY for .NET Core... which Mono even supports so don't tell me its not possible. Its more than possible its proven & is the basis for .NET AOT solutions.

Anyway love C# just hate the runtime & UI nightmares that have pledged it for years and years.

[JakeSays]

@zezba9000 the llilc project was proved that llvm wasn't a viable solution for .net core. the changes needed to llvm were substantial.

I never said it was not possible - just that it doesn't make sense.

and forgive me for using jit instead of aot, but with llvm they are the same thing. i've been using llvm since v1.8, and i can tell you that using it as an aot compiler is a lot more complicated than using it as a static backend for a compiler (c/c++, etc).

[reflectronic]

.NET CF had a "dumb JIT." It was basically a set of predetermined code blocks that were translated straight from IL, with no additional passes. Using something like this for server-class applications would be a performance disaster. Silverlight got the JIT and all of its optimizations from .NET Framework at some point.

Mono supports LLVM, but it has certain quirks. It uses conservative GC and does not properly support all exception behaviors. Issues like these make it okay for places where Mono is necessary, but not general enough for CoreCLR's purposes. This is still ignoring the throughput problems it causes for the (perfectly valid) JIT scenario.

[xiangzhai]

mono MIPS32 O32 ABI is just able to work.