Hacker News Reader

Comment by _ix | Hacker News Reader

Truly my own ignorance... help me out! Is this port strictly for Apple silicon, ~ARM64, or is that the same thing? Where would this leave support for say, AWS Graviton instances?

View on HN

PyPy already supports ARM64. This is additional work needed to support macOS 11 on M1. Apple changed some things that impact PyPy, like the register uses and ffi calling conventions. They updated clang to handle this, but PyPy's JIT emits assembler directly and so requires work to support M1.

> Apple changed some things that impact PyPy, like the register uses and ffi calling conventions.

I thought everyone who used 64-bit ARM used ARM's AAPCS64 (https://github.com/ARM-software/abi-aa/blob/master/aapcs64/a...), so the register usage and FFI calling convention should be the same as on Linux and Windows. What did Apple do differently that would affect the PyPy JIT?

There are some slight nuances that affect the JIT. https://developer.apple.com/documentation/xcode/writing_arm6...

Link is broken; asks user to enable remote code execution.

Please don’t call working links “broken”. It links to the right place, regardless of whether you like what happens when you get there.

In addition to a slightly modified ABI, Apple enforces W^X in hardware.

AFAIK, the only notable difference is with arguments spilled on the stack being packed on macOS (except variadic arguments). If all your arguments are int or larger, that means essentially no difference. (source: I worked on making Firefox work on M1. We didn't need changes to XPCOM, for instance, although theoretically, we'd need some. I don't think the JIT needed changes either. Funnily enough, I had to fix libffi for variadic arguments, and the libffi shipped in macOS is broken)

varargs in general is significantly different, I think it's even encoded as a char * in C++ name mangling.

Reply on news.ycombinator.com