On 08.05.2013, at 12:07, Torbjorn Granlund wrote:
> Alexander Graf writes:
>
> Ok, so the real problem here is that NARROW_MODE is not set, but is
> used to differentiate whether to use the 32bit cmp only or not.
>
> Eh?
>
> Richard, there are 2 ways out of this:
>
>1) get rid of NARR
Alexander Graf writes:
Ok, so the real problem here is that NARROW_MODE is not set, but is
used to differentiate whether to use the 32bit cmp only or not.
Eh?
Richard, there are 2 ways out of this:
1) get rid of NARROW_MODE and always check ctx->sf
No!
The cmp insn with L set s
On 08.05.2013, at 11:32, Alexander Graf wrote:
>
> On 08.05.2013, at 11:20, Torbjorn Granlund wrote:
>
>> Aurelien Jarno writes:
>>
>> 64-bit CPUs check for the L bit of comparison instruction to determine
>> if the instruction is 32-bit wide, and not to the MSR SF bit.
>>
>> L=1 on a 32-bit
On 08.05.2013, at 11:20, Torbjorn Granlund wrote:
> Aurelien Jarno writes:
>
> 64-bit CPUs check for the L bit of comparison instruction to determine
> if the instruction is 32-bit wide, and not to the MSR SF bit.
>
> L=1 on a 32-bit CPU should generate an invalid instruction exception.
>
Aurelien Jarno writes:
64-bit CPUs check for the L bit of comparison instruction to determine
if the instruction is 32-bit wide, and not to the MSR SF bit.
L=1 on a 32-bit CPU should generate an invalid instruction exception.
No. See my previous post.
The L bit is to be ignored for
On 08.05.2013, at 08:50, Aurelien Jarno wrote:
> On Tue, May 07, 2013 at 09:30:24PM +0200, Torbjorn Granlund wrote:
>> I realised a possible problem with my suggested patch.
>>
>> What about a 32-bit processor? Then NARROW_MODE macro is identical 0.
>>
>> The pre-patch behaviour was then to ig
On Tue, May 07, 2013 at 09:30:24PM +0200, Torbjorn Granlund wrote:
> I realised a possible problem with my suggested patch.
>
> What about a 32-bit processor? Then NARROW_MODE macro is identical 0.
>
> The pre-patch behaviour was then to ignore the L bit and decode both
> 32-bit and 64-bit instr
Am 07.05.2013 um 21:30 schrieb Torbjorn Granlund :
> I realised a possible problem with my suggested patch.
>
> What about a 32-bit processor? Then NARROW_MODE macro is identical 0.
>
> The pre-patch behaviour was then to ignore the L bit and decode both
> 32-bit and 64-bit instruction in the
I realised a possible problem with my suggested patch.
What about a 32-bit processor? Then NARROW_MODE macro is identical 0.
The pre-patch behaviour was then to ignore the L bit and decode both
32-bit and 64-bit instruction in the same way.
Apparently that is correct behaviour. (The manual is
Alexander Graf writes:
> The first hunk is just a comment about suspicious code. I don't suggest
> to apply that.
The "suspicious" code is correct. The Rc update should indeed be
SF-mode dependent.
With the other 4 hunks, qemu-ppc64 is now able to execute GMP's
testsuite to completion, us
On 05/07/2013 05:58 PM, Torbjorn Granlund wrote:
OK, so took to reading some of translate to see how well it agrees with
the PPC architecture definition.
I spotted a bug with cmp, which was repeated 4 times. Somebody decided
that NARROW_MODE should affect the handling of cmp instructions, which
11 matches
Mail list logo
