From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55918) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zw4vI-0001BU-HY for qemu-devel@nongnu.org; Tue, 10 Nov 2015 04:09:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zw4vD-00084j-DX for qemu-devel@nongnu.org; Tue, 10 Nov 2015 04:09:04 -0500 Received: from e06smtp10.uk.ibm.com ([195.75.94.106]:45962) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zw4vD-000849-2f for qemu-devel@nongnu.org; Tue, 10 Nov 2015 04:08:59 -0500 Received: from localhost by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 10 Nov 2015 09:08:56 -0000 Received: from b06cxnps4074.portsmouth.uk.ibm.com (d06relay11.portsmouth.uk.ibm.com [9.149.109.196]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id 078A81B0806E for ; Tue, 10 Nov 2015 09:09:11 +0000 (GMT) Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id tAA98sox5767474 for ; Tue, 10 Nov 2015 09:08:54 GMT Received: from d06av03.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id tAA98sld021384 for ; Tue, 10 Nov 2015 02:08:54 -0700 References: <1446740339-31366-1-git-send-email-pmorel@linux.vnet.ibm.com> <563B8498.7070804@redhat.com> <563C6695.7030507@linux.vnet.ibm.com> <563CD658.9060507@redhat.com> <56408B28.8070408@linux.vnet.ibm.com> <56408FA8.60602@redhat.com> From: Pierre Morel Message-ID: <5641B425.8060304@linux.vnet.ibm.com> Date: Tue, 10 Nov 2015 10:08:53 +0100 MIME-Version: 1.0 In-Reply-To: <56408FA8.60602@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed 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: Paolo Bonzini , qemu-devel On 11/09/2015 01:20 PM, Paolo Bonzini wrote: > > On 09/11/2015 13:01, Pierre Morel wrote: >>>> 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. >> OK, we agree it is a hack, >> but sorry, I should have missed something, >> because I do not understand what this hack is useful for. > It's used in the size argument of memory_region_init*, so that it can > remain an uint64_t. The size is usually small (up to 2^40, say) unless > it is 2^64 meaning "the whole address space". The latter case is > covered by UINT64_MAX. > > Paolo > OK, I understand, thanks for having taking time for me. To sum-up size is a size :-) and not an offset in memory. Size of UINT64_MAX does not exist but we can live without it, having a description for "whole address space", 2^64, can be useful. Even there may be other solutions like taking 0 for 2^64, if a memory size of 0 has no meaning, but it could be misleading too. So I do not see better solution for this interesting problematic.