pbsd
Joined 15 years ago
Karma
2,790
Submissions
823
Member since
Nov 14
Joined 15 years ago
How to encode VEX.vvvv:
0: VEX.vvvv must be 1111b.
1: VEX.NDS. Register-only source is encoded in VEX.vvvv where
the content of source registers will be preserved.
VEX.DDS. The second register operand is encoded in VEX.vvvv
where the content of first source register will be overwritten
by the result.
VEX.NDD2. The second destination register operand is encoded in
VEX.vvvv for instructions with 2 destination register operands.
For assembler, there are no difference between VEX.NDS, VEX.DDS
and VEX.NDD2.
2. VEX.NDD. Register destination is encoded in VEX.vvvv for
instructions with 1 destination register operand.
3. VEX.LWP. Register destination is encoded in VEX.vvvv and one
of the operands can access a memory location.
[1] https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;... return n ? (1u + popcount(n & n - 1u)) : 0u;
which both Clang and GCC promptly optimize to a single popcnt. f(n) = 5226577487551039623 + 1537228672809129301*(1669582390241348315^n + 636260618972345635^n) + 3689348814741910322*(725554454131936870^n + 194643636704778390^n + 1781303817082419751^n + 1910184110508252890^n) mod (2^61-1).
This involves 6 exponentiations by n with constant bases. Because in fizzbuzz the inputs are sequential, one can further precompute c^(2^i) and c^(-2^i) and, having c^n, one can go to c^(n+1) in average 2 modular multiplications by multiplying the appropriate powers c^(+-2^i) corresponding to the flipped bits.The main difference there seems to be that GCC treats the if() as unlikely to be taken while the for() as likely.
Currently the best attacks on NTRU, Kyber, etc, are essentially the same generic attacks that work for something like Frodo, which works on unstructured lattices. And while the resistance of unstructured attacks is pretty well studied at this point, it is not unreasonable to suspect that the algebraic structure in the more efficient lattice schemes can lead to more efficient attacks. How efficient? Who knows.
The floating point schedulers have a slow region, in the oldest entries of a scheduler and only when the scheduler is full. If an operation is in the slow region and it is dependent on a 1-cycle latency operation, it will see a 1 cycle latency penalty.
There is no penalty for operations in the slow region that depend on longer latency operations or loads.
There is no penalty for any operations in the fast region.
To write a latency test that does not see this penalty, the test needs to keep the FP schedulers from filling up.
The latency test could interleave NOPs to prevent the scheduler from filling up.
Basically, short vector code sequences that don't fill up the scheduler will have better latency.[1] https://www.amd.com/content/dam/amd/en/documents/processor-t...
So yeah, it seems plausible P-224 and the B-* curves were generated at a later date.