Convert YASM code to inline assembly #128

• Updates the assembly code to use @peterdettman's parallel multiplication algorithm.
• Convert the YASM code to inline asm blocks.

Any performance impact?

This is going to be MSVC incompatible. Do we care?

@gmaxwell Haven't benchmarked yet, but I would be very surprised, as the object code generated from the assembly blocks is identical, except there's one less function call involved (secp256k1_fe_mul_inner is now inlined into secp256k1_fe_mul). @gmaxwell Was the previous code working in MSVC at all?

+1 If the inline asm conditions are properly and fully specified, sometimes the code is slightly more efficient, as the compiler has more information to work with.

Chatter from bitcoin-dev

07:34 @gmaxwell (MSFT decided that for 64-bit they were not going to support inline asm... apparently windows developers were disrupting msft's portability hopes by needlessly writing too much of their software in ASM.) 07:34 @gmaxwell sipa: yes, assuming someone adds yasm to their msvc setup. 07:34 < sipa> well, if MSFT doesn't like app developers writing ASM, they won't get any ASM... 07:34 @gmaxwell instead they'd have to add GCC to it. :) 07:35 @gmaxwell I am not arguing against it. Just making sure we know and are all okay with it. I certantly am okay with it.

(I support this, and would have ACKed right away too except it'll take me a bit to review and test)

So on a fedora host here, gcc version 4.8.3 20140624 (Red Hat 4.8.3-1) (GCC)

w/ endomorphism configure: Using field implementation: 64bit_asm configure: Using bignum implementation: gmp configure: Using scalar implementation: 64bit

bench_sign and bench_verify are segfaulting. The tests pass, however.

segfault is at 0x0000000000400b59 <+25>: push %rbp 0x0000000000400b5a <+26>: mov %rdx,%r15 0x0000000000400b5d <+29>: mov (%rsi),%r10 0x0000000000400b60 <+32>: mov 0x8(%rsi),%r11 0x0000000000400b64 <+36>: mov 0x10(%rsi),%r12 0x0000000000400b68 <+40>: mov 0x18(%rsi),%r13 0x0000000000400b6c <+44>: mov 0x20(%rsi),%r14 0x0000000000400b70 <+48>: movabs $0x1000003d10,%rbp => 0x0000000000400b7a <+58>: mov (%r15),%rax 0x0000000000400b7d <+61>: mul %r13

Importantly: the tests crash too if I compile them without -DVERIFY. (I'd kinda worried we'd run into something like this eventually... the verify stuff is stirring the optimizer) Crashes go away at O0.

@gmaxwell Got it. Apparently, input arguments to the asm block are assumed to not be modified. I've changed the ones that are changed during execution to input/output arguments, which seems to fix the problem.

It's gratitiously incompatible with clang (at least some commonly deployed versions): http://llvm.org/bugs/show_bug.cgi?id=18916

Gah, to be compatible with OSX we need att_syntax? :(

You broke it now. :)

Converted to att syntax :(

ACK.