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.

movd eax, mm0   ; 64 bit operand to 32 bit operand
movd eax, xmm0  ; 128 bit operand to 32 bit operand    

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

Tomasz can write whatever he wants. In this case, he wanted to show a more descriptive error message

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.

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.

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

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.

add rax, imm32  ; 12345678901234 gives error sorry    

mov rax, 12345678901234    

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?

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)

Of course movd defines the transfer 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    

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.

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.

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.

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

@system error: You might want to check out the movbe instruction then.

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.

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.

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.

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.