FAT GMP 5 binaries
Thu, 15 May 2003 00:33:27 +0200
Content-Type: text/plain; charset=iso-8859-1
On 2003-05-14 19:04:38 +0200, Torbjorn Granlund wrote:
> Karl Hasselstrom <firstname.lastname@example.org> writes:
> So I'll chicken out and recommend that including/excluding a
> function from __gmp_cpuvec be made really easy, so it'll be easy
> to change.
> We will want to fix indexes, allowing user code to refer to
That will work, provided the set of functions in __gmp_cpuvec doesn't
mutate enough for the array to grow very sparse. But I must say I
personally don't care much for exposing this kind of icky details to
user code. Is there a point to this besides allowing user code to call
GMP routines like you described in the first post of this thread, i.e.
without using a wrapper function?
Besides, exposing the duplicated functions means we can't ever remove
a function from __gmp_cpuvec without breaking user code. Hmm. Unless
the array contains a pointer to the generic function if cpu-specific
functions aren't available.
> Maybe it would be a good idea to have the possiblity for _every_
> function to be duplicated, controlled by a single #define per
> function. (Some of that functionality will be needed anyway, since we
> presumably still want to be able to compile a library optimized for a
> single computer, preprocessing the whole __gmp_cpuvec machinery into
> Makes sense.
Just a thought: with every GMP function "pluggable" in this fashion,
this scheme could be used to handle user-supplied malloc() routines as
Karl Hasselstr=F6m, email@example.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
-----END PGP SIGNATURE-----