5 ms·

> 4/ So Apple simply cheated. They added Intel's memory-ordering to their CPU. When running translated x86 code, they switch the mode of the CPU to conform to I

by titzer 6y ago

> 4/ So Apple simply cheated. They added Intel's memory-ordering to their CPU. When running translated x86 code, they switch the mode of the CPU to conform to Intel's memory ordering. Uh, no. Implementing TSO in a highly performant way is not "cheating", it's a difficult engineering feat. And no, TSO is not some fancy Intel thingy. It's a standard memory model.

gameswithgo 6y ago
i believe in this case cheating is being used to mean that they were clever, working around the problem, not doing anything wrong
- Waterluvian 6y ago
  Yeah. "How do we make the Wii run Game Cube games? We cheat by putting a Game Cube in the Wii!" It's a playful use of the term.
  - eyelidlessness 6y ago
    Or for us old [feeling] folks: it’s “cheating” by getting a world map and playing through the puzzles and minibosses we would still encounter... not getting a Game Genie and sliding under Mother Brain. Edit: Lol I know, downvote away, icgaf I haven’t played a game besides minesweeper in months.
    - Waterluvian 6y ago
      I honestly just don't understand what you're trying to say.
      - eyelidlessness 6y ago
        I honestly was just kind of flow of consciousness riffing so I don’t blame you. Just overextending the metaphor of gaming applied to cheating with applied knowledge versus cheating with deus ex machina
spijdar 6y ago
To add to this: The POWER7 through POWER9 processors from IBM implement an equivalent to this called "SAO", or "Strong Access Ordering Mode". To quote an IBM engineer: > Currently, power has a weaker memory model than x86. Implementing a stronger memory model allows an emulator to more efficiently translate x86 code into power code, resulting in faster code execution. What's interesting is IBM publishes pretty detailed manuals about their processors. You can take a look at the POWER9 CPU manual [0] and search for "SAO". You'll see just how deep down support for this mode goes. To implement this sort of strong memory ordering requires modifications e.g. SAO mode introduces a new pipeline hazard to the L2 cache and requires deep support in the MMU, including corner cases like the virtual memory for VMs and nested VMs. It's not a casual addition to the uarch. EDIT: It just occurred to me Apple has taken a very different approach to solving this problem. From what I can tell, TSO on apple's CPUs is just process state implemented in their "high performance" cores that you get from flipping a bit in the MSR register (?). IBM's version is implemented in the memory system, and is applied to pages of memory (on Linux you call mprotect to mark a page SAO). TSO-semantics are then applied regardless of which core on a potentially multiprocessor, SMP system accesses it. The Apple implementation seems to be more limited -- but in a totally inconsequential way (can't share data between TSO and non-TSO processes). But it does beg the question, what happens when you have shared memory between a Rosetta 2 process and native ARM code? If the ARM code is running on a core without TSO, what gremlins come out to eat your data? [0] https://www.setphaserstostun.org/power9/POWER9_um_OpenPOWER_v20GA_09APR2018_pub.pdf https://www.setphaserstostun.org/power9/POWER9_um_OpenPOWER_...
- tpetry 6y ago
  Apple did implement this easier memory model without data sharing because instead of ibm their plan is to get rid of amd64. Why support strange amd64/arm combinations when your plan is to fully migrate to arm. You can do the easier work and use more die space for arm optimizations and effectively showing the developers they‘ll get a speed improvement when porting the code.
- deleted 6y ago
  [deleted]
- brigade 6y ago
grecy 6y ago
> When running translated x86 code, they switch the mode of the CPU to conform to Intel's memory ordering. I'm curious if this means that while any app is running in Rosetta2, does that mean the entire M1 CPU is in "Intel TSO mode", and therefore all processes run slower as a result, or can it do that for just the Rosetta2 Process(es)?
- BeeOnRope 6y ago
  I don't have any specific info, but I would be very surprised if this MSR setting wasn't on a per-core basis. So only cores that are currently running code that requires x86-TSO would be running in that mode.
  - saagarjha 6y ago
    Per core, yes. It gets set on entry and exit from the kernel for threads that have been marked as needing it.
- ithkuil 6y ago
  A cpu (core) executes one process at a time. There is a lot of cpu (core) global state that gets saved / restored upon context switch (either between processes or just between user mode and kernel mode). As a side note, there is a often a bit of terminology confusion on whether a cpu is the "die" or the "core". When discussing microarchitecture core == cpu in most cases
