Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

ARM already has instructions for improving performance of Javascript [1]. What if Apple added custom ISA extensions to their chips to support efficient x86 emulation? Current evidence seems to suggest that much of the translation is happening statically; a few additional instructions might greatly increase x86 emulation performance if most of the code can be translated instruction-by-instruction.

Also curious to see how Rosetta will work with x86 code whose instruction alignments can't be determined statically.

[1] https://stackoverflow.com/questions/50966676/why-do-arm-chip...



Apple's chips toggle TSO with a proprietary MSR; other than that there aren't really any other custom things going on.


TSO = Total Store Ordering.

(I didn't know what you were talking about at first, had to work it out.)


Is that so that the memory model is equivalent to X86?


Yep, exactly.


I think this is very unlikely as 1. Apple is still almost required to follow the ARM ISA as a result of its licensing agreement 2. They will regard x86 emulation as a short term legacy issue (developers will recompile their Apps for ARM soon) and so why design and build in extra hardware you won't need long term and 3. Rosetta 1 worked fine without this sort of help.


I don't agree that this is so farfetched. As noted in a sibling, Apple has released ISA extensions before. If the architecture is decoding to uops anyway the addition of x86 helper instructions may not affect the architecture much at all (or may even be implemented in microcode). Further, the comparison between Rosetta 1 and 2 may not necessarily apply, as the switch to intel was (arguably) a more substantial perf increase over POWER.


ARM licensing requires any vendor to approach ARM for permission to extend the ISA. ARM may well deny that request and instead make it part of the main ISA instead


Are we sure that applies to Apple in particular?

I presume the exact terms of Apple's license agreement with ARM are not public, so who knows exactly what is in it. It might have different terms from what ARM offers in the general case.


Apple execs had by far the upper hand while negotiating the contract than ARM execs did. The entire environment at the time was "we will do whatever apple wants".

Shortsighted really considering there weren't really any other options for instruction sets for apple to choose - all this stuff was signed before RISCV was a thing, and PPC and MIPS had pretty high barriers to entry (lots of porting work, lacking SIMD type instructions, and another migration for all apple devs) and poor performance.


I think 2. is the key point Apple will expect its developers to produce universal binaries very quickly. Once that has been done the issue has largely gone away. Plus not sure I agree that this is a smaller step up in performance when compared to POWER - certainly same order of magnitude.


True. As sibling noted below it sounds like there's no additional instructions used here.


Apple has already shipped custom instructions; they just aren't using them here.


Is there evidence that custom instructions aren't being used here? Keep in mind that they could have been added but not included in DTKs.


The build of Rosetta that will be used on the M1 has shipped already, I didn't see anything there (it looks largely identical to the DTK version).


I've seen this reported but am a bit sceptical - happy to be proven wrong.



Thanks!


all that "javascript" instruction does is emulate the x86 behaviour, which formed the basis of the javascript spec


People need to stop acting like that instruction is some amazing magical "make JS fast". Literally the only thing it does is to change the rounding mode and sentinel for NaNs.

That's it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: