>Which we have massive tables for each form which track those side effects and clobbering information too.
No, you have tables _of the instructions that the compiler codegen may use_. You have no tables of what someone may use inside inline assembly, because for most architectures it may not even be possible to build such tables in the first place!. That's a reason why usually you rely on the users specifying the side effects manually for these cases.
> Okay? There are no 128-bit integer registers on AMD64, ARM64, nor RISCV-64. So I have no idea what you are on about.
You have no idea why you would need to pass a 128 bit int in two registers if there are no two 128-bit integer registers? Am I missing something here?
Even rdtsc is already returning a 64-bit into two registers (another x86 idiosyncrasy I suppose), rather than "two separate return values", something the examples kind of gloss over.
No, you have tables _of the instructions that the compiler codegen may use_. You have no tables of what someone may use inside inline assembly, because for most architectures it may not even be possible to build such tables in the first place!. That's a reason why usually you rely on the users specifying the side effects manually for these cases.
> Okay? There are no 128-bit integer registers on AMD64, ARM64, nor RISCV-64. So I have no idea what you are on about.
You have no idea why you would need to pass a 128 bit int in two registers if there are no two 128-bit integer registers? Am I missing something here?
Even rdtsc is already returning a 64-bit into two registers (another x86 idiosyncrasy I suppose), rather than "two separate return values", something the examples kind of gloss over.