From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MPFdp-0005o4-Pl for qemu-devel@nongnu.org; Fri, 10 Jul 2009 08:55:53 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MPFdk-0005hd-Tw for qemu-devel@nongnu.org; Fri, 10 Jul 2009 08:55:53 -0400 Received: from [199.232.76.173] (port=36540 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MPFdk-0005hR-PA for qemu-devel@nongnu.org; Fri, 10 Jul 2009 08:55:48 -0400 Received: from qw-out-1920.google.com ([74.125.92.145]:57453) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MPFdk-00082j-07 for qemu-devel@nongnu.org; Fri, 10 Jul 2009 08:55:48 -0400 Received: by qw-out-1920.google.com with SMTP id 5so259573qwc.4 for ; Fri, 10 Jul 2009 05:55:47 -0700 (PDT) Message-ID: <4A573A50.1040200@codemonkey.ws> Date: Fri, 10 Jul 2009 07:55:44 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 6/6] use uint32_t for ioport port and value instead of int. References: <1246530731-14597-1-git-send-email-yamahata@valinux.co.jp> <1246530731-14597-7-git-send-email-yamahata@valinux.co.jp> <4A564003.5080707@codemonkey.ws> <20090710082121.GB5471@const.bordeaux.inria.fr> <20090710084508.GM12665%yamahata@valinux.co.jp> In-Reply-To: <20090710084508.GM12665%yamahata@valinux.co.jp> Content-Type: text/plain; charset=EUC-JP Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Isaku Yamahata Cc: Samuel Thibault , qemu-devel@nongnu.org Isaku Yamahata wrote: > Then, the signatures should like the followings? > > void cpu_out[bwl](CPUState *env, int64_t addr, int{8, 16, 32}_t val); > uint{8, 16, 32}_t cpu_inw(CPUState *env, int16_t addr); > If anything, it ought to be: void cpu_out[bwl](CPUState *env, uint16_t addr, int{8, 16, 32}_t val); But it's int today because the assumption is that most architectures can more efficiently pass int than other types (because it's the native type) and that int is adequate to contain all of the necessary types. But my original question still remains, what's the motivation for this change? Regards, Anthony Liguori