Hacker News Reader

Much easier would be to break the 512b operation into 4 128b uops on the small cores.

Right. But if you take an interrupt after the two of those three operations, and you want to restart on the big core, what do you do? Disallow interrupts in split operations? Unwind the partially-performed op? Allow the big core to run 128-bit ops to complete this one after restart? Something else?

Micro-ops, while require intermediate microarchitectural state, doesn't produce inconsistent architectural state when interrupted. The instruction either retired (produced effects) or didn't, from the POV of the ISA (and thus the kernel and user code)

But I thought that the SVE extension allowed interrupt and restart of an instruction? The alternative seems like it would lead to potentially very high interrupt latency?

I don't know about SVE, just some general principles/thought: you either postpone the serving of the interrupt until the current instruction is done or you throw away progress made in the current instruction.

My educated guess is that the latter is most frequently used as a technique.

Also traps are caused by the very instruction being executed so you cannot complete the current instruction in all circumstances before vectoring to the trap/interrupt handler.

Reply on news.ycombinator.com