ChakraCore
ChakraCore copied to clipboard
Support lacking for Apple Silicon (ARM)
On ARM macOS (all versions), ./build.sh --icu=/opt/homebrew/opt/icu4c/include -j=4 -y --lto-thin leads to:
CMake Error at CMakeLists.txt:47 (message):
Couldn't detect target processor, try `--arch` argument with build.sh
Non-windows arm support needs work, this has been an issue for some time but we couldn't find any free online environment to test ARM.
I also currently don't own an ARM device to experiment with - I'm hoping to purchase one soon which may enable me to develop arm support, though getting ARM into CI will be another issue. (EDIT: I should have a new macOS ARM device by the end of the month and getting CC to compile on it will be one of my first priorities)
@ppenzin I think we discussed this at some point but I can't now remember
See #6532 and #6468
UPDATE: I now have an Apple silicon device and have begun working on this. Various defines to update, hopefully very little actual code to change but will see.
Going to take slightly longer than I hoped - there's quite a bit of architecture dependent thread handling inside PAL which is currently used in Linux and macOS builds, it has no logic for ARM; and bringing in code to handle ARM is a more than trivial task - hopefully will take days rather than weeks but will see.
In an ideal world would simply remove PAL thread handling and use native linux & macOS APIs (or xplat posix APIs) though not sure whether that would be eaiser or harder than updating the PAL code.
chakracore's PAL is a fork of https://github.com/dotnet/runtime/tree/main/src/coreclr/pal that was never really kept in sync. Given that coreclr supports apple silicon, it might be a more beneficial task to investigate updating the PAL
chakracore's PAL is a fork of https://github.com/dotnet/runtime/tree/main/src/coreclr/pal that was never really kept in sync. Given that coreclr supports apple silicon, it might be a more beneficial task to investigate updating the PAL
Thanks for the suggestion - I looked at this before and the amount of divergence was such that I thought it would be more pain than it was worth, though I'm hoping I can bring in some of the code from there rather than updating the whole thing.
I discovered that the amount of divergence in PAL is pretty maddening when I tried to build on FreeBSD (which is another platform which PAL supports, while CC does not). I am not sure if there is an overarching reason behind that or if it just two copies gradually getting different changes.
I've started working on updating a few parts of it - I've also found other parts where ARM64 code in the wider codebase is windows only - though it's little bits here and there, very much hoping to be able to complete this task (apple silicon support) but it's not just changing a handful of conditionals as I'd hoped...
In my offline version the build currently gets to 60% before error-ing out.
I've started working on updating a few parts of it - I've also found other parts where ARM64 code in the wider codebase is windows only - though it's little bits here and there, very much hoping to be able to complete this task (apple silicon support) but it's not just changing a handful of conditionals as I'd hoped...
In my offline version the build currently gets to 60% before error-ing out.
Have you made any progress on this task?
I've started working on updating a few parts of it - I've also found other parts where ARM64 code in the wider codebase is windows only - though it's little bits here and there, very much hoping to be able to complete this task (apple silicon support) but it's not just changing a handful of conditionals as I'd hoped... In my offline version the build currently gets to 60% before error-ing out.
Have you made any progress on this task?
Yes, I've done more but there's still a ways to go - the code base has various places requiring change. Some code within the source tree required for macOS doesn't support ARM and some code required for ARM doesn't support macOS. I'm making progress slowly but it's still going to be a little while.
Lots of progress, with the Jit disabled I can now build chakraCore on apple silicon and it runs some things, though crashes if the code uses eval or with time travel debug.
I'll aim to have a PR open with an initial draft (not release ready) implementation of apple silicon support in the next week or two, hopefully something more complete will follow in the not too distant future.
My draft implementation at #6869 has a few bugs left to work out but seems ~99% functional with --no-jit supplied when it's built. Hopefully will sort out those bugs in the next week or two then begin on jit support.
If anyone wants to try chakracore on apple silicon feel free to checkout that fork and give it a try - though it's still experimental/WIP I can not yet recommend any use in any end product/production.
Draft implementation now seems to be fully working with JIT disabled, I'm beginning to work on the JIT now.
That's funny, I started working on this for fun recently and didn't know about this effort, but now that I came looking the current PR is ahead of me. I got interpreted passing other than with concurrent GC. Rough version in https://github.com/tcare/ChakraCore/tree/arm64.
That's funny, I started working on this for fun recently and didn't know about this effort, but now that I came looking the current PR is ahead of me. I got interpreted passing other than with concurrent GC. Rough version in https://github.com/tcare/ChakraCore/tree/arm64.
Ah, sorry about the duplicated effort, though I'd greatly appreciate any comments/feedback you have on my PR. I haven't hit a problem with concurrent GC, so I wonder if I fixed an issue by chance or if my testing is insufficient.
I was planning to answer @ppenzin's review points and merge the PR tomorrow.
Interpreter only support is landed in master.
JIT is tba.