MIPS32 and MIPS64 support #4234
Comments
|
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. |
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. |
|
Let me expand that a bit: 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. |
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 are mistaken. This is not how it works. |
|
@jasonwilliams200OK I'm guessing a Microsoft customer in this context means a product group within Microsoft. Also, can you explain how 'it' works? |
|
@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. |
|
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. |
|
@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. |
|
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. |
Marcia, Marcia, Marcia! (Sorry, @kangaroo , couldn't resist. 😉 ) |
|
For the record: https://en.wikipedia.org/wiki/Loongson And it runs Java, Go, Ruby... |
|
@xied75, I started with Debian Jesse (MIPS) running on qemu-mips and converted AT&T 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. 😉 |
|
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. |
|
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. |
|
@jasonwilliams200OK I did a search on source: Only managed to find two .s files? Do we still somehow need to convert this first? @benpye Something I can do as a small enough task? |
|
@xied75, try with capital |
|
Porting PAL is reasonably straight forward, most of the architecture On Tue, 23 Aug 2016, 16:50 Dong Xie, notifications@github.com wrote:
|
|
Oh I was just converting the vm layer, there is also assembly code in PAL! Good luck to me.. :( |
|
do you have some good news about MIPS support? |
|
Any new developments? |
|
any updates on MIPS support? |
|
any updates on MIPS support? |
|
@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. |
|
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. |
|
any updates on MIPS support? |
1 similar comment
|
any updates on MIPS support? |
|
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, 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. :) |
|
Early Access (EA) Build of MIPS64 Port has been released. Feel free to provide any feedback. |
|
Is this a MIPS64-only port or is MIPS32 also supported? |
MIPS64R2 only |
|
@lmcdougald Just curious, as of today, what would be the typical/target MIPS32 solution/platform/CPU you have in mind? |
|
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. |
|
@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. |
|
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.
|
|
Some Tesla cars use MIPS. Its been more than a novelty for a long time. |
|
.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.
|
|
@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. |
|
@lmcdougald lol that's a very good point. |
|
I'm just venting but... @lmcdougald ".NET IL has existed longer than LLVM, so that’s a pretty weird critique." "Consumer MIPS32 processors are a novelty." @JakeSays "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" |
|
@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. |
|
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. |
|
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. |
|
@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." |
|
@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. |
|
@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. |
|
@zezba9000 name one runtime environment that has been retargeted and ready for production in under a month. |
|
@JakeSays Nim, Rust langs. Those compile to C89 & LLVM. |
|
@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. |
|
@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? |
|
@JakeSays ".net native was developed long before llvm was usable as a reliable jit platform" 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. |
|
@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). |
|
.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. |
|
mono MIPS32 O32 ABI is just able to work. |
|
??? |
and others
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
19991992. 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.
The text was updated successfully, but these errors were encountered: