4 ms·
Ah, that's a great hypothesis. I wonder, then, how it works with x86 emulation on ARM. IIRC, atomic ops on ARM fault if the address isn't naturally aligned... b
by anematode 6mo ago
Ah, that's a great hypothesis. I wonder, then, how it works with x86 emulation on ARM. IIRC, atomic ops on ARM fault if the address isn't naturally aligned... but I guess the runtime could intercept that and handle it slowly.
- BobbyTables2 6mo agoAn emulated x86 atomic instruction wouldn’t need to use atomic instructions on ARM.
- dooglius 6mo agoWhy not?
- MBCook 6mo agoThey don’t have to match. As an example, what about a divide instruction. A machine without an FPU can emulate a machine that has one. It will legitimately have to run hundreds/thousands of instructions to emulate a single divide instruction, it will certainly take longer. Thats OK, just means the emulation is slower doing that than something like add that the host has a native instruction for. In ‘emulator time’ you still only ran one instruction. That world is still consistent.
- anematode 6mo ago? That's not how Windows on ARM emulation works. It uses dynamic JIT translation from x86 to ARM. When the compiler sees, e.g., lock add [mem], reg presumably it'll emit a ldadd, but that will have different semantics if the operand is misaligned.
- deleted 6mo ago[deleted]
- cylemons 6mo agoYou mean the locking would be done in software?
- omcnoe 6mo agoARM macs apparently have some kind of specific handling in place for this when a process is running with x86_64 compatibility, but it’s not publicly documented anywhere that I can see.
- my123 6mo agoXNU has this oddity: https://github.com/apple-oss-distributions/xnu/blob/f6217f891ac0bb64f3d375211650a4c1ff8ca1ea/osfmk/arm64/sleh.c#L1756 https://github.com/apple-oss-distributions/xnu/blob/f6217f89... Redacted from open source XNU, but exists in the closed source version