Context

A lot of issues regarding semantics came through, so I think it's a good idea to treat all of that in a more systematic way. Fixing by hand the mass of reports we got / we will get in the future is not tractable.

Thus, this issue is made to discuss how we can improve the overall situation regarding semantic definition for the lifting process.

Options

For now I see different options, with various level of feasibility (or rather, workload needed)

• Keeping the current system, check and correct everything using LLMs and the official documentations.
  This is a ~reasonable workload and keeps some sort of consistency for the project.

• Support for declarative-based semantics

  • Either custom, or an existing format (for instance Ghidra SLEIGH)
  • Then those semantics can be either
    • LLM generated
    • Recovered from existing ones (in the case of a well known format)
    • Deterministically generated (for instance, https://liblisa.nl/ for x86)

Using an existing format has the advantage of a reasonable workload, because we could re-use existing work.
libLISA style generation is much more work, for a debatable gain (even if the idea is very interesting in itself)

An other point to mention is "How much do we trust the docs to be well written"
For instance when I read #1551, it appeared that the Intel manual was ambiguous. Indeed the "Affected Flags" part is not consistent with the "Operation" (pseudo-code) part.

I had to manually check on my real CPU what happened, and for the curious people, the issue is indeed right,
the mentioned flags need to be updated in that case.

However it raises the more general issue of having reliable data to process into our semantic specification.
Maybe it can be ~resolved by telling an LLM to "be careful" and giving access to tools (qemu/real exec and gdb) when unsure/unclear.

Anyway, this is something we need to focus on, because I'm not solving these AI issues one by one.