Re: [Qemu-devel] target-i386: guest variable shift by 0 provokes shift by -1

[Peter Maydell]

On 18 March 2014 14:56, Richard Henderson <address@hidden> wrote:
> On 03/18/2014 07:47 AM, Peter Maydell wrote:
>> The interesting question is not immediate shifts
>> but variable ones. It's trivially easy for the frontend
>> to avoid passing out of range immediate values
>> and for the backend to screen them out. This
>> case is a variable shift TCG op.
>
> Exactly how are you distinguishing between constant and
> variable shifts?  By how they were issued in the first
> place?  By how they are presented to the backend?

By whether the backend or the frontend has trivial
access to the value to be able to avoid doing bad
things if it's out of range. If either do, they can
do a translate-time check to avoid issues. If neither
does then we need the host CPU architecture to be
OK with the out of range value, or we need to insert
an explicit mask op in the backend (which is likely
to be a duplicate of an explicit mask op already
inserted at the frontend to get the frontend-target
mandated behaviour for out of range ops).

Unless all our host architectures have undefined-result
behaviour for variable shifts by out of range values
then we can't make the TCG op semantics do that.
(They probably can; the only counterexample I know
of is the 8086, where the variable-shift cycle count
was proportional to the value of the shift, so feeding
it -1 would effectively cause it to hang.)

thanks
-- PMM