On Fri, Apr 10, 2015 at 03:51:07PM +0100, Peter Maydell wrote: > On 10 April 2015 at 03:07, Edgar E. Iglesias <edgar.igles...@gmail.com> 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!
