flat assembler
Message board for the users of flat assembler.

Index > Main > Instruction encoding (AMD64)

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
sekigun



Joined: 23 Dec 2004
Posts: 18
Location: Japan
sekigun
I am reading the AMD manuals and found this instruction:
ADC RAX, imm32 15 id Add sign-extended imm32 to RAX + CF.
However, when I try to compile it in FASM it complains that operand sizes don't match.
I wrote it as ADC RAX, dword 00000000, just like ADC EAX, dword 00000000. How would I have to write the instruction so that it gets translated to 15 00 00 00 00?
BTW, I thought that in long mode any operation on 32-bits operators would sign extend the 64-bits register, so that ADC EAX, imm32 is in fact the same instruction. Is that the reason for it not being included in ASM as a different opcode?
Post 23 Jul 2007, 14:17
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
Suppose that RAX is $FFFFFFFF and CF is 1. With ADC RAX, 0 the result is RAX = $100000000, and with ADC EAX, 0 the result is RAX = 0. I think the operations are ZERO extended.

About the problem with "dword" possibly is a fasm bug.
Post 23 Jul 2007, 14:47
View user's profile Send private message Reply with quote
sekigun



Joined: 23 Dec 2004
Posts: 18
Location: Japan
sekigun
I'll try downloading the latest version. (1.67.21) Same error...


Last edited by sekigun on 23 Jul 2007, 15:10; edited 1 time in total
Post 23 Jul 2007, 15:08
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
I have the latest and has de same problem but download the latest anyway because is pointless having older buggy (more) versions Very Happy

[edit] BTW, more than a bug perhaps it is a syntax problem. The problem is that you are requesting a dword operand to be added to a qword operand and that is dissallowed. For example you can't do "adc eax, byte 0" even tough the encoding exists (and fortunately it is the default anyway). You can do "lea eax, [byte ebx + 0]", only "lea eax, [dword ebx + 0]" and so on. I can't remember why Tomasz decided it to be this way but what I can remember is that the forum members didn't agree much Laughing[/edit]


Last edited by LocoDelAssembly on 23 Jul 2007, 15:17; edited 2 times in total
Post 23 Jul 2007, 15:10
View user's profile Send private message Reply with quote
Niels



Joined: 17 Sep 2006
Posts: 255
Niels
I haven't been ASM'ing for quite a while... but doesn't need RAX a qword?
Post 23 Jul 2007, 15:12
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
I edited my post. And no, you can't use a qword because it is not encodable with that instruction (fasm prompt error if you attempt to use qword).
Post 23 Jul 2007, 15:19
View user's profile Send private message Reply with quote
Niels



Joined: 17 Sep 2006
Posts: 255
Niels
I don't know if the encoding is available but an add with carry seems a logic option to me, even on two 64-bit bitstrings.
Post 23 Jul 2007, 15:24
View user's profile Send private message Reply with quote
Niels



Joined: 17 Sep 2006
Posts: 255
Niels
According to the Intel manual:
- opcode: REX.W + 13/l
- instruction: ADC r64, r/m64

Is legal and viable in 64-bit mode. (, not in 64/32-bit compatible mode btw...)

Niels
Post 23 Jul 2007, 15:43
View user's profile Send private message Reply with quote
Niels



Joined: 17 Sep 2006
Posts: 255
Niels
So, if a register or memory is used and not an immediate, the problem should be fixed...


Niels

[EDIT]
Sekigun, it is true, that a 32-bit ADC using an immediate does exists...
Post 23 Jul 2007, 15:44
View user's profile Send private message Reply with quote
Niels



Joined: 17 Sep 2006
Posts: 255
Niels
I see also that an ADC 64-bit, 32-bit version is available:
- opcode: REX.W 81 /2 id
- instruction: ADC r/m64, imm32

Niels

ps.
So, bug Thomasz Smile
Post 23 Jul 2007, 15:54
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
Niels: no, 64bit mode is still 3/4 32bit, to save space of instruction. "mov r, imm64" is only instruction that can take 64bit immediate directly
Post 23 Jul 2007, 16:04
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Quote:

ps.
So, bug Thomasz

No, it is a syntax problem, you can't do "cmp eax, byte 0" for example. Note that fasm will assemble "cmp eax, 0" with the byte form but any attempt to do it explicitly triggers the "Error: operand sized do not match.". You can do "cmp al, byte 0" and it is allowed in this case because the destination operand is a byte register. Also happens with memory, "cmp dword [eax], byte 0" does not work (but if you remove "byte" fasm will use the short encoding anyway), and "cmp byte [eax], byte 0" works.

