Index
> Main > Instruction encoding (AMD64)Goto page 1, 2 Next |
| Author |
|
|
LocoDelAssembly 23 Jul 2007, 14:47
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. |
|||
23 Jul 2007, 14:47 |
|
|
sekigun 23 Jul 2007, 15:08
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 |
|||
|
23 Jul 2007, 15:08 |
|
|
LocoDelAssembly 23 Jul 2007, 15:10
I have the latest and has de same problem but download the latest anyway because is pointless having older buggy (more) versions
[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  [/edit]Last edited by LocoDelAssembly on 23 Jul 2007, 15:17; edited 2 times in total |
|||
|
23 Jul 2007, 15:10 |
|
|
Niels 23 Jul 2007, 15:12
I haven't been ASM'ing for quite a while... but doesn't need RAX a qword?
|
|||
|
23 Jul 2007, 15:12 |
|
|
LocoDelAssembly 23 Jul 2007, 15:19
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).
|
|||
|
23 Jul 2007, 15:19 |
|
|
Niels 23 Jul 2007, 15:24
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.
|
|||
|
23 Jul 2007, 15:24 |
|
|
Niels 23 Jul 2007, 15:43
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 |
|||
|
23 Jul 2007, 15:43 |
|
|
Niels 23 Jul 2007, 15:44
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... |
|||
|
23 Jul 2007, 15:44 |
|
|
Niels 23 Jul 2007, 15:54
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  |
|||
|
23 Jul 2007, 15:54 |
|
|
vid 23 Jul 2007, 16:04
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
|
|||
|
23 Jul 2007, 16:04 |
|
|
LocoDelAssembly 23 Jul 2007, 16:11
Quote:
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). |
|||
|
23 Jul 2007, 16:11 |
|
|
Niels 23 Jul 2007, 16:21
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 |
|||
|
23 Jul 2007, 16:21 |
|
|
Niels 23 Jul 2007, 16:25
First things first, I see Tomasz as asm-wizard, so there is some honour in 'spotting' a bug...
LocoDelAssembly wrote:
This was the reason for my first reply(this.thread). Niels ps. According to me, I gave the right answer (with functional arguments) |
|||
|
23 Jul 2007, 16:25 |
|
|
Niels 23 Jul 2007, 16:29
vid,
I see your reference is MOV as where I read (subject)ADC... Two points for vid, oleh
Niels |
|||
|
23 Jul 2007, 16:29 |
|
|
LocoDelAssembly 23 Jul 2007, 16:55
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
|
|||
|
23 Jul 2007, 16:55 |
|
|
Niels 23 Jul 2007, 17:13
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 |
|||
|
23 Jul 2007, 17:13 |
|
|
LocoDelAssembly 23 Jul 2007, 17:37
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. |
|||
|
23 Jul 2007, 17:37 |
|
|
Niels 23 Jul 2007, 17:49
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.
LocoDelAssembly wrote:
I am not a fasm-preprocessor-wizard but he seems to explain/provide the (same?) optimalisation in preprocessor-form...? Niels |
|||
|
23 Jul 2007, 17:49 |
|
|
Niels 23 Jul 2007, 18:03
I think Tomasz did:
CMP CpuCycleTimeGain, TomaszCycleTimeGain I guess Tomasz let Tomasz win...
Niels |
|||
|
23 Jul 2007, 18:03 |
|
| Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|