Closed bchurchill closed 8 years ago
It seems the manual just labels every instruction family with one CPUID with the convention that instructions get extended to new registers when new chips come out. E.g., addpd is an AVX instruction, and the variant that works on ymm registers is still labeled AVX, even though it clearly requires a CPU with ymm registers (and not all AVX CPUs have them). I think that makes sense, so I'm not sure this was the right way to fix this issue (but maybe it was).
I wonder what will happen with AVX512. Are all AVX instructions going to support all 32 new registers?
You may be totally right about that, and maybe we'll need to revert. Looking at the wikipedia article, it seems that AVX does support ymm registers. But, if that's the case, we have a much more frustrating problem if the manual says some instructions are AVX but are actually AVX2. Did you look at VPCMPGTB ymm, ymm, ymm in particular? Do you know what the situation is there?
On 01/21/2016 05:16 PM, Stefan Heule wrote:
It seems the manual just labels every instruction family with one CPUID with the convention that instructions get extended to new registers when new chips come out. E.g., addpd is an AVX instruction, and the variant that works on ymm registers is still labeled AVX, even though it clearly requires a CPU with ymm registers (and not all AVX CPUs have them). I think that makes sense, so I'm not sure this was the right way to fix this issue (but maybe it was).
I wonder what will happen with AVX512. Are all AVX instructions going to support all 32 new registers?
— Reply to this email directly or view it on GitHub https://github.com/StanfordPL/x64asm/issues/221#issuecomment-173768800.
I haven't, but looking at the manual, that's an AVX2 instruction. Looking at the diff, it seems that was indeed a bug in the spreadsheet, but many of the others (maybe most?) such as ADDPD really are AVX, not AVX2. Does that sound right?
I think so. Reopening.
closed in e8a470a7403c3
and also b26c4e2245a2f671 (the revert). Had trouble managing branches correctly here.
I'm not sure what the root cause of this was; it could be bugs in the intel manual, or maybe it was our fault. Either way, it looks like around 92 instructions with ymm arguments were labeled incorrectly as 'avx'.