Assembly backend for >= 384-bit primes

[mratsim]

The current assembly backend is restricted to up to 384-bit primes (6 limbs) as otherwise it requires register spilling.

constantine/constantine/arithmetic/limbs_montgomery.nim

Lines 302 to 311 in 7f0f511

	when canUseNoCarryMontyMul:
	when UseASM_X86_64 and a.len in {2 .. 6}: # TODO: handle spilling
	if ({.noSideEffect.}: hasBmi2()) and ({.noSideEffect.}: hasAdx()):
	montMul_CIOS_nocarry_asm_adx_bmi2(r, a, b, M, m0ninv)
	else:
	montMul_CIOS_nocarry_asm(r, a, b, M, m0ninv)
	else:
	montyMul_CIOS_nocarry(r, a, b, M, m0ninv)
	else:
	montyMul_FIPS(r, a, b, M, m0ninv)

For Zero-Knowledge one-layer proof composition, a curve needs to be embedded in another as in it's modulus should be the order of the other, for example this is the case of BLS12-377 + CP6-782 (Zexe) or BLS12-377 + BW6-761 (Celo) see #93, the embedding curve has a large prime field for which there is no assembly at the moment.

Similarly, the curve MNT4-753 and MNT6-753 for recursive proofs are also much larger than 384-bit.

[jon-chuang]

Kilic's impl produces very good results for these limbs > 6

[mratsim]

Did you measure the performance against Goff? It seems quite simple https://github.com/ConsenSys/goff/blob/fa7dd55e/asm/amd64/element_mul.go#L70-L83

[jon-chuang]

Goff's method is naive push and pop, so I assume slow. Kilic splits up the inner loop so there is less data movement