mtgx 6y ago
Does that mean Microsoft's engineers who have been working on emulating x86 to Arm for many years are simply incompetent because they didn't use this?

by titzer 6y ago

gameswithgo 6y ago

i believe in this case cheating is being used to mean that they were clever, working around the problem, not doing anything wrong

Waterluvian 6y ago
Yeah. "How do we make the Wii run Game Cube games? We cheat by putting a Game Cube in the Wii!" It's a playful use of the term.
- eyelidlessness 6y ago
  Or for us old [feeling] folks: it’s “cheating” by getting a world map and playing through the puzzles and minibosses we would still encounter... not getting a Game Genie and sliding under Mother Brain. Edit: Lol I know, downvote away, icgaf I haven’t played a game besides minesweeper in months.
  - Waterluvian 6y ago
    I honestly just don't understand what you're trying to say.
    - eyelidlessness 6y ago
      I honestly was just kind of flow of consciousness riffing so I don’t blame you. Just overextending the metaphor of gaming applied to cheating with applied knowledge versus cheating with deus ex machina

spijdar 6y ago

To add to this: The POWER7 through POWER9 processors from IBM implement an equivalent to this called "SAO", or "Strong Access Ordering Mode". To quote an IBM engineer: > Currently, power has a weaker memory model than x86. Implementing a stronger memory model allows an emulator to more efficiently translate x86 code into power code, resulting in faster code execution. What's interesting is IBM publishes pretty detailed manuals about their processors. You can take a look at the POWER9 CPU manual [0] and search for "SAO". You'll see just how deep down support for this mode goes. To implement this sort of strong memory ordering requires modifications e.g. SAO mode introduces a new pipeline hazard to the L2 cache and requires deep support in the MMU, including corner cases like the virtual memory for VMs and nested VMs. It's not a casual addition to the uarch. EDIT: It just occurred to me Apple has taken a very different approach to solving this problem. From what I can tell, TSO on apple's CPUs is just process state implemented in their "high performance" cores that you get from flipping a bit in the MSR register (?). IBM's version is implemented in the memory system, and is applied to pages of memory (on Linux you call mprotect to mark a page SAO). TSO-semantics are then applied regardless of which core on a potentially multiprocessor, SMP system accesses it. The Apple implementation seems to be more limited -- but in a totally inconsequential way (can't share data between TSO and non-TSO processes). But it does beg the question, what happens when you have shared memory between a Rosetta 2 process and native ARM code? If the ARM code is running on a core without TSO, what gremlins come out to eat your data? [0] https://www.setphaserstostun.org/power9/POWER9_um_OpenPOWER_v20GA_09APR2018_pub.pdf https://www.setphaserstostun.org/power9/POWER9_um_OpenPOWER_...

tpetry 6y ago
Apple did implement this easier memory model without data sharing because instead of ibm their plan is to get rid of amd64. Why support strange amd64/arm combinations when your plan is to fully migrate to arm. You can do the easier work and use more die space for arm optimizations and effectively showing the developers they‘ll get a speed improvement when porting the code.
deleted 6y ago
[deleted]
brigade 6y ago

grecy 6y ago

> When running translated x86 code, they switch the mode of the CPU to conform to Intel's memory ordering. I'm curious if this means that while any app is running in Rosetta2, does that mean the entire M1 CPU is in "Intel TSO mode", and therefore all processes run slower as a result, or can it do that for just the Rosetta2 Process(es)?

BeeOnRope 6y ago
I don't have any specific info, but I would be very surprised if this MSR setting wasn't on a per-core basis. So only cores that are currently running code that requires x86-TSO would be running in that mode.
- saagarjha 6y ago
  Per core, yes. It gets set on entry and exit from the kernel for threads that have been marked as needing it.
ithkuil 6y ago
A cpu (core) executes one process at a time. There is a lot of cpu (core) global state that gets saved / restored upon context switch (either between processes or just between user mode and kernel mode). As a side note, there is a often a bit of terminology confusion on whether a cpu is the "die" or the "core". When discussing microarchitecture core == cpu in most cases

mtgx 6y ago

Does that mean Microsoft's engineers who have been working on emulating x86 to Arm for many years are simply incompetent because they didn't use this?