Live data from Hacker News

XOR'ing a register with itself is the idiom for zeroing it out. Why not sub?

devblogs.microsoft.com

191–200 of 231 posts

Re: XOR'ing a register with itself is the idiom for zeroing it out. Why not sub?

#191

Back in the stone ages XOR ing was just 1 byte of opcode. Habbits stick. In effect XORing is no longer faster since a long time.

The XOR trick is implemented as a (malloc from register file) on modern processors, implemented in the decoder and it won't even issue a uOp to the execution pipelines. Its basically free today. Of course, mov RAX, 0 is also free and does the same thing. But CPUs have limited decoder lengths per clock tick, so the more instructions you fit in a given size, the more parallel a modern CPU can potentially execute. So...…

sub is also recognized as zeroing idiom for register file. Intel documents these in "3.5.1.7 Clearing Registers and Dependency Breaking Idioms" from Optimization Reference Manual: https://www.intel.com/content/www/us/en/developer/articles/t...

Here's html version: https://zzqcn.github.io/perf/intel_opt_manual/3.html#clearin...

AMD has similar list in "2.9.2 Idioms for Dependency removal" from "Software Optimization Guide for the AMD Zen5 Microarchitecture" document: https://docs.amd.com/v/u/en-US/58455_1.00

Re: XOR'ing a register with itself is the idiom for zeroing it out. Why not sub?

#192
post #146

Earlier quoted context omitted.

You can do better. X86 has both "op [mem], reg" and "op reg, [mem]" variants of most instructions, where "[mem]" can be a register too. So you have two ways to encode "xor eax, eax", differing by which of the operands is in the "possible memory operand" slot, the source or the destination.

This one would be a fun challenge in a ctf, or maybe more appropriate for a puzzle hunt – most people would look at the dissassembly and not at the actual bytes and completely miss the binary encoding

Some disassembly listings will also include the actual bytes (there are multiple reasons why you will want this).

Re: XOR'ing a register with itself is the idiom for zeroing it out. Why not sub?

#193
post #184

Earlier quoted context omitted.

Temperature-dependent sex determination may not be at equilibrium now but is not an exception to Fisher's principle. The temperature at which sex determination switches is variable based on the parent's genes, and it will try to re-equilibrate with the environment temperature to obtain 1:1 ratios just like in other animals.

Indeed, that is why I wrote "may have been 50/50 before we started causing rapid climate change".

It's still not a violation of Fisher's principle, long term we would see natural selection move the threshold temperature upwards.

Re: XOR'ing a register with itself is the idiom for zeroing it out. Why not sub?

#194
post #144

SUB has higher latency than XOR on some Intel CPUs: latency (L) and throughput (T) measurements from the InstLatx64 project ( https://github.com/InstLatx64/InstLatx64 ) : | GenuineIntel | ArrowLake_08_LC | SUB r64, r64 | L: 0.26ns= 1.00c | T: 0.03ns= 0.135c | | GenuineIntel | ArrowLake_08_LC | XOR r64, r64 | L: 0.03ns= 0.13c | T: 0.03ns= 0.133c | | GenuineIntel | GoldmontPlus | SUB r64, r64 | L: 0.67ns= 1.0 c | T: 0.…

.03ns is a frequency of 33 GHz. The chip doesn't actually clock that fast. What I think you're seeing is the front end detecting the idiom and directing the renamer to zero that register and just remove that instruction from the stream hitting the execution resources.

Re: XOR'ing a register with itself is the idiom for zeroing it out. Why not sub?

#195

Earlier quoted context omitted.

Not really. Itanium was a result of some people at Intel being obsessed by LINPACK benchmarks and forgetting everything else. It sucked for random memory access, and hence everything that's not floating-point number-crunching. Compiler can't hide memory access latency because it's fundamentally unpredictable. VLIW does magic for floating-point latency (which is predictable), but - As transistors got smaller, FP perfo…

Naive question: shouldn't vliw be beneficial to memory access, since each instruction does quite a lot of work, thus giving the memory time to fetch the next instruction?

- Even each instruction does a lot of work, it is supposed to do it in parallel, so time available to fetch the next instruction is (supposed to be) the same.

- Not everything is parallelisable so most of instructions words end up full of NOPs.

- The real problem are data reads. Instruction fetches are fairly predictable (and when they aren't OOO suck just as much), data reads aren't. An OOO can do something else until the data comes in. VLIV, or any in-order architecture, must stall as soon as a new instruction depends on the result of the read.

Re: XOR'ing a register with itself is the idiom for zeroing it out. Why not sub?

#196
post #84

Earlier quoted context omitted.

Those aren't the only resources. I could imagine XOR takes less energy because using it might activate less circuitry than SUB.

I'm not aware of any stories in the historical record of "real programmers" optimizing for power use, only for speed or code size.

Aerospace.

Re: XOR'ing a register with itself is the idiom for zeroing it out. Why not sub?

#197
Back in the early 1980s I leveled up my self taught Z80 assembly skills by reading a book that attempted to disassemble and explain the Sinclair Spectrum ROM.

I remember the very first ROM instruction was XOR A and this was already a revelation to me as I'd never considered doing anything other than LD A,0 to clear the accumulator.

Re: XOR'ing a register with itself is the idiom for zeroing it out. Why not sub?

#200

I use the carry flag in a lot of z80 assembly for communicating a status of an operation. XOR doesn’t mess with the carry flag, I think it’s another point in favor of xor. (Though I don’t remember even considering using sub)

This is the exact reason I remember from back in the 80's. Perform arithmetic, clear register, CF is still valid.
Post reply on HN