Memory barrier for fat initialization

[Niels Möller]

tg at gmplib.org (Torbjörn Granlund) writes:

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

For a start, only checking existence of instructions. When it comes to
clever scheduling, I don't do very much.

The only nettle function currently implemented in assembler where it
might be beneficial to use different loops based on cpu model is memxor.
Iirc, using sse instructions gives a memxor speedup on some x86_64 cpus
and slowdown on others. This needs investigation.

> 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.

Hopefull they have *some* way to ask the kernel about cpu features.

> 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.

So then, if we want to avoid the sigill dance, we have to ask the kernel
about it, one way or the other.

>   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.

I think it's old tradition that libc forks various helper processes.
Which one may need to be aware of if registering a SIGCHLD handler, but
I think it's reasonably safe. I guess it was easier in the old days
before multithreading, though: there are some subtleties combining
threads and fork, but I think it's still possible.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.