The wasm ARM64 support has landed. A few points about that: Wasm stresses the ARM64 simulator in new ways; when hacking on the ARM [sic] simulator (especially for Wasm, especially for signals-related issues), please also port pertinent changes to the ARM64 simulator.
Test coverage for ARM64 is not yet good. We run some tests on the simulator on linux-64, and we test-compile Firefox for ARM64 hardware (Android) but don't yet run any tests on hardware. There's an effort underway to fix that, ETA mid-April, will probably involve running tests on an Android cloud farm. In the mean time I'll run weekly tests on hardware locally. Push() and Pop() are weird on ARM64. The JS baseline works around that by using a separate stack pointer. The wasm baseline and wasm stubs code however use the native SP and basically cannot use raw Push and Pop -- Jit engineers beware. --lars On Fri, Feb 2, 2018 at 8:35 AM, Lars Hansen <lhan...@mozilla.com> wrote: > There's an effort underway to get full spidermonkey support on ARM64. The > JS baseline mostly works already (not my doing); I'm working on wasm > baseline to complement it. Full optimizing jits are for "later" (hi, > Jakob). > > Anyhow there's now a new ARM64 platform in bugzilla and bugs might start > showing up tagged with that platform; also please use it when filing > ARM64-related issues. > > My impression of our ARM64 simulator so far is that it is pretty good; I > have seen some failures on hardware that don't show up on simulator, and > the generated code is very occasionally different for the simulator, but I > expect that for day-to-day development work the simulator is adequate. > > --lars > > _______________________________________________ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
