qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH for-2.5 05/30] m68k: define operand sizes


From: Laurent Vivier
Subject: Re: [Qemu-devel] [PATCH for-2.5 05/30] m68k: define operand sizes
Date: Wed, 12 Aug 2015 10:44:43 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0


Le 12/08/2015 06:07, Richard Henderson a écrit :
> On 08/09/2015 01:13 PM, Laurent Vivier wrote:
>> -#define OS_BYTE 0
>> -#define OS_WORD 1
>> -#define OS_LONG 2
>> -#define OS_SINGLE 4
>> -#define OS_DOUBLE 5
>> +#define OS_BYTE     1
>> +#define OS_WORD     2
>> +#define OS_LONG     3
>> +#define OS_SINGLE   4
>> +#define OS_DOUBLE   5
>> +#define OS_EXTENDED 6
>> +#define OS_PACKED   7
>>
> 
> Is there a reason you've skipped the 0 value when adding the new values?

I think there is no reason, but if I change the value I have to update
abdc_mem, sbcd_mem instructions as they use it as an
incrementer/decrementer. I agree, it's a strange idea.

> 
>> +static inline int insn_opsize(int insn, int pos)
>> +{
>> +    switch ((insn >> pos) & 3) {
> 
> 
> In particular, that change means that insn_opsize is more complicated
> than needed.  Further, is there any reason for POS to be a varable? 
> Isn't it at the same place for all insns?
> 
>> +static inline int ext_opsize(int ext, int pos)
> 
> This should probably wait until the fp insns get added.

Yes.

Laurent



reply via email to

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