I think the downvotes are because of your language. First, you wrote "M1 has instruction-level x86 emulation" as an authoritative sounding statement, as if it'

I think the downvotes are because of your language. First, you wrote "M1 has instruction-level x86 emulation" as an authoritative sounding statement, as if it's true. When you also talked about Qualcomm and MediaTek having to add lots of complexity and deal with legal pitfalls, that added to the idea that you really did mean a full x86 instruction decoder, because that's where the legal pitfalls are expected to be. But it's false, the M1 doesn't do instruction-level x86 emulation, so that's a minor irritation. Comments don't usually get downvoted over a simple mistake, but they do if it looks like someone is saying something really misleading. But then in response to being told it doesn't do that, you wrote "so, it does? thanks for clarifying!". That language read like you were being snarky. The phrasing "so, it does?" in response to a correct "It doesn't." is typical English snark, a way of sounding dismissive and challenging at the same time. That interpretation invited a downvote. Once you have been perceived as snarky, following it with "thanks for clarifying!" is doomed to come across as more snark. The exclamation mark makes this worse. If you are legit just curious, then I think what has happened is you did not understand that "instruction-level x86 emulation" is a very different thing than "memory ordering", stating the former to be something the M1 does is misleading, and you did not realise you had written something that came across as snark. I'll legit try to explain the difference in case you're interested. A CPU doing x86 emulation at the instruction level would have the chip decode x86 machine instructions in hardware one by one and perform the operations they describe. The M1 doesn't have hardware to decode x86 though; neither does any other ARM CPU. It could be built, but nobody has, probably for legal reasons not technical reasons. For memory ordering, we probably wouldn't call it emulation. All multi-core CPUs have a memory ordering model, but different architectures have different models. This means how memory accesses (reads and writes) in programs running on one core are observed by programs on other cores running in parallel and doing memory accesses to the same locations. (On single-core CPUs it is irrelevant because normal CPU cores always observe their own reads and writes in program order.) It's probably not obvious how memory accesses can be observed out of order. It happens because at some level, reads and writes inside a CPU are not instantaneous. They become messages back and forth with the memory, messages take time to travel, and these messages get even more complicated when there are different kinds of caches all over the place as well. With multiple cores sending and receiving memory messages, each of these taking time to travel, the result is cores see memory messages in a different order from each other. Rather than explain, I'll link to the Wikipedia article: https://en.wikipedia.org/wiki/Memory_ordering https://en.wikipedia.org/wiki/Memory_ordering ARM generally has a weak memory model, which means the order of instructions in a program on one core has little effect on the order of memory accesses seen by other cores. This is too weak for some things to work (like locks between parallel threads), so there are also barrier instructions which force all memory accesses before and/or after the barrier to be visible to programs on other cores in the order of instructions, as long as the programs on the other cores also use barriers. On x86 you don't need barriers, because the ISA is defined (due to the history of CPUs) so that all memory accesses by each core are visible to all the others in the exact order of instructions run by each core. (There are some exceptions but they don't matter). This is a great illusion, because in reality to stay fast there are memory access messages flying around inside the CPU and between the cores and caches, getting out of order in large queues. To maintain the effect as if everything is in order needs a bunch of extra transistors and logic on the chip, to keep track of which messages have to be queued up and waited for before others. This is why when x86 programs are translated into ARM programs (by Rosetta 2 software), if it's for a multi-threaded program the ARM code needs a lot of barrier instructions all over the place, and these tend to be slow because the chip isn't optimised for lots of barriers. On the M1, it has a non-standard (for ARM) operating mode where the weak order switches to program order, like x86. For this to work it needs extra logic on the chip. It seems that the M1 doesn't use this extra logic all the time though, only when Rosetta 2 is using it. Probably because it slows things down a bit to turn it on. So when x86 programs are translated into ARM programs (by Rosetta 2 software) it doesn't need to include lots of barrier instructions. Maybe not any. The resulting code which runs on the M1 is ARM code (not x86 code), but it's special ARM code because if it's run in parallel with other ARM code accessing the same memory on another core, it only runs correctly when the M1 turns on the non-standard program-order memory mode, which slows the CPU a little.