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.

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.

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. 😉 )
(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...

@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. 😉

[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.

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