Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

devblogs.microsoft.com

Post reply on HN
Print view View original

51–60 of 231 posts

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

#51

Post by asQuirreL »

themafia wrote: post #8
NewCzech wrote: post #4

The obvious answer is that XOR is faster. To do a subtract, you have to propagate the carry bit from the least-significant bit to the most-significant bit. In XOR you don't have to do that because the output of every bit is independent of the other adjacent bits. Probably, there are ALU pipeline designs where you don't pay an explicit penalty. But not all, and so XOR is faster. Surely, someone as awesome as Raymond C…

XOR and SUB have had identical cycle counts and latencies since the 8088. That's because you can "look ahead" when doing carries in binary. It's just a matter of how much floorspace on the chip you want to use. https://en.wikipedia.org/wiki/Carry-lookahead_adder The only minor difference between the two on x86, really, is SUB sets OF and CF according to the result while XOR always clears them.

A carry lookahead adder makes your circuit depth logarithmic in the width of the inputs vs linear for a ripple carry adder, but that is still asymptotically worse than XORs constant depth.

(But this does not discount the fact that basically all CPUs treat them both as one cycle)

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

#52

Post by tliltocatl »

IshKebab wrote: post #48
signa11 wrote: post #32

Earlier quoted context omitted.

indeed. riscv for instance. also, afaik, xor’ing is faster. i would assume that someone like mr. raymond would know…

> afaik, xor’ing is faster Even tiny tiny CPUs can do sub in one cycle, so I doubt that. On super-scalar CPUs xor and sub are normally issued to the same execution units so it wouldn't make a difference there either.

On superscalars running xor trick as is would be significantly slower because it implies a data dependency where there isn't one. But all OOO x86's optimize it away internally.

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

#54

Post by pif »

signa11 wrote: post #32
shawn_w wrote: post #27

Earlier quoted context omitted.

Quite a few architectures have a dedicated 0 register.

indeed. riscv for instance. also, afaik, xor’ing is faster. i would assume that someone like mr. raymond would know…

Which part of "mathematical operations don’t reset the NaT bit" did you not understand?

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

#55

Post by flohofwoe »

empiricus wrote: post #23

The hw implementation of xor is simpler than sub, so it should consume slightly less energy. Wondering how much energy was saved in the whole world by using xor instead of sub.

I doubt any of that is measurable, since all ALU operations are usually implemented with the same logic (e.g. see https://www.righto.com/2013/09/the-z-80-has-4-bit-alu-heres-...)

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

#56

Post by fredoralive »

recursivecaveat wrote: post #39
tliltocatl wrote: post #21

Earlier quoted context omitted.

What's SMT in this context?

Simultaneous Multi-Threading (hyper-threading as Intel calls it). I'm not a cpu guy, but I think the ALU used for subtraction would be a more valuable resource to leave available to the other thread than whatever implements a xor. Hence you prefer to use the xor for zeroing and conserve the ALU for other threads to use.

By the time you get to a CPU complex enough to be to have SMT it is likely to detect these “clear register” patterns and special case them.

XOR would also be handled by the ALU, the L is for logic.

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

#57

Post by defrost »

defmacr0 wrote: post #36
NewCzech wrote: post #4

The obvious answer is that XOR is faster. To do a subtract, you have to propagate the carry bit from the least-significant bit to the most-significant bit. In XOR you don't have to do that because the output of every bit is independent of the other adjacent bits. Probably, there are ALU pipeline designs where you don't pay an explicit penalty. But not all, and so XOR is faster. Surely, someone as awesome as Raymond C…

I would be surprised if modern CPUs didn't decode "xor eax, eax" into a set of micro-ops that simply moves from an externally invisible dedicated 0 register. These days the x86 ISA is more of an API contract than an actual representation of what the hardware internals do.

From TFA:

  The predominance of these idioms as a way to zero out a register led Intel to add special xor r, r-detection and sub r, r-detection in the instruction decoding front-end and rename the destination to an internal zero register, bypassing the execution of the instruction entirely. You can imagine that the instruction, in some sense, “takes zero cycles to execute”.

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

#58

Post by enduku »

I ran into this rabbithole while writing an x86-64 asm rewriter.

xor was the default zeroing idiom.I onkly did sub reg,reg when I actually want its flags result. Otherwise the main rule is: do not touch either form unless flags liveness makes the rewrite obviously safe. Had about 40 such idioms for the passes.

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

#59

Post by JuniperMesos »

defrost wrote: post #10

Once an instruction has an edge, even if only extremely slight, that’s enough to tip the scales and rally everyone to that side. And this, interestingly, is why life on earth uses left-handed amino acids and right-handed sugars .. and why left handed sugar is perfect for diet sodas.

This is a hypothesis about why the chirality of life on earth is what it is, but I don't think there's enough evidence to state that this (or any competing hypothesis) is definitely the correct explanation.

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

#60

Post by b1temy »

Back when I was in university, one of the units touching Assembly[0] required students to use subtraction to zero out the register instead of using the move instruction (which also worked), as it used fewer cycles.

I looked it up afterwards and xor was also a valid instruction in that architecture to zero out a register, and used even fewer cycles than the subtraction method; but it was not listed in the subset of the assembly language instructions we were allowed to use for that unit. I suspect that it was deemed a bit off-topic, since you would need to explain what the mathematical XOR operation was (if you didn't already learn about it in other units), when the unit was about something else entirely- but everyone knows what subtraction is, and that subtracting a number by itself leads to zero.

[0] Not x86, I do not recall the exact architecture.

Post reply on HN