Behavior of shift built-ins with large shift operand

[Jozott00]

VADL defines the following built-in function

function lsl ( a : Bits<N>, b : UInt<M> ) -> Bits<N> // <=> a << b
function asr ( a : SInt<N>, b : UInt<M> ) -> SInt<N> // <=> a >> b
function lsr ( a : UInt<N>, b : UInt<M> ) -> UInt<N> // <=> a >> b
function rol ( a : Bits<N>, b : UInt<M> ) -> Bits<N> // <=> a <<> b
function ror ( a : Bits<N>, b : UInt<M> ) -> Bits<N> // <=> a <>> b

What is the defined behavior of these built-ins if b >= N?

QEMU defines undefined behavior in these cases.
For the simulation speed, it would be desirable if we could also define it as undefined behavior.

@AndreasKrall do you already have a definition for such a case?

[AndreasKrall]

As VADL is a processor description language, we should not have undefined behavior there. Some processors expect a certain behavior, e.g. the result is zero for a shift left or the result sets all bits to the sign bit. Others masks out the lower bits (& (N - 1)). An interesting case is the x86 architecture. 8088 resulted in a zero for lsl with b>n and 80286 masked the lower bits. This behavior was used to detect which processor was used. AArch64 and RISC-V mask out the lower bits.

If we leave the behavior undefined, it is the responsibility of the processor specification to describe the correct behavior. If the specification is not complete, it can give different results when executing the ISS on different hardware. I do not think that this is a good idea.

I suggest to define the behavior in the following way:

function shift( a : Bits<N>, b : UInt<M> ) -> Bits<N> // <=> a shift (b & zext(N-1))

Then we do not need the masking when defining the variable shift for RISC-V and AArch64. The QEMU emulator can make an analysis, if the shift factor always is smaller than N and then does not need to generate the masking. It is more complex, but a lot safer.

[AndreasKrall]

I just noticed that the masking only gives defined behavior if N is a power of 2. The correct specification should be:

function shift( a : Bits<N>, b : UInt<M> ) -> Bits<N> // <=> a shift (b % N)

Of course this should be optimized to b & zext(N-1) if N is a power of 2.

Anton also thinks that this would be the best definition.

I will give best practice code in the reference manual how to specify other behaviors with our primitive which should guide the optimizations in the generators.

[AndreasKrall]

QEMU supports the following host architectures: i386/x86-64,AArch32,AArch64,Power(PC),MIPS,Sparc,S390x

The shift behavior with shift counts bigger than the word size for the following architectures is:

AMD64     remainder
AArch32   sign bit / zero
AArch64   remainder
MIPS      remainder
Power(PC) 64 remainder also for 32 bit shifts which gives sign bit / zero in the range 32..63
RISC-V    remainder
Sparc     remainder
S/390     64 remainder also for 32 bit shifts which gives sign bit / zero in the range 32..63

It is possible to dynamically check if the host architecture does a remainder with the correct size. When the test fails, the TCG frontend has to issue an additional mask operation, otherwise the mask operation can be eliminated.