On Sat, 2015-01-17 at 09:42 +0100, Niels Möller wrote:

> > I didn't like the duplication of code either. I'm not very skilled in
> > m4, but I though that x86_64/ could include the fat variant and use the
> > non-sse2 variant.
> I think I'd prefer to do it the other way around, with memxor-1.asm and
> memxor-2.asm both including x86_64/memxor.asm, just defining USE_SSE2
> differently. With little actual code under fat/. Do you see any problem
> with that approach?

No (but no idea how to implement it).

> > The code in fat.c is quite elaborate on the cases it handles. The more
> > functions added the more unmanageable the code will become. Would it
> > make sense to restrict that support to the systems where ifunc is
> > available? Then the addition of new optimized functions becomes very
> > simple.
> I agree that as more functions are added, we need some macros for the
> boilerplate code. But I think that can be done without dropping support
> for the non-ifunc systems. Basically, use an alternative definition of
> your DEFINE_FAT_FUNC which defines a wrapper function and an init
> function, instead of a resolver function.

I realized that non-ifunc systems are desirable, or windows support goes
away. I couldn't make wrapper functions using macros. What I'm thinking
is a perl script which auto-generates the wrapper functions by reading
fat.c and the header files. What would you think of that?

regards,
Nikos


_______________________________________________
nettle-bugs mailing list
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs

Reply via email to