CoreRT on macOS Big Sur / ARM / Apple Silicon

[christianscheuer]

Hi dear CoreRT community,

With Apple's announcement at WWDC this week, it's now clear that as soon as late 2020, there will be new Macs shipping to customers running on ARM / "Apple Silicon".

I suspect the status of CoreRT being able to run on ARM / Linux is currently at a very initial stage, if I am reading this issue tracker correctly:
#4856

Starting this thread to see if there's any user traction on getting CoreRT to also work on macOS Big Sur+ on ARM. We'd also be very interested in hearing about any other .NET 5 AOT solutions that could integrate with LLVM and would target macOS on ARM.

Maybe getting support for ARM on macOS would be prohibitively expensive / slow for the community and the small team of volunteer maintainers who have been so kind as to continue supporting this great tech. Or maybe you would gauge it to be achievable within say 6 months or so, in which case we could probably stay with CoreRT for our product on the Mac platform.

Any insight and input would be greatly appreciated :)

[jkotas]

We need to move to dotnet/runtimelab where the project can leverage the same engineering infrastructure (e.g. cross-compilation environment) as dotnet/runtime: dotnet/runtimelab#4

Once in dotnet/runtimelab, it should not be hard to get CoreRT up on running on ARM64. It was running on Windows ARM64 before, so the most of the code is there.

[christianscheuer]

Thank you so much for the quick reply, @jkotas. That's wonderful news.
We're getting the Universal Quick Start toolkit (the developer ARM mac mini) so will be able to run tests soon.

[RalfKornmannEnvision]

It was running on Windows ARM64 before, so the most of the code is there.

Was it generating ARM64 code or just ARM? I am asking because while I was working to get CoreRT generating code that work on they Nintendo Switch I noticed that most of the code in ILCompiler.Compiler/src/Compiler/DependencyAnalysis/Target_ARM64/ just throws NotImplementedException. So I needed to implement most of it to get my test program working. Beside of this I noticed that there were many more things missing to get ARM64/Linux working. The ObjectWriter didn't work. There were no information generated for the stack walk to get the GC working. There were other issues like running CoreRT on a Windows/X64 host but generating ARM64/linux based code.

Unfortunately thework on CoreRT port was stoped when there was a decision to stay with Mono even CoreRT was more than twice as fast in our Benchmark.

[MichalStrehovsky]

It's Windows ARM64 - .NET Native and CoreRT share a lot of code and ARM64 is a supported platform for .NET Native. The runtime itself (in src/Native/runtime) supports this and is well tested - we just don't build it that way.

The main difference between CoreRT and .NET Native is in the AOT compiler - the projects share a lot of code, but they're not the same. So some of the helpers in ILCompiler.Compiler/src/Compiler/DependencyAnalysis/Target_ARM64/ are implemented, but those that are specific to CoreRT just throw right now. The differences between the CoreRT and .NET Native AOT compilers mostly stem from different code generators - .NET Native uses the Visual C++ code generator, CoreRT uses RyuJIT. ObjectWriter is also specific to the RyuJIT-backed compiler - the Visual C++ code generator handles the object file writing for .NET Native.

@RalfKornmannEnvision do you have the changes you made to RyuJIT/CoreRT for Unix-y ARM64 in a branch somewhere? Would you be willing to contribute them?

[RalfKornmannEnvision]

It's Windows ARM64 - .NET Native and CoreRT share a lot of code and ARM64 is a supported platform for .NET Native. The runtime itself (in src/Native/runtime) supports this and is well tested - we just don't build it that way.

The main difference between CoreRT and .NET Native is in the AOT compiler - the projects share a lot of code, but they're not the same. So some of the helpers in ILCompiler.Compiler/src/Compiler/DependencyAnalysis/Target_ARM64/ are implemented, but those that are specific to CoreRT just throw right now. The differences between the CoreRT and .NET Native AOT compilers mostly stem from different code generators - .NET Native uses the Visual C++ code generator, CoreRT uses RyuJIT. ObjectWriter is also specific to the RyuJIT-backed compiler - the Visual C++ code generator handles the object file writing for .NET Native.

Make sense from this point of view.

@RalfKornmannEnvision do you have the changes you made to RyuJIT/CoreRT for Unix-y ARM64 in a branch somewhere? Would you be willing to contribute them?

I still have the changes and it was always the plan to contribute the non platform specify (XBox One, Playstation 4, Nintendo Switch) parts. Unfortunately there are still some open legal issues from our side that keep me from doing it. When I finally have the OK I need to check if it still works with all the changes on RuyJit and CoreRT that were made since I last touched it. Beside of this I am not sure if my changes will even work for a regular Linux as I tested everything only with the XBox, Playstation 4 and the Switch crosscompiled from a Windows x64 host.