qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 51/52] target-m68k: add cmpm


From: Laurent Vivier
Subject: Re: [Qemu-devel] [PATCH 51/52] target-m68k: add cmpm
Date: Sun, 8 May 2016 11:07:11 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0


Le 07/05/2016 à 23:50, Peter Maydell a écrit :
> On 7 May 2016 at 20:01, Laurent Vivier <address@hidden> wrote:
>>
>>
>> Le 07/05/2016 à 00:00, Richard Henderson a écrit :
>>> On 05/04/2016 11:21 AM, Laurent Vivier wrote:
>>>> +    reg = AREG(insn, 0);
>>>> +    src = gen_load(s, opsize, reg, 1);
>>>> +    tcg_gen_addi_i32(reg, reg, opsize_bytes(opsize));
>>>> +
>>>> +    reg = AREG(insn, 9);
>>>> +    dest = gen_load(s, opsize, reg, 1);
>>>> +    tcg_gen_addi_i32(reg, reg, opsize_bytes(opsize));
>>>
>>> Delay the writeback to the first areg until after the second load.
>>
>> We can't delay because we can have "cmpm (%a0)+,(%a0)+" that is used to
>> compare two consecutive memory contents.
> 
> If you write back to the first areg before the second
> load, don't you get the wrong value as seen by the
> exception handler if the second load faults?
> 
> Usually you want to use the updated value for the
> purposes of calculating the address to use in the
> second load, but you don't want to actually update
> the guest CPU register until after the load has
> happened, in case it faults.
> 
> (Disclaimer: I'm just assuming that on a fault no
> registers are updated, but if that wasn't the case the OS
> wouldn't be able to cleanly restart the instruction after
> fixing up a page fault, so it seems like a good guess.)

You're right.

But I didn't really care here of the page faults because m68k only
supports non privileged instructions: coldfire is used in semi-hosting
mode (no MMU) and 680x0-like machine has no hardware (I use it in
linux-user mode).

I'm working on a Quadra 800 [1] emulation where I have added all the
needed hardware and privileged instructions, and of course, I have to
re-work all the memory access because of what you have described above...

But I'm going to try to update this series taking care of the memory
access fault as much as possible.

Laurent

[1] https://github.com/vivier/qemu-m68k/tree/q800-v2.4.0



reply via email to

[Prev in Thread] Current Thread [Next in Thread]