From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48484) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zw7nN-0008Ju-UD for qemu-devel@nongnu.org; Tue, 10 Nov 2015 07:13:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zw7nK-0003SX-N3 for qemu-devel@nongnu.org; Tue, 10 Nov 2015 07:13:05 -0500 Received: from e06smtp12.uk.ibm.com ([195.75.94.108]:42912) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zw7nK-0003RB-De for qemu-devel@nongnu.org; Tue, 10 Nov 2015 07:13:02 -0500 Received: from localhost by e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 10 Nov 2015 12:13:00 -0000 Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id DFCC017D8042 for ; Tue, 10 Nov 2015 12:13:14 +0000 (GMT) Received: from d06av07.portsmouth.uk.ibm.com (d06av07.portsmouth.uk.ibm.com [9.149.37.248]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id tAACCuH06226318 for ; Tue, 10 Nov 2015 12:12:56 GMT Received: from d06av07.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av07.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id tAACCurg010041 for ; Tue, 10 Nov 2015 05:12:56 -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> <5641B425.8060304@linux.vnet.ibm.com> From: Pierre Morel Message-ID: <5641DF48.3020603@linux.vnet.ibm.com> Date: Tue, 10 Nov 2015 13:12:56 +0100 MIME-Version: 1.0 In-Reply-To: <5641B425.8060304@linux.vnet.ibm.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/10/2015 10:08 AM, Pierre Morel wrote: > > > 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. > > > My problem with this came because usually, on hardware, region are easier described by start/end rather than by start/size. But changing this in the actual implementation would be too much.