SHA1NEXTE

SHA1NEXTE supplies the fifth SHA-1 working variable, E, which SHA1RNDS4 has no room for. Its first operand is a copy of the state A, B, C and D taken before the last four rounds, with A in dword 3; its second holds the message words of the next four rounds, W[t] in dword 3. It rotates the old A left by 30 bits, which is E after four rounds, adds it to W[t], and writes that sum with the other three words unchanged over the first operand. The result is exactly the second operand SHA1RNDS4 wants, so the two alternate through a block: SHA1RNDS4’s page shows the loop, and where the first E and the final one come from.

Why E is a rotate#

In each SHA-1 round of FIPS 180-4, E takes D, D takes C, C takes B rotated left by 30, and B takes A. Followed through four rounds, the E that comes out is the A that went in, rotated by 30, with no arithmetic, which is why the instruction needs only the old state. A case recorded on Zen 5 shows it plainly: with the message words all zero, dword 3 of the result was the old A, 510E527Fh, rotated by 30, D443949Fh, and the other three dwords were zero.

Operand details#

• Only dword 3 of the first operand is read; its other three dwords are overwritten.
• The addition is modulo 2^32, like every addition in SHA-1.
• There is only the legacy SSE encoding, NP 0F 38 C8: bits 128 and up of the register are left alone, and a memory operand must be aligned to 16 bytes.
• It needs the SHA extension (CPUID leaf 7, EBX bit 29). With GCC 14, _mm_sha1nexte_epu32 compiles under -msha or an -march that has SHA, such as goldmont, icelake-client, alderlake or znver1; skylake, skylake-avx512 and x86-64-v4 lack it.

AMD’s Zen 5 guide lists SHA1NEXTE as microcoded, like the other SHA-1 instructions. SHA1MSG1 and SHA1MSG2 compute the message words it adds to.

In the optimization guide

What the optimization guide says about SHA1NEXTE, a line per claim. Each links to the claim in the guide, with its sources and where they differ.

Silvermont to Goldmont Plus

• Vectors and cryptography: Goldmont is the first Atom core with the SHA extensions and RDSEED.

Forms

Operation

What the forms do, in pseudocode that our tests run against results recorded on real processors. How to read.

# xmm1: the state A, B, C, D four rounds
# before; src2: the next four words
e = rol(xmm1.d[3], 30, 32)  # E now
xmm1.d[3] = src2.d[3] + e
xmm1.d[2] = src2.d[2]
xmm1.d[1] = src2.d[1]
xmm1.d[0] = src2.d[0]
# bits 128 and up of the register are unchanged

Operands

Flags

None: XED records no flag that the forms test or change.

Exceptions

The exception class is XED's name for the set of exception conditions that a form follows. How to read.

All forms

SSE_TYPE_4

Attributes

What else XED records about the forms. How to read.

Memory forms

aligned memory operand

Intrinsics

The C intrinsics of Clang 23.1.2 that compile to SHA1NEXTE, each with the form it compiles to and the Clang options it needs. The forms come from compiling every intrinsic and decoding the result with Intel XED; all intrinsics A–Z explains the method.

CPUID and processors

Each form belongs to an XED ISA set. A form can be used when the processor reports every CPUID bit of one of its ISA set's alternatives.

More SHA instructions

• SHA1MSG1
• SHA1MSG2
• SHA1RNDS4
• SHA256MSG1
• SHA256MSG2
• SHA256RNDS2