3 ms·

It could very well be that they cannot reliably prove those flags are unused in enough cases to optimise out their (expensive) calculation.

• Someone 4y ago
  The flags get saved and restored on task switches and interrupts. I would think deciding whether those bits actually get used across that is infeasible, but yet, https://dougallj.wordpress.com/2022/11/09/why-is-rosetta-2-fast/ https://dougallj.wordpress.com/2022/11/09/why-is-rosetta-2-f... says: “This almost entirely prevents inter-instruction optimisations. There are two known exceptions. The first is an “unused-flags” optimisation, which avoids calculating x86 flags value if they are not used before being overwritten on every path from a flag-setting instruction.” Does this mean the emulator is buggy (if I write a loop that sets and clears flags, but doesn’t do anything with them, an interrupt handler that samples the flag values would need to see both values), but in a way that no sane code would notice?
  • atq2119 4y ago
    It does technically sound like there is a gap in the emulation, yes. Though, since interrupts are normally transparent to user space software, you'd have to use something like ptrace or be messing with the signal delivery mechanism to even have a chance at noticing the gap. And you'd have to do quite obscure and absurd things even by those APIs' standards.
  • erincandescent 4y ago
    Rosetta 2 doesn't emulate interrupts (they're not visible to userspace components) It does have to emulate signals but its moderately easy to handle those by deferring them to "safe" points where all architectural state is known