From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55673) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZPRed-0006fd-Pj for qemu-devel@nongnu.org; Wed, 12 Aug 2015 04:45:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZPRea-00038i-LU for qemu-devel@nongnu.org; Wed, 12 Aug 2015 04:44:59 -0400 Received: from mout.kundenserver.de ([212.227.126.187]:51104) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZPRea-000379-9W for qemu-devel@nongnu.org; Wed, 12 Aug 2015 04:44:56 -0400 References: <1439151229-27747-1-git-send-email-laurent@vivier.eu> <1439151229-27747-6-git-send-email-laurent@vivier.eu> <55CAC68E.60601@twiddle.net> From: Laurent Vivier Message-ID: <55CB077B.6050702@vivier.eu> Date: Wed, 12 Aug 2015 10:44:43 +0200 MIME-Version: 1.0 In-Reply-To: <55CAC68E.60601@twiddle.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH for-2.5 05/30] m68k: define operand sizes List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson , qemu-devel@nongnu.org Cc: peter.maydell@linaro.org, peter.crosthwaite@xilinx.com, Andreas Schwab , gerg@uclinux.org 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