flat assembler
Message board for the users of flat assembler.

Index > Main > Instruction encoding (AMD64)

Goto page Previous  1, 2
Author
Thread Post new topic Reply to topic
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
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.
Post 23 Jul 2007, 18:49
View user's profile Send private message Reply with quote
sekigun



Joined: 23 Dec 2004
Posts: 18
Location: Japan
sekigun
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
Post 23 Jul 2007, 18:55
View user's profile Send private message Reply with quote
Niels



Joined: 17 Sep 2006
Posts: 255
Niels
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
Post 24 Jul 2007, 15:52
View user's profile Send private message Reply with quote
Niels



Joined: 17 Sep 2006
Posts: 255
Niels
Sekigun,

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

Niels
Post 24 Jul 2007, 16:04
View user's profile Send private message Reply with quote
Niels



Joined: 17 Sep 2006
Posts: 255
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
Post 24 Jul 2007, 16:12
View user's profile Send private message Reply with quote
sekigun



Joined: 23 Dec 2004
Posts: 18
Location: Japan
sekigun
Niels wrote:
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.
Post 24 Jul 2007, 17:32
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Actually signed imm8 is used when number is in -128..127 range, so the $80..$FF range is encoded using signed imm32.
Post 24 Jul 2007, 18:23
View user's profile Send private message Reply with quote
Niels



Joined: 17 Sep 2006
Posts: 255
Niels
sekigun wrote:
ADC RAX,0x1234 should be translated to ADC RAX(not r64),imm32 and it is.


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...

sekigun wrote:
The problem is you cannot enforce the encoding because of the operand size mismatch error.


I hope you see the light soon Smile

Niels
Post 24 Jul 2007, 18:37
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Code:
  adc rax, $12 ; Works, encoded as simm8
  adc rax, $1234 ; Works, encoded as simm32
  adc rax, $12345678 ; Works, encoded as simm32
    
Post 02 Aug 2007, 23:48
View user's profile Send private message Reply with quote
Niels



Joined: 17 Sep 2006
Posts: 255
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...
Post 03 Aug 2007, 13:16
View user's profile Send private message Reply with quote
Niels



Joined: 17 Sep 2006
Posts: 255
Niels
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" Smile
Post 03 Aug 2007, 13:23
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.