Re: [RFC PATCH 00/17] (The beginning of) a new i386 decoder

[Paolo Bonzini <pbonzini@redhat.com>]

On 8/25/22 01:01, Richard Henderson wrote:
>> One notable
>> difference is that the new decoder always sign-extends 8-bit immediates,
>> so for example a "cmpb $e9, %dl" instruction will subtract $0xfff...fffe9
>> from the temporary value.  This is the way Intel intended "Ib" immediates
>> to work, and there's no difference between the two.
> 
> That is in fact an improvement.

Yes, it is and it is a direct effect of encoding the operand types and 
sizes in a table, instead of writing ad hoc code everywhere.

>> Anyay, porting these opcodes is really more of a validation for the
>> whole concept and a test for the common decoder code; it's probably more
>> efficient to focus on the SSE and VEX 2-byte and 3-byte opcodes as a path
>> towards enabling AVX in QEMU, and keep the existing decoder for non-VEX,
>> non-SSE opcodes.
> 
> Eh... I disagree.  I would really hate to retain the existing decoder.
> This is already so much better...

Absolutely, it's just a matter of programmer efficiency, and then 
SSE/AVX is where I would start.

I would hate to not get there just because I didn't have time to 
complete the last sixty-ish one-byte opcodes (which are also the ones 
that benefit the least from table-driven decoding; that's already 
visible in 90-9F).

This was just a heads up that if I complete this patchset I would 
probably ask to have it committed with "just" SSE/AVX (plus the BMI VEX 
instructions), in a similar spirit to how the Meson conversion only 
covered Makefiles.

Paolo