Matthew Dempsky

> In Montgomery, there is no separate carrying, and limbs are always saturated. It sounds like the current code uses an unsaturated Solinas representation? I'm not hip with the lingo,...

Here's a 64-bit scmul_8 implementation I came up with: ``` func fiat_p224_scmul_8(out1 *[4]uint64, arg1 *[4]uint64) { x1 := arg1[0] > 32 // Now add z * 2^96... m1, c1 :=...

> and with slightly extra complexity, I think scmul_3 should be doable too. Yeah, replacing the first few assignments with this seems to work as scmul_3, and is still measurably...

> Note that this isn't the kind of code we can write for Montgomery, because for the Montgomery code, we only have access to the prime as an integer, not...

Alternatively: ``` $ python3 foo.py P-224: [224, 0] - [96] P-256: [256, 32, 6, 4] - [33, 10, 5, 0] P-384: [384, 128, 32] - [129, 96, 0] P-521: [521]...

Here it is as 32-bit/64-bit limb sequences (in little endian): ``` $ python3 limb.py p224/32: [1, 0, 0, 0, 0, 0, 0, 1] - [0, 0, 0, 1, 0, 0,...

> One thing we could do is remove the path from the name and just have ambiguous names. There still needs to be underlying uniqueness of the names for the...

The backport CL is https://go-review.googlesource.com/c/go/+/429895 It's intentionally minimally invasive to address the issue while minimizing risk of collateral damage. Specifically, instead of hitting an ICE while emitting broken dictionary symbols,...

> type I interface { m() interface { I } } is equivalent to type I interface { m() I }. No, they're not. > Is this only limited to...

All interface type literals must expand to canonical, embedding-free representations.