qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v4 1/4] Add moxie target code


From: Anthony Green
Subject: Re: [Qemu-devel] [PATCH v4 1/4] Add moxie target code
Date: Thu, 28 Feb 2013 12:30:44 -0500

Peter - thanks for reviewing this.

On Thu, Feb 28, 2013 at 6:06 AM, Peter Maydell <address@hidden> wrote:
> On 27 February 2013 22:09, Anthony Green <address@hidden> wrote:
>> +static const VMStateDescription vmstate_moxie_cpu = {
>> +    .name = "cpu",
>> +    .unmigratable = 1,
>> +};
>
> Since this is a new CPU it should just go ahead and implement
> migration support.

I think I did this.  See next patch.

>> +/* The dynamic value of the DELAY_SLOT_TRUE flag determines whether the jump
>> + * after the delay slot should be taken or not. It is calculated from SR_T.
>> + *
>> + * It is unclear if it is permitted to modify the SR_T flag in a delay slot.
>> + * The use of DELAY_SLOT_TRUE flag makes us accept such SR_T modification.
>> + */
>
> Is the Moxie really an SH-4 clone which has cloned this particular
> SH-4 issue, or have you just copied this comment incorrectly
> from the target-sh4 code? Do all of the copied constants really
> also apply?

A fair bit of this was cut-n-paste.  It's all cleaned up now.  Moxie
has no delay slots.

>> +        case 0x31: /* div.l */
>> +            {
>> +                int a = (opcode >> 4) & 0xf;
>> +                int b = opcode & 0xf;
>> +                tcg_gen_div_i32(REG(a), REG(a), REG(b));
>
> Didn't Richard mention the problem of exceptions on division
> in review of an earlier version of this patch?

Current hardware doesn't trap on divide by zero, so I don't mind this
failing now.  The exception processing mechanism will be implemented
soon at which time I'll clean this up.

I'll post the new series in a few minutes....

Thanks again,

AG



reply via email to

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