I‘m a little bit surprised these flags are used in a way that a simple backflow analysis wouldn’t reveal. If those flags are used within one function (that is, flags only need to be preserved across local branches), then an analysis should find the uses and corresponding instructions that set those. If those flags are used across function boundaries (e.g. after a return or passed as an argument), then it would be harder to detect, so a conservative emulator would have to correctly emulate the flags across all calls and returns.
But do those uses actually exist? What are those use cases for the flags that isn’t just some straight line code or maybe using some simple branches? Is there code that relies on even weirder cases like creating a fault, with the fault handler depending on correctly set A/P flags? Or did Apple just not want to deal with having flow analyses in their JIT emulator and decided going the hardware route was easier?
Famous last words, "simple". What about sequences like:
pushfd
pop eax
and eax, ebx
Now you need to know what ebx is to know for certain that PF and AF are irrelevant. Which is very likely, but not guaranteed, and the halting problem rears its ugly head.
I don't know whether there are good heuristics there or even how common that really is, but my gut feeling is that it may still be easy to "accidentally" drop into the slow AF/PF-preserving case, which can hurt in performance-critical code.
On the other hand, calculating AF/PF in hardware in the first place seems, from my outside view at least, much simpler, and appears to prevent a great deal of potential headache.
That's kind of what I did here, I "used" the bits on the stack by loading them into eax and ANDing them with whatever's in ebx. But yeah, the value could also be more directly referenced on the stack...
I've written a Prime minicomputer emulator, and it has these kinds of flags. In my experience, if you don't do exact hardware emulation, there will be some oddball program that doesn't work. If someone posted their program that Apple couldn't correctly emulate, it would cast doubt on their emulation in general, even if this oddball program is the only case in the world where it didn't work.
For Apple, I'm guessing that failing to emulate even an oddball program would be an unacceptable risk.
My guess is that there's an x86-ISA JIT or emulator or threaded-code VM, that itself reuses these flag bits (when it can guarantee a stretch of non-ALU code) to smuggle information between HLL ops. So Apple is in effect transparently transporting the smuggled data.
But do those uses actually exist? What are those use cases for the flags that isn’t just some straight line code or maybe using some simple branches? Is there code that relies on even weirder cases like creating a fault, with the fault handler depending on correctly set A/P flags? Or did Apple just not want to deal with having flow analyses in their JIT emulator and decided going the hardware route was easier?