4 ms·

Couldn't rosetta (or other x86 emulator) do some static analysis and emit the instructions for computing PF and AF only in cases where there is a chance that th

Couldn't rosetta (or other x86 emulator) do some static analysis and emit the instructions for computing PF and AF only in cases where there is a chance that they will be inspected? And not emitting extra instructions if nothing until the next instruction which overwrites flags reads the problematic flags. That way in most case it could use the regular arm add instruction. And only in the rare cases where analysis fails you would need the extra instructions. Or are there some common patterns where making such analysis is difficult? Something like copying the whole state of status register for later use (don't remember if x86 even allows that) instead of checking flags directly. Although in that case you would need an extra code anyway to reorganize value so that it matches the strucutre of x86 flag register. I assume the order on x86 and arm is not identical.

thegeomaster 4y ago
I assume there is no extra cost to the extra subs/adds instructions, so there is no reason to perform this extra analysis when those are available. The author does say: >In a VM, it isn’t able to configured the host CPU, so it can’t use this functionality. There are two other options. Either, you can skip computing the flags, because they’re mostly useless and most software won’t care. Or you can compute them the long way shown above. Rosetta 2 chooses the second option, and this mostly works out fine, because they have an “unused flags” optimisation that avoids the computation a lot of the time. So there's an optimization pass that does what you mentioned, it's just not needed when you have the right instruction available, and the thing is probably a wee bit faster if you don't do it.
stevefan1999 4y ago
if you got a jit in between you are doomed
dougall 4y ago
Every time there's an indirect branch (including a return) there's a chance that they will be inspected. The "unused flags" optimisation does remove most of them, in a way that gets it right 100% of the time (excluding signals/interrupts inspecting state at random points, and possible bugs), but the pattern "an add or subtract or compare followed by an indirect branch or return" is still very common. (I haven't looked at Linux Rosetta 2, other than to note the parity-flag computation coincidentally showing up in a screenshot posted to Twitter, so I'm not sure exactly how often they do the manual computation, but I'm guessing it's anywhere flags are used, in which case the unused-flags optimisation could be extended further by tracking AF and PF separately to the usual flags, which is roughly your suggestion.) You could still remove the vast majority of the remaining computations with some heuristics that work well, but then you've gone from 100% correct to 99.9% correct, which is nice to avoid when you have the option.
deleted 4y ago
[deleted]

thegeomaster 4y ago

I assume there is no extra cost to the extra subs/adds instructions, so there is no reason to perform this extra analysis when those are available. The author does say: >In a VM, it isn’t able to configured the host CPU, so it can’t use this functionality. There are two other options. Either, you can skip computing the flags, because they’re mostly useless and most software won’t care. Or you can compute them the long way shown above. Rosetta 2 chooses the second option, and this mostly works out fine, because they have an “unused flags” optimisation that avoids the computation a lot of the time. So there's an optimization pass that does what you mentioned, it's just not needed when you have the right instruction available, and the thing is probably a wee bit faster if you don't do it.

stevefan1999 4y ago

if you got a jit in between you are doomed

dougall 4y ago

Every time there's an indirect branch (including a return) there's a chance that they will be inspected. The "unused flags" optimisation does remove most of them, in a way that gets it right 100% of the time (excluding signals/interrupts inspecting state at random points, and possible bugs), but the pattern "an add or subtract or compare followed by an indirect branch or return" is still very common. (I haven't looked at Linux Rosetta 2, other than to note the parity-flag computation coincidentally showing up in a screenshot posted to Twitter, so I'm not sure exactly how often they do the manual computation, but I'm guessing it's anywhere flags are used, in which case the unused-flags optimisation could be extended further by tracking AF and PF separately to the usual flags, which is roughly your suggestion.) You could still remove the vast majority of the remaining computations with some heuristics that work well, but then you've gone from 100% correct to 99.9% correct, which is nice to avoid when you have the option.

deleted 4y ago

[deleted]