Memory barrier for fat initialization

[Torbjörn Granlund]

nisse at lysator.liu.se (Niels Möller) writes:

  x86_64 and arm are the most important.
  
OK, those are interesting to GMP as well.

What's Nettle's intended "fat granularity"?

I assume existence of instructions is sometimes enough, e.g., if AES
hardware support exists then it seems safe to assume it outperforms
generic instructions.

But the GMP experience tells us that the exact schedule of insns can
improve performance by 2x.  This requires CPU identification, not just
detection of the available instructions.

  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).
  
I assume starting with ARM + Linux would make sense also for GMP.  I
won't work on Ios porting, as I am not about to pay the apple
programming tax.  I also don't have any apple or windoze phones.

But NetBSD would be cool to support; for PCs they have a /proc/cpuinfo
with quite similar structure as GNU/Linux.  Not sure about ARM.

  See this post by Martin Storsjö,
  http://lists.lysator.liu.se/pipermail/nettle-bugs/2015/003267.html.
  
I read parts.  I believe ARM has instructions and registers for
identifying the CPU.  Unfortunately, they are read-protected on user
mode.  They also seems to vary from device to device.

  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.
  
I am not sure forking is that neat either.

-- 
Torbjörn
Please encrypt, key id 0xC8601622