From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44118) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgsdF-0005D0-3L for qemu-devel@nongnu.org; Sat, 11 Apr 2015 06:27:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YgsdB-0008MS-SC for qemu-devel@nongnu.org; Sat, 11 Apr 2015 06:27:21 -0400 Received: from mail-pd0-x22c.google.com ([2607:f8b0:400e:c02::22c]:33999) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YgsdB-0008LG-LJ for qemu-devel@nongnu.org; Sat, 11 Apr 2015 06:27:17 -0400 Received: by pdbqa5 with SMTP id qa5so49761129pdb.1 for ; Sat, 11 Apr 2015 03:27:16 -0700 (PDT) Date: Sat, 11 Apr 2015 20:27:10 +1000 From: "Edgar E. Iglesias" Message-ID: <20150411102710.GS30629@toto> References: <1428437400-8474-1-git-send-email-peter.maydell@linaro.org> <1428437400-8474-2-git-send-email-peter.maydell@linaro.org> <20150409085537.GA30629@toto> <55264496.70702@redhat.com> <20150410020736.GB28944@toto> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH 01/14] memory: Define API for MemoryRegionOps to take attrs and return status List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Peter Crosthwaite , Patch Tracking , QEMU Developers , Greg Bellows , Paolo Bonzini , Alex =?iso-8859-1?Q?Benn=E9e?= , Richard Henderson On Fri, Apr 10, 2015 at 03:51:07PM +0100, Peter Maydell wrote: > On 10 April 2015 at 03:07, Edgar E. Iglesias wrote: > > On Thu, Apr 09, 2015 at 11:21:26AM +0200, Paolo Bonzini wrote: > >> On 09/04/2015 11:04, Peter Maydell wrote: > >> > We discussed this last time round, I think. Whether structs get > >> > passed in registers depends on the host CPU ABI/calling convention. > >> > >> Because of C++, structs up to pointer size are in practice always passed > >> in registers. 64-bit structs may or may not. > >> > >> The main advantage of structs is that it's impossible to mismatch the > >> parameter order. That even trumps readability in my opinion. > >> > >> I'm ambivalent, but I wouldn't mind at all using structs. > > > > Thanks for clarifying that Paolo. > > > > Yes, the manual bit masking and shifting is easier to get wrong. > > The struct also has stronger type checking in a way, as you cant OR in literals > > that are out of bounds. (IIRC GCC will even warn you for free). > > The struct is also easy to extend if we ever run out of bits in the uint64_t. > > > > Peter, would you consider switching to struct or are you still convinced > > of the pure uint64_t approach? > > OK, having thought about this I'm willing to take the struct-and-bitfields > approach. My preferences are somewhat based on habit and also on some > of Linus' rants about bitfields for kernel use [eg > http://yarchive.net/comp/linux/bitfields.html], but I think we are > not going to hit any of the problem cases (notably, we don't care > about the arrangement of the bitfields within the word, we aren't > trying to have bitfields and locks/volatile/atomic info shared in > one struct, and we don't have a particular need to test multiple > bits at once). > > I'll change over to structs for v2. Awesome, thanks!