Top 10 Craziest Assembly Language Instructions

In this video we’ll look at some of the most complex instructions available in x86/64 Assembly language.

I have checked against the manuals from Intel and AMD and results from hardware, but it is almost impossible to create a video without any mistakes. Please test the instructions yourself before you apply them in code.

Happy programming :)

References/Sources:

RDSEED object is based on “The Object” from Led Zeppelin’s Presence album.

Software used to make this vid:

[NotDwight]

TIL I learned there's an audience for top 10 videos about assembly instructions. Cool.

[electroflame]

Dot product of packed singles in your area

[davidjohnston]

RdSeed - It's not always slow. There's a FIFO on the output of the RNG. RdSeed pulls from that FIFO. If you haven't just pulled a bunch of values from the FIFO, the value will be available immediately because the FIFO is not empty. If you try to continuously pull from Rdseed and measure the average time per instruction, it will appear slower because you are limited to the physical rate of generation of full entropy numbers from the RNG, which requires a whole lot of computation - Generate 512 bits from the entropy source, AES-CBC-MAC them together to get 128 bits (that's two RdRand result's worth) XOR it with and output from the DRBG (another 3 AES operations, just like SP800-90C describes) stuff the two 64 bit numbers from the 128 bit result into the output FIFO. How do I know all that? I designed it.

[luck]

Wow, so the task I was given in a job interview was actually an assambler one-liner. Good to know.

[ChildOfTheLie]

Lol, this guy has that kind of voice that makes it sound like he's constantly on the brink of laughter

I can't get over this presentation. That's the kind of nerdy content you expect to find in a recording of a 10 year old talk that was given to 50 people in a tent :D

[Requiem]

I love how hyped this guy is about CPU instructions. Really fun to listen to.

[zrebbesh]

"HCF" -- Halt and Catch Fire.

On a lot of early CPUs (1970s/1980s, yes damnit I am old) the manual gave the bit pattern for each instruction - and the the rest of the bit patterns did undocumented things. Some were just a different way to spell NOP, some did deeply bizarre unintended things that happened because the bits randomly activated chunks of the CPU circuitry that mixed and matched chunks that were used in different combinations for other commands, and some did things that were only ever intended to be done in the factory, during QA testing.
We used to hunt through these "undocumented instructions" looking for anything interesting or cool that we could then figure out uses for. But this was a bit risky. A fair number of CPUs had at least one undocumented instruction that would immediately cause the machine to lock up and, a few seconds later, destroy the CPU. Sometimes they caught fire, sometimes they melted through the PCB. Sometimes they desoldered themselves from the board and fell out. Whenever we found it we called it a "Halt And Catch Fire" instruction and patched the name 'HCF' into our macro assembler for that bit pattern, in order to avoid accidentally finding it again.
Naturally when I saw the title of this video I figured HCF would be at the top of the list.
Finding an HCF usually meant a new version of the chip as soon as the company could mask it off. We thought of ourselves as contributing to their QA efforts, although very few of them thanked us for it.

[xABADCAFE]

So the most amazing thing about these instructions to me is the fact so many of them run in single digit cycles. You have to marvel at the engineering effort that has gone into it. Also, a compiler has to basically be sentient to know when and how to use some of these.

[Andrath]

You'd almost think silicon makers like to mess with compiler writers.

[DukePaprikar]

Yeah, watch-mojo really dropped the ball by not covering this one.

[zactron]

Good lord that poor silicon. I can't even begin to imagine how you'd design chips to implement some of these instructions. I'd love to see a followup video showing some examples of using these instructions, and if they're superceded, what should be used instead!

[flowerpt]

Intel: One cycle
Bioinformaticists: lemme reimplement that in Python and take 300, 000 cycles to compute the same thing.

[icarvs_vivit]

#1 is the definition of insane and incredibly useful.
Thank you for translating the Enginese into English.
Now I can delete my string comparison macros forever.

[ZILtoid]

PMADDWD is quite useful for fast affine transformation functions. On SSE2, I can even calculate two pixels at once

[redsmith]

I just remember, porting the torque game engine to PSP, and from all the work, the CMPXCHG instruction for the mutex, i implemented some native PSP intrinsic to do that, good memories, the best optimization trick also, the game was doing 10 fps at the best, the problem was matrix transposition, between the engine and PSP "opengl", so i made a transposition on the fly changing the order of reading and writing of the registers in the VFPU instructions, kicking the Sony engineers 'axe' ; ), and getting 30 fps, enough to pass their performance standards.

[soranuareane]

CMPXCHG is how mutual-exclusion, locks, and semaphores are implemented in systems like QEMU. I remember having to fix a bug with a race condition in the QEMU Sparc interpreter by adding judicious use of CMPXCHG locking. It's an amazing instruction and, with its guaranteed atomic behavior, can be used to trivialize mutexes.

[ishdx]

the last one seems so damn complex it's unbelievable it takes 3-4 cycles

[WarpRulez]

You know that an instruction is complex if implementing it in a higher-level programming language would take literally hundreds of lines of code.

[FinaISpartan]

Can't wait till you remake this vid in 10 years with all the custom RISC-V extension instructions. Gonna be pretty wild to see what people come up with.