public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* gmp's c++ interface / mpz_class
@ 2022-10-14 18:11 Pedro Alves
  2022-10-14 20:42 ` Pedro Alves
                   ` (2 more replies)
  0 siblings, 3 replies; 7+ messages in thread
From: Pedro Alves @ 2022-10-14 18:11 UTC (permalink / raw)
  To: gdb; +Cc: Zaric, Zoran (Zare)

Hi!

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?

Pedro Alves

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: gmp's c++ interface / mpz_class
  2022-10-14 18:11 gmp's c++ interface / mpz_class Pedro Alves
@ 2022-10-14 20:42 ` Pedro Alves
  2022-10-19 10:28   ` Florian Weimer
  2022-10-17 10:44 ` Luis Machado
  2022-10-17 17:21 ` Tom Tromey
  2 siblings, 1 reply; 7+ messages in thread
From: Pedro Alves @ 2022-10-14 20:42 UTC (permalink / raw)
  To: gdb; +Cc: Zaric, Zoran (Zare)

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: gmp's c++ interface / mpz_class
  2022-10-14 18:11 gmp's c++ interface / mpz_class Pedro Alves
  2022-10-14 20:42 ` Pedro Alves
@ 2022-10-17 10:44 ` Luis Machado
  2022-10-17 11:29   ` Pedro Alves
  2022-10-17 17:21 ` Tom Tromey
  2 siblings, 1 reply; 7+ messages in thread
From: Luis Machado @ 2022-10-17 10:44 UTC (permalink / raw)
  To: Pedro Alves, gdb; +Cc: Zaric, Zoran (Zare)

On 10/14/22 19:11, Pedro Alves wrote:
> Hi!
> 
> 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:

Is uint128_t an option (at least temporarily)?

> 
>   /* 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?
> 
> Pedro Alves


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: gmp's c++ interface / mpz_class
  2022-10-17 10:44 ` Luis Machado
@ 2022-10-17 11:29   ` Pedro Alves
  0 siblings, 0 replies; 7+ messages in thread
From: Pedro Alves @ 2022-10-17 11:29 UTC (permalink / raw)
  To: Luis Machado, gdb; +Cc: Zaric, Zoran (Zare)

On 2022-10-17 11:44 a.m., Luis Machado wrote:
> On 10/14/22 19:11, Pedro Alves wrote:
>> Hi!
>>
>> 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:
> 
> Is uint128_t an option (at least temporarily)?

That is not portable, unfortunately.  It doesn't exist in all compilers, and/or all architectures.

So it's useful to prototype things, but it's not something we can use, because we need this in
core code (DWARF expression evaluation).

We may end up with something like a typedef that maps to int128_t when available,
and to a C++ class emulation when not available, though.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: gmp's c++ interface / mpz_class
  2022-10-14 18:11 gmp's c++ interface / mpz_class Pedro Alves
  2022-10-14 20:42 ` Pedro Alves
  2022-10-17 10:44 ` Luis Machado
@ 2022-10-17 17:21 ` Tom Tromey
  2022-10-24 13:34   ` Joel Brobecker
  2 siblings, 1 reply; 7+ messages in thread
From: Tom Tromey @ 2022-10-17 17:21 UTC (permalink / raw)
  To: Pedro Alves; +Cc: gdb, Zaric, Zoran (Zare)

>>>>> "Pedro" == Pedro Alves <pedro@palves.net> writes:

Pedro> In gdb/gmp-utils.h.  However, we need do to arithmetic on the type, and this wrapper
Pedro> type doesn't implement operator+, operator-, etc, etc.  I guess we could add those,
Pedro> as wrappers around mpz_add, etc.  Or use raw mpz_add, etc. directly.  However, I just found
Pedro> out that GMP already has its own C++ interface:

Pedro>  https://gmplib.org/manual/C_002b_002b-Interface-General

Pedro> Before we explore this further, is there an already known reason we shouldn't be using
Pedro> that interface?

I feel sure Joel and I have talked about it, but I don't remember what
reason there was any more.  The warning in the manual is a bit
off-putting, though:

       *Everything described in this chapter is to be considered preliminary
    and might be subject to incompatible changes if some unforeseen
    difficulty reveals itself.*

Pedro> Not sure yet whether efficiency really matters in practice, but I suspect it does.

I'm curious about this as well.

FWIW I've occasionally thought about replacing parts of valarith with GMP.
That way gdb could more easily support 128-bit integers.

Tom

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: gmp's c++ interface / mpz_class
  2022-10-14 20:42 ` Pedro Alves
@ 2022-10-19 10:28   ` Florian Weimer
  0 siblings, 0 replies; 7+ messages in thread
From: Florian Weimer @ 2022-10-19 10:28 UTC (permalink / raw)
  To: Pedro Alves; +Cc: gdb, Zaric, Zoran (Zare)

* Pedro Alves:

> 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.

I tried to use it recently in a hobby project, but it turned out to be a
poor fit because it's not integrated well with C++11 and later features
(no move constructors, no rvalue references).  The unconditional use of
malloc is rather off-putting, too.

I'm contemplating to use tagged integers/pointers as the main
representation, with heap allocation only on demand, maybe using the the
mpn* functions directly, or perhaps copy things out of a long-lasting
mpz_t object that's used as a temporary for arithmetic.

For 72-bit integers, that seems a bit over the top, though.

Thanks,
Florian


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: gmp's c++ interface / mpz_class
  2022-10-17 17:21 ` Tom Tromey
@ 2022-10-24 13:34   ` Joel Brobecker
  0 siblings, 0 replies; 7+ messages in thread
From: Joel Brobecker @ 2022-10-24 13:34 UTC (permalink / raw)
  To: Tom Tromey via Gdb; +Cc: Pedro Alves, Zaric, Zoran (Zare), Joel Brobecker

> Pedro> In gdb/gmp-utils.h.  However, we need do to arithmetic on the type, and this wrapper
> Pedro> type doesn't implement operator+, operator-, etc, etc.  I guess we could add those,
> Pedro> as wrappers around mpz_add, etc.  Or use raw mpz_add, etc. directly.  However, I just found
> Pedro> out that GMP already has its own C++ interface:
> 
> Pedro>  https://gmplib.org/manual/C_002b_002b-Interface-General
> 
> Pedro> Before we explore this further, is there an already known reason we shouldn't be using
> Pedro> that interface?
> 
> I feel sure Joel and I have talked about it, but I don't remember what
> reason there was any more.

Yes, we talked about it for sure, and decided against it, but I don't
remember the reasons, unfortunately :-(.

> The warning in the manual is a bit
> off-putting, though:
> 
>        *Everything described in this chapter is to be considered preliminary
>     and might be subject to incompatible changes if some unforeseen
>     difficulty reveals itself.*

I do remember this comment played a part.

-- 
Joel

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2022-10-24 13:34 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-10-14 18:11 gmp's c++ interface / mpz_class Pedro Alves
2022-10-14 20:42 ` Pedro Alves
2022-10-19 10:28   ` Florian Weimer
2022-10-17 10:44 ` Luis Machado
2022-10-17 11:29   ` Pedro Alves
2022-10-17 17:21 ` Tom Tromey
2022-10-24 13:34   ` Joel Brobecker

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).