From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60634) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZujxJ-0005R1-7t for qemu-devel@nongnu.org; Fri, 06 Nov 2015 11:33:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZujxG-0008IP-Ij for qemu-devel@nongnu.org; Fri, 06 Nov 2015 11:33:37 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49669) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZujxG-0008II-D1 for qemu-devel@nongnu.org; Fri, 06 Nov 2015 11:33:34 -0500 References: <1446740339-31366-1-git-send-email-pmorel@linux.vnet.ibm.com> <563B8498.7070804@redhat.com> <563C6695.7030507@linux.vnet.ibm.com> From: Paolo Bonzini Message-ID: <563CD658.9060507@redhat.com> Date: Fri, 6 Nov 2015 17:33:28 +0100 MIME-Version: 1.0 In-Reply-To: <563C6695.7030507@linux.vnet.ibm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/7] int128: reparing broken 128 bit memory calculations List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Pierre Morel , qemu-devel@nongnu.org Cc: cornelia.huck@de.ibm.com, peter.maydell@linaro.org On 06/11/2015 09:36, Pierre Morel wrote: > The calculation are not broken and it works for actual usage Thanks for confirming. > For me, it is the design that is broken, as it uses an integer to represent > something that is fundamentally unsigned like the size of a memory area. But it uses a very large integer. :) Consider that every time you do math on uint16_t, C is actually using a 32-bit signed integer. This is roughly the same. > This leads to have UINT64_MAX represented with {1, 0} instead of {0, > UINT64_MAX} > while {1, 0} is 2^64. > This again leads to have unnecessary and obfuscating transformations > with int128_2_64() > to test for UINT64_MAX and return {1,0} in memory_region_init() while using > inverse translation test{1,0} and return UINT64_MAX in memory_region_size() Yes, the use of UINT64_MAX for 2^64 is a hack, but it is unrelated to the signedness of Int128. Paolo