3 ms·
There'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 s
by jedimastert 7y ago
There'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.
- murderfs 7y agoIf you're going to do something like that, you might as well steal from the register numbering bits instead. (many architectures have done this: Intel has lots of short-form encodings for "op {al, ax, eax, rax} #imm", and ARM has Thumb, which basically chops the register count in half for all instructions to shorten their encoding)
- vidarh 7y agoM68000 has a MOVEQ #imm, Dn Since its instructions are always multiples of 16bit though, the immediate value is 8 bit, so slightly more useful, but the most common use of it was certainly setting a register to 0
- epx 7y agoTrivia: MIPS and RISC-V have the r0 register equal to zero to optimize this case in a more elegant way.
- will4274 7y agoSo does x64, almost. More accurately, so do the underlying Intel and AMD micro-archs that host x64.