Richard Henderson <r...@twiddle.net> writes: > On 08/10/2016 02:51 PM, Nikunj A Dadhania wrote: >> I can fix the BE case using following but not sure if that will be >> correct ! >> >> tcg_gen_qemu_ld_i64(xth, EA, ctx->mem_idx, MO_Q); >> gen_helper_bswap32x2(xth, xth); >> tcg_gen_addi_tl(EA, EA, 8); >> tcg_gen_qemu_ld_i64(xtl, EA, ctx->mem_idx, MO_Q); >> gen_helper_bswap32x2(xtl, xtl); > > This cannot be correct, because it assumes a host-dependent byte ordering. > You > should be able to see different results depending on a BE or LE host. > > >> __vector uint32_t vrt32; >> uint32_t rb32[4] = {0x00010203, 0x20212223, 0x30313233, 0x40414243}; >> asm("lxvw4x %x0, 0, %1 \n\t" \ >> : "=ws"(vrt32) : "r"(&rb32)); >> printf("VRT32 = "); vec_put_u32(vrt32); >> >> Result On LE: >> VRT32 = 40414243 30313233 20212223 00010203 >> >> Result On BE: >> VRT32 = 03020100 23222120 33323130 43424140 > > Did you really recompile the test program for BE and LE, or did you just use > a > different command-line switch to qemu with the same executable image?
I have two different images one LE and other BE and run it like this; ./ppc64le-linux-user/qemu-ppc64le -cpu POWER9 test-tcg/LElxvx ./ppc64-linux-user/qemu-ppc64 -cpu POWER9 test-tcg/BElxvx $ file LElxvx LElxvx: ELF 64-bit LSB executable, 64-bit PowerPC or cisco 7500, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.32, not stripped $ file BElxvx BElxvx: ELF 64-bit MSB executable, 64-bit PowerPC or cisco 7500, version 1 (GNU/Linux), statically linked, for GNU/Linux 4.4.3, not stripped > I can't see how you could possibly get these results for BE. I have been confused since yesterday, so thought of asking you. Regards Nikunj