Adding some more basis to the patch: I received some documentation from Freescale support relating to this: Signal Processing Engine (SPE) Programming Environments Manual: http://cache.nxp.com/files/32bit/doc/ref_manual/SPEPEM.pdf. Relevant info is on page #113.
According to the documentation, the value is CR (4 bits wide) is set as follows: crD = undefined || cl || undefined || undefine That is, if the condition is true, the crD[2] bit will be set to 1, else zero. The value for rest of the three bits is undefined. Taking this information into account, we can set crD[1] bit as well, without violating architecture specification. The existing logic in QEMU which interprets the value of CR (which is set by a number of different instructions) for branching decisions works well with all other instructions. This existing logic is also used for emulation of other CPUs which do not support efscmp* instructions. Hence, I believe setting CR = 6 instead of CR = 4 is the most straightforward solution. Comments and suggestions are welcome. ________________________________ From: Imran, Talha Sent: Friday, May 13, 2016 9:26 PM To: qemu-triv...@nongnu.org Subject: [PATCH] Fix QEMU PPC e500v1 efscmp* instructions re-post with attachment. ________________________________ From: Imran, Talha Sent: Friday, May 13, 2016 9:04 AM To: qemu-triv...@nongnu.org Subject: [PATCH] Fix QEMU PPC e500v1 efscmp* instructions ping ________________________________ From: Imran, Talha Sent: Tuesday, May 10, 2016 6:24 PM To: qemu-...@nongnu.org; qemu-devel@nongnu.org Subject: [PATCH] Fix QEMU PPC e500v1 efscmp* instructions Hi Everyone, Please find attached a patch which fixes handling in QEMU PPC e500v1 for efscmp* instructions. This was the cause of over 400 FAILs for this CPU while running GCC testsuite, which have been fixed. Value for Condition Registers (CR) being set in QEMU was different from the value observed on hardware. I have not managed to find a documentation describing the behaviour of e500 cores for these instructions. However, the behaviour on MPC8548-CDS target was observed by dumping registers to stdout, while running executables from uboot. These instructions are used by GCC only when compiling for te500v1 multilib; hence no effect on other PPC CPUs (603, 7400 etc.) A comparison of GCC v5.2.0 testsuite results summary (number of FAILs) is as follows: CPU = te500v1 without patch: 699 with patch: 193 CPU = e500v2 without patch: 225 with patch: 225 Is this OK to commit? Comments and suggestions are welcome. Thanks, Talha Imran
ppc-efscmpgt.patch
Description: ppc-efscmpgt.patch
