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~
