4 ms·
This is the XOR AX,AX of the 21th century
by epx 7y ago
This is the XOR AX,AX of the 21th century
- omginternets 7y agoWhat's XOR AX,AX of the 20th century?
- fourthark 7y agoShorter (in assembled bytes) and faster than MOV AX,0 https://stackoverflow.com/questions/33666617/what-is-the-best-way-to-set-a-register-to-zero-in-x86-assembly-xor-mov-or-and https://stackoverflow.com/questions/33666617/what-is-the-bes...
- Doctor_Fegg 7y agoGoes back to the 8080, in fact.
- root670 7y agoFastest way to zero a register.
- csirob 7y agoWhat is a 'register'? /s :)
- nemo1618 7y agoxor'ing a value with itself produces 0, so XOR AX,AX is equivalent to "AX = 0". It's a common trick in assembly code because it's faster (and/or maybe more compact, can't remember) than the more obvious MOV AX,$0.
- deleted 7y ago[deleted]
- navaati 7y agoThis is assembly. This instruction is doing an boolean "Exclusive Or" of a register named "AX" (think of a register like a hardware variable) with itself into itself. This always leave the register containing 0, because 0 XOR 0 = 0 and 1 XOR 1 = 0. And for some weird reason, doing that was faster than just doing MOV AX, 0 (which is literally "Move 0 into AX", so "AX = 0" in more familiar syntax). Edit: Oh man, my fellow HN'ers, as I did, all jumped on the occasion to show off :)
- omginternets 7y agoAh! Wow, that is surprising. Why was it so much faster?
- jedimastert 7y agoThere's a bunch of overhead associated with reading a constant from the program and moving that to the register. Math operations, on the other hand, are very simple to do because it's baked right into the CPU, only requiring one instruction and a few cycles
- murderfs 7y agoNo, the reason is that `xor ax, ax` has a shorter encoding, because it only takes 3 bits to encode a register on 32-bit x86, and far more bits are required for a useful immediate move. It would be ridiculous to have a short encoding for `mov rN, #imm` where the immediate has to be in the range 0-7.
- tomtomtom777 7y ago> It would be ridiculous to have a short encoding for `mov rN, #imm` where the immediate has to be in the range 0-7. Such instruction didn't exist but I wouldn't call it ridiculous. It would actually be quite useful as setting a register to 3 is far more common than setting a register to 7911.
- 7y ago
- jedimastert 7y agoThe op "XOR" the the "xor" operation between two things and stores the result in the first operand. "XOR"ing a number with itself always results in 0, which is then stored in the operand itself. This operation was almost always faster than moving a constant (like 0) into a register, because of all of the overhead of making the constant and reading and writing.
- WorldMaker 7y agoI've wondered about that with JSON.parse(JSON.stringify(obj)) being the fastest way to deep clone a plain JS object in any JS engine. It always looks dumb when it shows up, but it works well enough and I've seen it described as a best practice by some types of data manipulation libraries.
- vorticalbox 7y agoWould like to know this aswell. I know using spread const clone = {...source}; Is faster than object.assign({},source) And seeing as in this case the source is already a js object it would probably be slow to string and the parse.
- WorldMaker 7y agoKeep in mind that both of those two options are only shallow clones. If you've got any bit of nesting and need a deep clone the code starts to get a lot more complex. In general, in places where I "need" a lot of deep clones I try to use an Immutable library with good reuse/sharing tools, but when you have to deep clone a plain JS object JSON.parse(JSON.stringify(obj)) is incredibly fast in most browsers, despite the fact that you would think string allocation might be a bottle neck.