The optimization discussed in that thread was making instructions spend few bytes while this immediate size feature actually is used to force the encoding to a particular size even when such size is not needed (from the instruction functionality point of view).

However, you sometimes need to align a loop code to a certain boundary, normaly you achieve it by adding NOPs (or instructions that not affect the context) above the loop label, but that wastes CPU cycles. A better way is to try to fill the gap by enlarging the instructions that do useful things so you don't waste cycles and you have an aligned label at the same time.

For example, if you need to advance $ three bytes to make $ aligned to 16 but you just need to do MOV EAX, EBX, you could replace it by LEA EAX, [byte EBX+0], however since you can't use "byte" fasm assembles the equivalent of LEA EAX, [EBX] which is two bytes, not three and hence $ mod 16 is 15 and not zero. Is highly probable that sekigun wants to enforce the use of dword imm in ADC because in his particular code he aligns something doing that and at the same time he adds the CF to RAX which behaves the same using signed 8-bit immediate or 32-bit signed immediate.

And about why AMD64 uses few 64 bit imms is because the instructions would be large as hell otherwise. The CPU can decode up to three instructions per cycle but only if the instructions are Single Path and the three fits in a 16 bytes boundary (something really hard to achieve with 64-bit operands considering that two 64 bit immediates fills 16 bytes and a instruction isn't composed of just immediates). The RIP relative addressing was also introduced to avoid encoding 64-bit offsets as 64-bit immediates.

PS: http://board.flatassembler.net/topic.php?t=3866#28240 <- Tomasz explanation of the decision.

OK, I got it.

use64
ADC RAX,0x12 ; 48 83 D0 12 ADC reg64,imm8
ADC RAX,0x1234; 48 15 34 12 00 00 ADC RAX,imm32
;ADC RAX,dword 0x12; 48 15 12 00 00 00 Heresy in FASM for some reason

LocoDelAssembly,

I am aware of the (old)'size-optimalisation'; Is the information you gave further on, a reason Tomasz decided to leave it out >> 'win on short instructions' against 'loss on align to boundary'?

Niels


ps.
Sekigun, for clearity:
BYTE 0X00 ; 8-bit
WORD 0X0000 ; 16-bit
DWORD 0X00000000 ; 32-bit
QWORD 0X0000000000000000 ; 64-bit

Sekigun,

Did you check opcode-tables or used a disassembler...?
I do think "ADC RAX,0x1234" will convert as "ADC RAX,imm16"...

Niels

Sekigun,

I looked in the Intel manual, there doesn't seem to be a "ADC r64,imm16"
So, from what I still know from fasm, it should have given you a (size-doesn't-match) error using "ADC RAX,0x1234"...

Niels

There isn't, ADC RAX,0x1234 should be translated to ADC RAX(not r64),imm32 and it is. The problem I found is that if the number is below 0xFF it gets "optimized" to ADC r64,imm8 which is not what one would expect.

The problem is you cannot enforce the encoding because of the operand size mismatch error.
ADC RAX,dword 0x1234 ;ERROR
ADC RAX,byte 0x12 ;ERROR
The first one affects only 64bit machines, however the second one affects every register size.

Actually signed imm8 is used when number is in -128..127 range, so the $80..$FF range is encoded using signed imm32.

No Sekigun, "ADC RAX,0x1234" should make an error and "ADC RAX,dword 0x1234" should be fine.
r64 means 64-bit register, so, RAX will do...



I hope you see the light soon

Niels

These don't get converted:

ADC RAX,byte 0x12
ADC RAX,word 0x1234
ADC RAX,dword 0x12345678

Niels

ps.
LocoDelAssembly, please actually READ and LISTEN this thread...

So, when the Manual is telling: "ADC r64,imm16" isn't present:

ADC RAX, 0x1234 ; Should give an error!!!
ADC RAX, dword 0x1234 ; Will convert 0x1234 to 0x00001234, the instruction is correct!!!

Niels

ps.
The auto-assume "word and dword is equal" is not logic and surpasses "FASM assume's nothing"