Hi Luciano,

On Jul 12, 2016, at 1:24 PM, Luciano Notarfrancesco <luchiano@gmail.com> wrote:

On Sat, Apr 23, 2016 at 7:48 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Plugins:
Upgrade LargeIntegersPlugin to v2.0
LargeInteger primitives now deal with 32-bits digits.  No change to image code.

Memory is 8 bytes aligned on Spur. When storing 32/64 bits large
integers values, allways fill the eight bytes whatever the
effectivily used size, rather than bother with dissertion of size.

Generate integer type checking as C macros rather than direct/indirect
interpreterProxy function call in plugins. This, and 32-bit accessing mean
singificantly faster large integer arithmetic.


Awesome!
The legs are in the architecture endianness?
What are the reasons to not use GMP?

1. the existing code is functional and adequate.  GMP offers no new functionality and may offer performance improvements or may not.  But the existing code is capable of being tuned also.

2. The existing plugin is internal; with the "new" linkage I wrote two years ago now internal plugins have a much simpler call interface into the VM (no double calls through a pointer anymore; just direct calls on the VM functions). But LGPL forces us to make the plugin external.  Hence using GMP implies a loss of performance in marshaling arguments and allocating and returning results.

IMO these two together make GMP irrelevant.  Less compelling reasons are

3. Yet another library to install on all build environments; AFAIA it's not present on non-Linux platforms

4. Being a library we don't control we're dependent on others fixing it.

What reasons, other than brand identity are there for using GMP?

Could we use it if was already installed in the host platform? It seems to me that it would be quite straight forward to call to the GMP low-level API from the LargeIntegersPlugin, without making any changes in the image. https://gmplib.org/manual/Low_002dlevel-Functions.html