On Tue, May 18, 2021 at 09:30:38AM +0200, Greg Kurz wrote:
> On Tue, 18 May 2021 08:40:36 +0200
> Giuseppe Musacchio wrote:
>
> > The ISA [1] specifies the load order to be the target one, hence
> > the use of MO_TEQ in my patch (in both lxvwsx and lxvdsx).
> >
> > I believe the error is hidden
On Tue, 18 May 2021 08:40:36 +0200
Giuseppe Musacchio wrote:
> The ISA [1] specifies the load order to be the target one, hence
> the use of MO_TEQ in my patch (in both lxvwsx and lxvdsx).
>
> I believe the error is hidden in some of the .mak files: I could not
> reproduce this problem with Qemu
On 18/05/2021 02:34, David Gibson wrote:
I'm having a hard time convincing myself this is correct in all cases.
Have you tested it with all combinations of BE/LE host and BE/LE guest
code?
The description in the ISA is pretty inscrutable, since it's in terms
of the confusing numbering if differ
The ISA [1] specifies the load order to be the target one, hence
the use of MO_TEQ in my patch (in both lxvwsx and lxvdsx).
I believe the error is hidden in some of the .mak files: I could not
reproduce this problem with Qemu's user-mode emulation in either
BE nor LE mode, this lead me to discover
On Mon, May 17, 2021 at 04:40:32PM -0500, Paul A. Clarke wrote:
> `lxvdsx` is byte-swapping the data it loads, which it should not
> do. Fix it.
>
> Fixes #212.
>
> Fixes: bcb0b7b1a1c05707304f80ca6f523d557816f85c
> Signed-off-by: Paul A. Clarke ' ...^
I'm having a hard time convincing myself
`lxvdsx` is byte-swapping the data it loads, which it should not
do. Fix it.
Fixes #212.
Fixes: bcb0b7b1a1c05707304f80ca6f523d557816f85c
Signed-off-by: Paul A. Clarke mem_idx, MO_TEQ);
+tcg_gen_qemu_ld_i64(data, EA, ctx->mem_idx, MO_LEQ);
tcg_gen_gvec_dup_i64(MO_Q, vsr_full_offset(xT(c
