target-arm: Fix rounding constant addition for Neon shifts
Handle cases where adding the rounding constant could overflow in Neonshift instructions: VRSHR, VRSRA, VQRSHRN, VQRSHRUN, VRSHRN.
Signed-off-by: Christophe Lyon <christophe.lyon@st.com>[peter.maydell@linaro.org: fix handling of large shifts in rshl_s32,...
target-arm: Move Neon VZIP to helper functions
Move the implementation of the Neon VUZP unzip instruction from inlinecode to helper functions. (At 50+ TCG ops it was well over therecommended limit for coding inline.) The helper implementations alsogive the correct answers where the inline implementation did not....
target-arm: Move Neon VUZP to helper functions
Move the implementation of the Neon VUZP unzip instruction from inlinecode to helper functions. (At 50+ TCG ops it was well over therecommended limit for coding inline.) The helper implementations alsofix the handling of the quadword version of the instruction....
target-arm: Correct conversion of Thumb Neon dp encodings into ARM
We handle Thumb Neon data processing instructions by converting theminto the equivalent ARM encoding, as the two are very close. Howeverthe ARM encoding should have bit 28 set, not clear. This wasn't causing...
target-arm: Fix Neon VQDMLSL instruction
For VQDMLSL, negation has to occur after saturation, not before.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
target-arm: Refactor handling of VQDMULL
Refactor the handling of VQDMULL so that it is dealt with inits own if() case rather than together with the accumulatinginstructions.
target-arm: Implement VMULL.P8
Implement VMULL.P8 (the 32x32->64 version of the polynomial multiplyinstruction).
qemu-lock.h: Remove non-pthreads spinlock implementations
Since configure guarantees us that we have pthreads on all hostsexcept mingw (which doesn't support a USER_ONLY config), we canand should use the pthread_mutex based implementation of spin_lock()...
e1000: verify we have buffers, upfront
The spec says: Any descriptor with a non-zero status byte has beenprocessed by the hardware, and is ready to be handled by the software.
Thus, once we change a descriptor status to non-zero we shouldnever move the head backwards and try to reuse this...
e1000: clear EOP for multi-buffer descriptors
The e1000 spec says: if software statically allocatesbuffers, and uses memory read to check for completed descriptors, itsimply has to zero the status byte in the descriptor to make it readyfor reuse by hardware. This is not a hardware requirement (moving the...
View all revisions | View revisions
Also available in: Atom