Who is vfmaddrnd231pd??
75 points by valdemar
75 points by valdemar
As a man with dyslexia, some of Intel's newer instruction names feel outright spiteful.
Another funny one i just learned about while implementing floating point support in my jit compiler:
ucomisd
Which is just Unordered Compare Scalar Double Precision Floating-Point Values and Set EFLAGS; x86 is so complex to me, I really struggled with just making a constant double load work
The nice thing about x86 is that the manual sets expectations. The first instruction in the listing is AAA. This manages expectations in two important ways:
First, you discover that the first instruction relates to dealing with BCD in the most overcomplicated way imaginable.
Secondly the mnemonic is the sound that x86 assembly programmers make.
That said, I’m a fan of PowerPC’s EIEIO as an assembly mnemonic.
eieio was my favourite PPC instruction until xxlxor, which is just a joy to try to say. It's the BIGGEST EXCLUSIVE OR EVER.
Who says IBM doesn't have a sense of humour?
Secondly the mnemonic is the sound that x86 assembly programmers make.
This made me chuckle. I’ve been learning reverse engineering lately, and this pretty much represents my experience with Intel assembly 🫠
Despite the unintuitive naming, this is one of the easy instructions: it compares to FP numbers in the "usual way" and sets the flags (somewhat similar to regular cmp). There are things in x86 that are complex and worth complaining about, but not this?
Fp ops just feel bolted on, which i guess they are? Its just hard to like for me
They are, but FP/SIMD operations are pretty separate in almost all ISAs (both in encoding and registers -- primarily because the intersection of operations/used data is very low). I do find the SSE extensions (~1998) to be a pretty reasonable design and many more recent designs are actually rather similar. A modern ISA like AArch64 (~2011) has a more consistent naming of the instructions and can avoid some legacy, but their fcmp does pretty much the same as the x86 ucomisd.
See this example (Godbolt) comparing x86-64 with some other ISAs -- you can see some much worse ISAs like the x87 FPU and 32-bit ARM, where floating-point condition codes are in a separate register and sometimes need to be moved explicitly to the regular status code register first...
It's the good friend of FJCVTZS
The weird thing is I don't see what's JS-specific about this instruction. is it because it's dealing with double-precision FP?
It's the overflow behavior. JS defines float-to-integer conversion as: round the float to an integer, zero all bits except the bottom 32. This behavior is unusual, e.g. both x86 and the normal ARM conversion instruction saturate too large floats to 2^31 instead of using wrap-around. I guess emulating it is slow enough that adding hardware support was considered worthwhile.
And in this case, it's so simple that it's not a huge lift to add it (just taking the already-existing FCVTZS instruction and disconnecting the signal to raise an FP exception on overflow).
On a fun related note: changing the floating-point environment, in particular the rounding mode, is disallowed (considered UB) in Rust. You have to write assembly or switch to another language for it. It was frustrating to discover after I built some evil algorithms that involve int-to-float shenanigans and require particular rounding modes. IIRC AVX-512 has instructions like these but AVX2/FMA does not.
WhiIe was looking into that I found this github thread, which links this delightful program where setting the rounding mode to something other than the default causes out of bound reads.
https://github.com/rust-lang/unsafe-code-guidelines/issues/471
OK, wow. I thought that the time of ghost instructions ended in the LOADALL286/LOADALL386 era, but apparently not? :-)