APX vs EFLAGS.AF

[Beulich__Jan]

Would it be possible (and make sense) to alter the APX spec slightly to state that whenever it's not left alone by an insn, AF is undefined? APX being 64-bit only, and EFLAGS.AF - aiui - being largely meaningless in 64-bit mode would seem to suggest that such a slight adjustment could already have been done when x86-64 was first specified. While that can't be altered anymore, new 64-bit-only ISA extensions certainly have some playing room there ...

[j_agron]

Thanks, Jan.  Solid feedback.  Here's my take on this, from my point-of-view.

In general, we always have x86-64 simplifications in mind, but we also are cognizant of the scope/cost/complexity of clean-up efforts and their impacts on SW intricacy, HW validation, power/perf gain, value, etc.  When x86-64 (or any modal feature) is added, it provides a blanket way of making changes easier, as they're local to that mode, but this was not pursued as x86-64 was introduced.  Since APX is not modal, there isn't as much freedom to alter semantics, either, and we didn't pursue such changes.

In cases like this, we purposefully wanted to design APX with minimal perturbance in that we didn't want instructions to change semantics (unless it was useful**) just because they use an APX-related prefix; esp. as register allocation (and use of EGPRs, NDD, etc.) may be outside of the control of a SW developer.  

In addition, from a hardware perspective, APX is not really adding much in the way of new functional units -- rather much of it is just new encodings for things that the underlying machine, and the underlying uOPs, already support.  So, APX (aside from the _new_ instructions APX introduces) seeks to map efficiently to the existing uOPs, rather than inventing new uOPs, with ever-so-slightly modified semantics.  From a definition/test/validation perspective, for both Intel and others, this also means that definitions, usages, and validation tests for a legacy-encoded op that writes EFLAGS.AF can also be leveraged for the REX2 and EVEX versions of said instructions. So, even if AF isn't popular and is often un-used, or even un-defined (although most implementations have a defined behavior that doesn't really deviate), the cost of changing it's semantics outweighs visible benefits.

**I will say that we did pursue "useful" semantic changes in APX, esp. with respect to NDD operation's having zero-upper semantics in smaller bit-width operations.  The merge behavior is often not desired by software, and the cost of merge behavior at the HW level requires additional sources/dependencies, etc.