Memory barrier for fat initialization
nisse at lysator.liu.se
Thu Jan 15 19:28:57 UTC 2015
tg at gmplib.org (Torbjörn Granlund) writes:
> Which architectures do you intend to target for fat nettle builds?
x86_64 and arm are the most important.
> I really would want to move GMP towards fattyness for all current
> platforms. Unfortunately, this is not easy, and the problem is neither
> writing the actual code (fat.c, fat_entry.asm) nor getting memory
> ordering right. The real problem is robust CPU identification.
On ARM, linux (including android variants) is the most important kernel.
And on linux, it seems that reading /proc/cpuinfo is the easiest way.
(And if we care at all for apple ios or windows phones, it seems they
have less need for runtime detection).
See this post by Martin Storsjö,
> But config.guess causes many instances of SIGILL and whatnot. That is
> part of its design. Perhaps we could setup a signal handler in fat.c,
> but that is not very attractive. I wish all hardware manufacturers
> provided a cpuid-style instruction that runs in user mode.
Touching signal handlers in a library is not very nice. If there's no
better way, maybe fat.c could spawn a child process to do all the hairy
things,, and report the result back.
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
More information about the gmp-devel