FAT GMP 5 binaries

[Karl Hasselstrom]

--a8Wt8u1KmwUX3Y2C
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2003-05-14 19:04:38 +0200, Torbjorn Granlund wrote:

> Karl Hasselstrom <kha@treskal.com> 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.
>=20
> We will want to fix indexes, allowing user code to refer to
> __gmp_cpuvec.

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
>   nothing.)
>  =20
> 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
well.

--=20
Karl Hasselstr=F6m, kha@treskal.com
      www.treskal.com/kalle

--a8Wt8u1KmwUX3Y2C
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+wsQ3N7iPzXSoOQoRAvU1AJ9B4Y4WKnPVPRbv5IhhMwJDjMCB6gCeMOBS
BKJYxDqcc9ifAzN3GxVAKSk=
=8F0g
-----END PGP SIGNATURE-----

--a8Wt8u1KmwUX3Y2C--