Either, the syntax must be changed to allow this or extended to allow the enforcing of operand size (for example for things like [byte ebx+0] that you can't do and removing "byte" fasm encodes the shortest encoding which is "[ebx]" that is even shorter than "[ebx+imm8]" and that may be undesirable in some situations).
Post 23 Jul 2007, 16:11
View user's profile Send private message Reply with quote
Niels



Joined: 17 Sep 2006
Posts: 255
Niels
vid wrote:
Niels: no, 64bit mode is still 3/4 32bit, to save space of instruction. "mov r, imm64" is only instruction that can take 64bit immediate directly


I am aware of the (still) partly hybrid context of the 'full' 64-bit mode...

Is what you are saying, that I have an old Intel manual?
Cause I don't see an ADC version with an immediate64...

Niels

[EDIT]
vid: @ff


Last edited by Niels on 23 Jul 2007, 16:37; edited 1 time in total
Post 23 Jul 2007, 16:21
View user's profile Send private message Reply with quote
Niels



Joined: 17 Sep 2006
Posts: 255
Niels
First things first, I see Tomasz as asm-wizard, so there is some honour in 'spotting' a bug... Smile

LocoDelAssembly wrote:

No, it is a syntax problem, you can't do "cmp eax, byte 0" for example.


This was the reason for my first reply(this.thread).

Niels

ps.
According to me, I gave the right answer (with functional arguments) Smile Smile Smile
Post 23 Jul 2007, 16:25
View user's profile Send private message Reply with quote
Niels



Joined: 17 Sep 2006
Posts: 255
Niels
vid,

I see your reference is MOV as where I read (subject)ADC...

Two points for vid, oleh Smile

Niels
Post 23 Jul 2007, 16:29
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
Here it is the discussion about using immediate size operands that don't match with destination operand http://board.flatassembler.net/topic.php?p=33043#33043
Post 23 Jul 2007, 16:55
View user's profile Send private message Reply with quote
Niels



Joined: 17 Sep 2006
Posts: 255
Niels
LocoDelAssembly wrote:
Here it is the discussion about using immediate size operands that don't match with destination operand http://board.flatassembler.net/topic.php?p=33043#33043


Isn't that a weird discussion, since immediates should always be the same size as the destination operand? This, against the few (listed, known, documented) exceptions.

Niels
Post 23 Jul 2007, 17:13
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
Sure, but the ENCODING is not required to be always the same size as the destination operand. A great proof is x86-64 where almost no instruction can have a 64-bit inmediate but still can use a 64-bit destination operand.

For example in "[dword EBX+0]" fasm encodes the zero as an imm32 instead of supressing it, but when you use [EBX+0] fasm applies optimization and removes the immediate. To allow it you could use [byte EBX+0] so fasm would assemble a signed 8-bit immediate, but since such operator is not allowed you can't. According to what I read on that thread, older versions of fasm supported it but Tomasz decided to remove such flexibility.

As vid, I don't understand the decision neither and the Tomasz's example of "var dw ? / cmp [var],al" has not much sense to me because a register is a different thing that does not accept size specification as constants do.
Post 23 Jul 2007, 17:37
View user's profile Send private message Reply with quote
Niels



Joined: 17 Sep 2006
Posts: 255
Niels
LocoDelAssembly wrote:
Sure, but the ENCODING is not required to be always the same size as the destination operand.


Ok, now I know what (faster processor logic) you mean.

LocoDelAssembly wrote:
A great proof is x86-64 where almost no instruction can have a 64-bit inmediate but still can use a 64-bit destination operand.


One might wonder why that is... since an immediate is resident in memory 'while playing', so the handler should be there if a m64 is accepted. (Security, segments, etc, etc, will probably be the reason...change, change, change)

LocoDelAssembly wrote:
According to what I read on that thread, older versions of fasm supported it but Tomasz decided to remove such flexibility.


So, the manual part is still applicable but the fasm-auto-optimalisation is removed... I think 'Intel' implemented it for (cycle)speed-reasons, so it could be a deal to persued Tomasz. Smile

LocoDelAssembly wrote:

As vid, I don't understand the decision neither and the Tomasz's example of "var dw ? / cmp [var],al" has not much sense to me because a register is a different thing that does not accept size specification as constants do.


I am not a fasm-preprocessor-wizard but he seems to explain/provide the (same?) optimalisation in preprocessor-form...?

Niels
Post 23 Jul 2007, 17:49
View user's profile Send private message Reply with quote
Niels



Joined: 17 Sep 2006
Posts: 255
Niels
I think Tomasz did:

CMP CpuCycleTimeGain, TomaszCycleTimeGain

I guess Tomasz let Tomasz win... Smile


Niels
Post 23 Jul 2007, 18:03
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

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

Powered by rwasa.