Hacker News Reader

> And ARMs fixed length instructions allow apple to just duplication their instruction decoder logic until they are decoding (currently) 7 instructions per cycle.

Only the A32 and A64 instruction sets of ARM have fixed 32-bit-length instructions. T32 instructions are either 16 or 32 bits long.

True. But even decoding a variable length instruction set with just two lengths is far easier than decoding x86.

With T32 you just look at bits 15-13. If they are 111, it's a 32bit instruction. If they are anything else, it's a 16 bit instruction.

x86 is somewhat insane. Instructions can be any length from 1 to 15 bytes, and thanks to prefix bytes, the bits that specify the length can be found at any byte offset and might be spread over multiple bytes and interact with each other.

Even for 15 byte instructions, the 15th byte can tell the difference between "this is a valid 15 byte instruction" or "this instruction is actually 16 bytes long and therefore invalid"

> while ARM derived CPUs can just ignore those writes

Could you elaborate why?

On x86, an instruction is allowed to overwrite the memory for the very next instruction and expect the CPU to pick up the modified instruction and execute it.

On modern Superscalar designs, this requires the instruction cache to actively watch for any writes to cachelines it holds and invalidate them. If that cacheline is currently being executed, the core needs to go further.

The scheduler needs to decide if the instruction modifing the cacheline is before or after that position in the instruction stream. If it's after, the whole pipeline needs to be flushed and the instruction fetcher reset to the modified instruction and execution restarted.

Not a fast operation, but it needs to be supported due to the spec (and legacy code)

With ARM, the spec says the CPU is allowed to do whatever it feels like in this sitatuion. The cheapest option is to just ignore the write and execute whatever old code is currently in the instruction cache.

But to allow self modify code (and loading of libraries) ARM provides a special "invalidate the instruction cache" instruction which explictly tells the CPU something funky has happened and it need to flush data out of the instruction cache before continuing.

> ARM has a more relaxed memory model that allows you to skip some uarch components.

Note that ARM still generally supports ldar to match Intel’s semantics.

True. It becomes more of a power consumption advantage, because instructions that use those stricter memory semantics are explicitly marked.

Also, even with those instructions there are still things ARM can't currently do. X86 can and will do misaligned atomic updates (as long as it doesn't cross a cacheline). ARM can't.