From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49356) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEzvo-000694-0y for qemu-devel@nongnu.org; Mon, 20 Jun 2016 10:12:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bEzvi-0008FU-H1 for qemu-devel@nongnu.org; Mon, 20 Jun 2016 10:12:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37271) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bEzvi-0008Et-8X for qemu-devel@nongnu.org; Mon, 20 Jun 2016 10:11:58 -0400 Date: Mon, 20 Jun 2016 15:11:53 +0100 From: "Dr. David Alan Gilbert" Message-ID: <20160620141153.GD2891@work-vm> References: <1466097133-5489-1-git-send-email-dgilbert@redhat.com> <1466097133-5489-2-git-send-email-dgilbert@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH 1/5] BIT_RANGE convenience macro List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: QEMU Developers , Paolo Bonzini , Andrea Arcangeli , Eduardo Habkost * Peter Maydell (peter.maydell@linaro.org) wrote: > On 16 June 2016 at 18:12, Dr. David Alan Gilbert (git) > wrote: > > From: "Dr. David Alan Gilbert" > > > > e.g. BIT_RANGE(15, 0) gives 0xff00 > > > > Suggested by: Paolo Bonzini > > Signed-off-by: Dr. David Alan Gilbert > > --- > > include/qemu/bitops.h | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/include/qemu/bitops.h b/include/qemu/bitops.h > > index 755fdd1..e411688 100644 > > --- a/include/qemu/bitops.h > > +++ b/include/qemu/bitops.h > > @@ -23,6 +23,9 @@ > > #define BIT_MASK(nr) (1UL << ((nr) % BITS_PER_LONG)) > > #define BIT_WORD(nr) ((nr) / BITS_PER_LONG) > > #define BITS_TO_LONGS(nr) DIV_ROUND_UP(nr, BITS_PER_BYTE * sizeof(long)) > > +/* e.g. BIT_RANGE(15, 0) -> 0xff00 */ > > +#define BIT_RANGE(hb, lb) ((2ull << (hb)) - (1ull << (lb))) > > Isn't this undefined behaviour if the hb is 63? I've checked the C99 spec; it explicitly defines the unsigned behaviour ('reduced modulo one more than the maximum value representable in the result type'). > Also there is semantic overlap with the MAKE_64BIT_MASK macro > proposed in https://lists.gnu.org/archive/html/qemu-devel/2016-05/msg02154.html > (which also has ub, but see > https://lists.gnu.org/archive/html/qemu-devel/2016-06/msg02614.html > for the version which doesn't). > > I prefer a "start, length" macro to "position, position", > because this matches what we already have for the deposit > and extract functions in this header. I think it depends on the use; I agree that makes sense for things like extracting an n-bit integer; in this case what we have is something which is fixed at bit 51 and another bit - we dont ever think about the difference between those two bits. Dave > > thanks > -- PMM -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK