flat assembler
Message board for the users of flat assembler.

flat assembler > Main > Why this operation is not possible ?

Goto page Previous  1, 2, 3, 4, 5, 6  Next
Author
Thread Post new topic Reply to topic
system error



Joined: 01 Sep 2013
Posts: 671
revolution wrote:
The_Unknown_Member: If you need to add bx to eax you can manually extend it and then add:
Code:
movzx ecx,bx ;zero extend to full 32 bits.
add eax,ecx

;or

movsx ecx,bx ;sign extend to 32 bits
add eax,ecx    
So you have to "know" if the number stored in bx is signed or unsigned so that you can use the proper extend function to convert it to a full 32-bit value, and then add it to eax.

As for "why" you can't do it with one instruction, the reason is as Furs stated, there is no encoding for it. In theory Intel/AMD could create new instructions "addzx r32,r16" and "addsx r32,r16", but there would be little call for it, and they would mostly go unused, so it is unlikely that we will ever see such instructions.


1. Rule 1 and Rule 2 are never broken. There are only few exceptions. Like

MOV EAX,CS

2. PUSH/POP are single operands instructions. It obliges to what rules?

3. "no encoding for it" is because Intel/AMD sets that to be a standard rule. In other ways, Intel/AMD doesn't not provide such encodings in order to observe that rule. That rule is called "operands must be of the same size". Assembly language translates it as syntax error because it is a language.

Why do you think Tomasz uses "Error: Operand sizes are not equal" instead of "Error: No encoding for this"? Hmm???? hmmmmm????
Post 30 Aug 2017, 03:13
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1430
Tomasz can write whatever he wants. In this case, he wanted to show a more descriptive error message so the programmer knows what to fix. "Invalid encoding" is not helpful error message, you'll have to look at Intel Manuals to see why that is so (by itself). But the error message doesn't answer why it's invalid.

More "rule breakers":
Code:
movd eax, mm0   ; 64 bit operand to 32 bit operand
movd eax, xmm0  ; 128 bit operand to 32 bit operand    
And no, they didn't do it to preserve that rule. They did it to preserve opcode space as I said on first post. There's only a limited amount of "opcodes" (i.e. identifications) you can fit in one byte or a couple bytes.

movzx/movsx already take two bytes just for the opcode (no operands) because they couldn't fit it into one byte -- all the opcode space was taken by other insns they added before. Where would they add "add eax, bx" then?

AMD even removed some less-used 1-byte opcodes in x64 or re-purposed them (I'm NOT talking about REX prefix, but about arpl->movsx 64 mode), so yes, don't give me bullshit like they don't care about it.
Post 30 Aug 2017, 10:33
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16778
Location: In your JS exploiting you and your system
system error wrote:
1. Rule 1 and Rule 2 are never broken. There are only few exceptions.
Those two sentences do not agree with each other.
Post 30 Aug 2017, 10:43
View user's profile Send private message Visit poster's website Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
Furs wrote:
Tomasz can write whatever he wants. In this case, he wanted to show a more descriptive error message


Any error message should reflect the nature of the syntax being violated. That rule being violated is "Operands are not of the same size".


Quote:
More "rule breakers":
Code:
movd eax, mm0   ; 64 bit operand to 32 bit operand
movd eax, xmm0  ; 128 bit operand to 32 bit operand    
And no, they didn't do it to preserve that rule. They did it to preserve opcode space as I said on first post. There's only a limited amount of "opcodes" (i.e. identifications) you can fit in one byte or a couple bytes.


I don't see no rule-breaker there.

MOVD itself defines the transfer rule. It's a DWORD transfer. And FASM is smart enough to pick up a DWORD from the source because you can't DIVIDE A MM0 or an XMM register like you do with variables by using a size override.

I don't know where you learned assembly language but you do need a serious education on this or else you'll keep on misleading people under the pretense of an "master of everything".
Post 30 Aug 2017, 10:53
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
revolution wrote:
system error wrote:
1. Rule 1 and Rule 2 are never broken. There are only few exceptions.
Those two sentences do not agree with each other.


Maybe my quantifier "never" is incorrect. But that doesn't mean Tomasz is wrong when he uses "Error: Operands sizes not equal". He got that one right because he knows the Rule very well. You don't?
Post 30 Aug 2017, 10:56
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1430
system error wrote:
Any error message should reflect the nature of the syntax being violated. That rule being violated is "Operands are not of the same size".
Every assembler has a different syntax. Syntax means nothing. AT&T asm is completely different. Heck even MASM has a different syntax. (dword ptr and stuff)

You can even assemble raw bytes with db. Syntax means nothing. You won't be able to make a "add eax, bx" instruction with db because it doesn't exist. You can make "add eax, ebx" though.

system error wrote:
I don't see no rule-breaker there.

MOVD itself defines the transfer rule. It's a DWORD transfer. And FASM is smart enough to pick up a DWORD from the source because you can't DIVIDE A MM0 or an XMM register like you do with variables by using a size override.
What?

Size override happens only with 32-bit -> 16-bit operand, because they have the same opcode. 8-bit has no size override because it has a totally separate opcode. I know you'll say I speak nonsense, but you brought size override up which makes *zero* sense. Of course movd defines the transfer rule, every instruction defines the transfer rule in Intel Manuals. Every one of them. There is no implied "golden rule".

Another rule-breaker:
Code:
add rax, imm32  ; 12345678901234 gives error sorry    
Yeah, you get error trying to add an immediate larger than 32-bit. It does say imm32 in Intel Manuals. mov on the other hand works:
Code:
mov rax, 12345678901234    
Why? Because mov has an opcode for 64-bit immediate.
Post 30 Aug 2017, 11:12
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16778
Location: In your JS exploiting you and your system
system error wrote:
Maybe my quantifier "never" is incorrect.
Definitely. But it goes one step further than that: There has been no such rule stated by Intel or AMD.
system error wrote:
But that doesn't mean Tomasz is wrong when he uses "Error: Operands sizes not equal". He got that one right because he knows the Rule very well. You don't?
I know of no such rule. I've never before seen such a rule stated until I read this thread. And I see no evidence that such a rule needs to exist. CPU makers can decide to make encodings for many different things if they wish to. But there comes a point of practicality and usefulness that dominates the final decisions about what to include and what to exclude. Did you know that ARM have defined vector instructions that do exactly what the OP is asking for (saddw and uaddw)? ARM must have thought there was enough of a use case that including them was worthwhile.
Post 30 Aug 2017, 11:18
View user's profile Send private message Visit poster's website Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
Furs wrote:
Every assembler has a different syntax. Syntax means nothing. AT&T asm is completely different. Heck even MASM has a different syntax. (dword ptr and stuff)


Syntax means everything in a Programming Language. OMG!! Syntax means nothing?? You can't produce executable without the correct syntax!! IDIOT!! Hahahaha xD


Quote:
Of course movd defines the transfer rule

Yes. Now you finally understand it. That quick huh? xD

Quote:
Another rule-breaker:
Code:
add rax, imm32  ; 12345678901234 gives error sorry    
Yeah, you get error trying to add an immediate larger than 32-bit. It does say imm32 in Intel Manuals. mov on the other hand works:
Code:
mov rax, 12345678901234    


Here we are assuming 32-bit CPU as suggested by the original post from OP. 64-bit code requires a slightly different topic. Don't play your extended "master of everything" garbage with me because you know how it always ends. hahahaha xD
Post 30 Aug 2017, 11:24
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
revolution wrote:
system error wrote:
Maybe my quantifier "never" is incorrect.
Definitely. But it goes one step further than that: There has been no such rule stated by Intel or AMD.
system error wrote:
But that doesn't mean Tomasz is wrong when he uses "Error: Operands sizes not equal". He got that one right because he knows the Rule very well. You don't?
I know of no such rule. I've never before seen such a rule stated until I read this thread. And I see no evidence that such a rule needs to exist. CPU makers can decide to make encodings for many different things if they wish to. But there comes a point of practicality and usefulness that dominates the final decisions about what to include and what to exclude. Did you know that ARM have defined vector instructions that do exactly what the OP is asking for (saddw and uaddw)? ARM must have thought there was enough of a use case that including them was worthwhile.


There's always a set of rules to define the characteristics of x86 intel instruction set architecture. Without these set of rules, you can't call it an architecture and all hell will break loose. You can't build an assembler on top of it if you can't oblige to these rules or if a set of rules are not defined.

OMG! You too! hahahaha xD
Post 30 Aug 2017, 11:30
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16778
Location: In your JS exploiting you and your system
system error wrote:
There's always a set of rules to define the characteristics of x86 intel instruction set architecture.
Where? Link please. I'd be happy to learn.
Post 30 Aug 2017, 11:39
View user's profile Send private message Visit poster's website Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
revolution wrote:
system error wrote:
There's always a set of rules to define the characteristics of x86 intel instruction set architecture.
Where? Link please. I'd be happy to learn.
The rules are scattered all over the manuals. It's your own initiative to find what the rules are.

Rule 4. Little Endian
Rule 5. Left Side operand is the Destination. Right side Operand is the Source.
Rule 6. Byte-addressable addressing

Now don't tell me that these rules and defining characteristics don't exist in X86 ISA or that you don't know they exist. Because I will be extremely dissappointed by the level of basic knowledge on this board ... Surprised
Post 30 Aug 2017, 11:53
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16778
Location: In your JS exploiting you and your system
Hmm, all of those additional rules are also broken.

4. BSWAP, there is no clear endian for this.
5. POP, no destination is given.
6. Many of the vector loads and stores have alignment restrictions.

Plus your claim of the rules being in the manuals is false. No such rules are stated by either Intel or AMD (but you are welcome and encouraged to point out the page number or paragraph number to show my error).

Unless you consider general characteristics are "rules"? If so then I think your claim is misleading at best.
Post 30 Aug 2017, 12:04
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1430
@system error: You might want to check out the movbe instruction then.
Post 30 Aug 2017, 12:04
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
revolution wrote:
Hmm, all of those additional rules are also broken.

4. BSWAP, there is no clear endian for this.
5. POP, no destination is given.
6. Many of the vector loads and stores have alignment restrictions.

Plus your claim of the rules being in the manuals is false. No such rules are stated by either Intel or AMD (but you are welcome and encouraged to point out the page number or paragraph number to show my error).

Unless you consider general characteristics are "rules"? If so then I think your claim is misleading at best.


4. BSWAP is used to emulate a BIG-ENDIAN machine. I don't see no problem with that.
5. Of course, it's a single operand instruction. Two-operands RULES don't apply. What is your problem?
6. And what's your point with vectored instructions?? The rules on their usage is in the manuals.


Quote:
Plus your claim of the rules being in the manuals is false. No such rules are stated by either Intel or AMD (but you are welcome and encouraged to point out the page number or paragraph number to show my error


So it is allowed then for a programmer to think that left side operand is the SOURCE and the right operand is the DESTINATION? So the rule of MOV in FASM is now;


MOV <source>, <destination>

It's never explicitly stated in the manual either. Do you agree with this new rule??
Post 30 Aug 2017, 12:15
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
Furs wrote:
@system error: You might want to check out the movbe instruction then.


You mean like,

movbe <source>, <destination> ??

or

movbe <destination>, <source> ??

I checked MOVBE instruction entry and I don't see no rules on source/operand on it. So according to revolution, since there's no rule explicitly stated in the manual, both versions are semantically correct.
Post 30 Aug 2017, 12:20
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16778
Location: In your JS exploiting you and your system
Presenting strawman arguments doesn't make your case. I pointed out that POP doesn't have an explicit destination ([--esp]), you then say (paraphrasing) "rule doesn't apply to POP". But POP does have a destination, it's just that it isn't stated using the normal methods, and thus breaks your "rule". You said "Left Side operand is the Destination" but POP fails to accept [--esp] as the destination, it is implied.

You can't claim rules and then go on to say "oh but there are exceptions" because that makes it not-a-rule-at-all. If you want to say they are general characteristics then I have no argument against that.
Post 30 Aug 2017, 12:26
View user's profile Send private message Visit poster's website Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
revolution wrote:
Presenting strawman arguments doesn't make your case. I pointed out that POP doesn't have an explicit destination ([--esp]), you then say (paraphrasing) "rule doesn't apply to POP". But POP does have a destination, it's just that it isn't stated using the normal methods, and thus breaks your "rule". You said "Left Side operand is the Destination" but POP fails to accept [--esp] as the destination, it is implied.

You can't claim rules and then go on to say "oh but there are exceptions" because that makes it not-a-rule-at-all. If you want to say they are general characteristics then I have no argument against that.


Push <operand>
Pop <operand>

When does the POP 's operand have in contact with a source operand? I am eager to know.

"Error: Operand sizes are not equal"

The OP's original post is about two operands instruction. Not a POP or a PUSH. They are no two-operands instructions.
Post 30 Aug 2017, 12:33
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7354
Location: Kraków, Poland
revolution wrote:
Hmm, all of those additional rules are also broken.

4. BSWAP, there is no clear endian for this.
5. POP, no destination is given.
6. Many of the vector loads and stores have alignment restrictions.

Plus your claim of the rules being in the manuals is false. No such rules are stated by either Intel or AMD (but you are welcome and encouraged to point out the page number or paragraph number to show my error).

Unless you consider general characteristics are "rules"? If so then I think your claim is misleading at best.
While such postmodern approach may be technically correct, I wouldn't consider it a good approach when teaching beginners. In many areas of expertise it is usual to at first learn some basic rules that later may turn out to be too simplistic or incomplete. But to appreciate the knowledge of exceptions one needs to be a bit advanced it the topic, while simple rules and generalizations help shape the learning curve.

And arguing whether to call the simple rules a "general characteristics" is a hair-splitting, in my opinion. Both can mean the same, we need to at least consider that we may not always be on the same page in understanding some phrases.

Furs wrote:
Another rule-breaker:
Code:
add rax, imm32  ; 12345678901234 gives error sorry    
Yeah, you get error trying to add an immediate larger than 32-bit. It does say imm32 in Intel Manuals. mov on the other hand works:
Code:
mov rax, 12345678901234    
Why? Because mov has an opcode for 64-bit immediate.
One thing of note here: in the development of fasm I paid attention to the distinction between the assembly language and machine code. I see the first one as an abstraction layer over the actual instruction code (which is quite obvious if you consider the fact that often the identical operation can be encoded in many different ways) which focuses on what the instruction does instead of how is it encoded. For this reason "add rax,0FFFFFFFFFFFF0000h" is a valid instruction in fasm and "add rax,0FFFF0000h" is not - becase the former is exactly what the instruction performs, even if the latter is more like what the encoding looks like.
Post 30 Aug 2017, 12:41
View user's profile Send private message Visit poster's website Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
revolution wrote:
You can't claim rules and then go on to say "oh but there are exceptions" because that makes it not-a-rule-at-all. If you want to say they are general characteristics then I have no argument against that.


There are always exceptions to rules. You have a logical fallacy there. Just because there are exceptions, that doesn't mean there are no rules.

x86 architecture will lose it's identity and characteristics if there are no rules defining and enforcing it as one.

FASM1 is an example where all of those rules are observed, enforced and preserved. FASMG is a good example where you can define your own set of rules not bound to x86 architecture rules.

Now it's up to you to tell the beginners that

MOV <source>, <destination>

is also correct in FASM. The rule is never defined in the Manual anyway.


Well, GOOD LUCK!! Hahahaha xD
Post 30 Aug 2017, 12:41
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
Big boss is coming. I am out of here. ;p
Post 30 Aug 2017, 12:43
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, 3, 4, 5, 6  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-2019, Tomasz Grysztar.

Powered by rwasa.