Searched hist:"5 baf5641cc82fe18e98c1063d8682be9cdcae85c" (Results 1 – 2 of 2) sorted by relevance
| /qemu/target/i386/tcg/ |
| H A D | decode-new.h | 5baf5641cc82fe18e98c1063d8682be9cdcae85c Thu Oct 19 21:14:34 UTC 2023 Paolo Bonzini <pbonzini@redhat.com> target/i386: rename zext0/zext2 and make them closer to the manual
X86_SPECIAL_ZExtOp0 and X86_SPECIAL_ZExtOp2 are poorly named; they are a hack
that is needed by scalar insertion and extraction instructions, and not really
related to zero extension: for PEXTR the zero extension is done by the generation
functions, for PINSR the high bits are not used at all and in fact are *not*
filled with zeroes when loaded into s->T1.
Rename the values to match the effect described in the manual, and explain
better in the comments.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|
| H A D | decode-new.c.inc | 5baf5641cc82fe18e98c1063d8682be9cdcae85c Thu Oct 19 21:14:34 UTC 2023 Paolo Bonzini <pbonzini@redhat.com> target/i386: rename zext0/zext2 and make them closer to the manual
X86_SPECIAL_ZExtOp0 and X86_SPECIAL_ZExtOp2 are poorly named; they are a hack
that is needed by scalar insertion and extraction instructions, and not really
related to zero extension: for PEXTR the zero extension is done by the generation
functions, for PINSR the high bits are not used at all and in fact are *not*
filled with zeroes when loaded into s->T1.
Rename the values to match the effect described in the manual, and explain
better in the comments.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
|