0

It seems like to be able to add the max 64 bit value immediate you have to use the movabsq instruction, and cannot just do movq or mov. For example, here is what I did to test:

movq    $0xFFFFFFFFFFFFFFFF, %rbx
mov     $0xFFFFFFFFFFFFFFFF, %rbx
movq    $0xEFFFFFFFFFFFFFFF, %rbx # starts with 'E' // probably added as 8-
mov     $0xEFFFFFFFFFFFFFFF, %rbx # starts with 'E' // bytes because cannot be
movabsq $0xFFFFFFFFFFFFFFFF, %rbx #                 // reduced by sign-extension

And it assembled as:

 0x0000000000401000  48 c7 c3 ff ff ff ff           ? mov    $0xffffffffffffffff,%rbx
 0x0000000000401007  48 c7 c3 ff ff ff ff           ? mov    $0xffffffffffffffff,%rbx
 0x000000000040100e  48 bb ff ff ff ff ff ff ff ef  ? movabs $0xefffffffffffffff,%rbx
 0x0000000000401018  48 bb ff ff ff ff ff ff ff ef  ? movabs $0xefffffffffffffff,%rbx
 0x0000000000401022  48 bb ff ff ff ff ff ff ff ff  ? movabs $0xffffffffffffffff,%rbx

Why does this occur? For example, why does the mov/movq add it as a four-byte value, 0x FF FF FF FF? Whereas it tries to add it as an 8-byte immediate when the value is less than the 8-byte max. And the only way I'm only to get the full value is specifying movabsq (without doing a trick like -1 or something). Or, is the assembly trying to be 'smart' and just seeing 'oh, this value is the same as 32-bit sign extended and we can save 4 bytes by doing Move imm32 sign extended to 64-bits to r/m64. ?

And if the answer is yes to that question, is part of the responsibility of the assembler to 'improve/reduce possible assembly inefficiencies'? Or does that fall to the compiler, and the assembler is merely supposed to take the assembly presented to it and put it into ELF (or whatever format the target is)?

David542
  • 104,438
  • 178
  • 489
  • 842
  • 2
    Yes, assemblers always pick the smallest valid encoding, that's part of the benefit of using one instead of writing machine code by hand. If they didn't, you have to worry about telling them how to optimize the encoding for every instruction. (Although the existence of `movq` vs. `movabs` in the first place already is something like that. However, the use-case is for symbol address that aren't known until link-time) – Peter Cordes Oct 10 '20 at 03:52
  • @PeterCordes I see, so I sort of answered my question then -- the assembler is just optimizing the output by sign-extending. And that link explains the other part. Also, this link is good if you want to add it: https://stackoverflow.com/questions/52434073/whats-the-difference-between-the-x86-64-att-instructions-movq-and-movabsq (oh, you just added it, thanks) – David542 Oct 10 '20 at 03:57
  • @PeterCordes by the way, I'm sure I'm not the first to say, but why not write a book or blog or something with a collection of all your great answers on SO (and code golf too, some of those are so neat). I'm sure that'd be a lot more long-lasting than helping people like me with my very-very-basic assembly questions :) – David542 Oct 10 '20 at 04:02
  • 1
    You can browse my answers on https://stackoverflow.com/users/224132/peter-cordes. And https://stackoverflow.com/tags/x86/info links to some of them. I've considered writing a book, but that would be a lot of work and anything set in stone (or even ink) can't be updated when things change, or I find out I made a mistake, or whatever. Plus, I like a short deep-dive on one narrow thing, without necessarily having to combine it all into a coherent introduction to anything. – Peter Cordes Oct 10 '20 at 04:07

0 Answers0