Re: [Qemu-devel] [RISU RFC PATCH v2 02/14] risugen_x86_asm: add module

[Richard Henderson]

On 7/1/19 6:35 AM, Jan Bobek wrote:
> +    VEX_V_UNUSED => 0b1111,

I think perhaps this is a mistake.  Yes, that's what goes in the field, but
what goes in the field is ~(logical_value).

While for general RISU-ish operation, ~(random_number) is just as random as
+(random_number), the difference will be if we ever want to explicitly emit
with this interface a specific vex instruction which also requires the 
v-register.

> +sub rex_encode(%)
> +{
> +    my (%args) = @_;
> +
> +    $args{w} = 0 unless defined $args{w};
> +    $args{r} = 0 unless defined $args{r};
> +    $args{x} = 0 unless defined $args{x};
> +    $args{b} = 0 unless defined $args{b};
> +
> +    return (value => 0x40
> +            | (($args{w} ? 1 : 0) << 3)
> +            | (($args{r} ? 1 : 0) << 2)
> +            | (($args{x} ? 1 : 0) << 1)
> +            | ($args{b} ? 1 : 0),
> +            len => 1);
> +}

Does

        (defined $args{w} && $args{w}) << 3

work?  That seems tidier to me than splitting these conditions.

> +        return (value => (0xC4 << 16)
> +                | (($args{r} ? 1 : 0) << 15)
> +                | (($args{x} ? 1 : 0) << 14)
> +                | (($args{b} ? 1 : 0) << 13)

Further down in vex_encode, and along the lines of VEX_V_UNUSED, this appears
to be actively wrong, since these bits are encoded as inverses.  What this
*really* means is that because of that, rex_encode and vex_encode will not
encode the same registers for a given instruction.  Which really does feel
bug-like, random inputs or no.


r~