From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) by sourceware.org (Postfix) with ESMTPS id C248F385AE5E for ; Fri, 14 Oct 2022 20:42:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C248F385AE5E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-f47.google.com with SMTP id i83-20020a1c3b56000000b003c6c154d528so51413wma.4 for ; Fri, 14 Oct 2022 13:42:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:references:cc:to:from:subject :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=rOssNZa6gc/dRO3LtQoANx87mgUQoCJJqR48Aqg34IA=; b=y57nwz1K9lnxsKdBaSDFn1D26gIk0Tjm24paUxY/RTVkYAXEuJOBGrS4/JrVBx4r8e BDtmE7ZphYm9dCM8qb+TT2g7Op2Zd6Y+nwjASvnntYAB1BXyD8F+zkLOazMTxvXKbsbe 51AcIuv71GWTx0elIOcjSKp0/Ru+0TL0XCN0ewNBzRPge+0NJF8r+7IpPcz6G5qZFd/c o6pmu8MPncxF3DysfEFegeyCG7aXyCDZtMOe6eaR3ArmzBxOOdLtEAh5G3o2Lkame3vk VtV1zDIzJKVTMqvRVkBRjlasgf6g9MirFmLDvvJ4ouXbkSU1QSHAgYGsZ+w6QQ6PONSl GsAw== X-Gm-Message-State: ACrzQf1oZfUjWQEFaNzR0GFcqI5mOHIDf/tTOuznBQHzFOZupxvKzhUL ESPxK+b4CVykDRMdVTtPVQQ= X-Google-Smtp-Source: AMsMyM5S/fg1wCG9zzzLnUBBZ7GdZVziQ3vS9pmYANi20aj1qVlk8FCk1V9/MOSeiMZD90siWlUOhw== X-Received: by 2002:a05:600c:3595:b0:3b4:8378:98d2 with SMTP id p21-20020a05600c359500b003b4837898d2mr5133495wmq.64.1665780133595; Fri, 14 Oct 2022 13:42:13 -0700 (PDT) Received: from ?IPv6:2001:8a0:f93a:3b00:e038:5cdc:b8bf:4653? ([2001:8a0:f93a:3b00:e038:5cdc:b8bf:4653]) by smtp.gmail.com with ESMTPSA id q1-20020a056000136100b002301c026acasm2620660wrz.85.2022.10.14.13.42.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Oct 2022 13:42:11 -0700 (PDT) Subject: Re: gmp's c++ interface / mpz_class From: Pedro Alves To: gdb@sourceware.org Cc: "Zaric, Zoran (Zare)" References: Message-ID: Date: Fri, 14 Oct 2022 21:42:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2022-10-14 7:11 p.m., Pedro Alves wrote: > Zoran and I found a potential need for an integer type with precision of 64-bit + 8-bit, in order to > store bit offsets that can span a whole 64-bits address space. Instead of rolling our own, > I guess it makes sense to use libgmp, since, well, we already depend on it. I see that we have: > > /* A class to make it easier to use GMP's mpz_t values within GDB. */ > > struct gdb_mpz > { > > In gdb/gmp-utils.h. However, we need do to arithmetic on the type, and this wrapper > type doesn't implement operator+, operator-, etc, etc. I guess we could add those, > as wrappers around mpz_add, etc. Or use raw mpz_add, etc. directly. However, I just found > out that GMP already has its own C++ interface: > > https://gmplib.org/manual/C_002b_002b-Interface-General > > Before we explore this further, is there an already known reason we shouldn't be using > that interface? I played with this a bit. So gmp implements infinite precision by heap-allocating a growing buffer to hold the value storage. That's not surprising. However, what surprised me was that it _always_ heap-allocates, even for "regular" 8-bytes precision. I.e., it doesn't employ SBO (Small Buffer Optimization) to avoid heap allocation until the held value grows big. Like, this: mpz_class val; ... already calls malloc in the ctor. Hmm. Since we don't need infinite precision, it will end up a lot more efficient to roll our own type, with fixed (or templated) storage size. Like a simplified version of GCC's wide_int. Not sure yet whether efficiency really matters in practice, but I suspect it does. I'd still be curious about GMP's native C++ interface. Pedro Alves