Why this operation is not possible ?

Index > Main > Why this operation is not possible ?

Goto page Previous 1, 2, 3, 4, 5, 6 Next

Author

Thread

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20451
Location: In your JS exploiting you and your system

revolution 01 Sep 2017, 15:12

Thanks for the clarification. But ...

system error wrote:

I also explained that...

Quote:
In other [words], Intel/AMD doesn't not provide such encodings in order to observe / preserve that rule and characteristics

I disagree with this part. I think the reason for currently not having any encoding to support different registers sizes is simply because they see no great need for it, i.e. there are (in their opinion) more useful instructions to add to the instruction set.

01 Sep 2017, 15:12

system error

Joined: 01 Sep 2013
Posts: 670

system error 01 Sep 2017, 15:33

Maybe, maybe not.

Balanced operands as the main characteristics of X86 architecture, is not going anywhere anytime soon or else it will never retain its identity and characteristics as an x86 "architecture" Not to mention backward compatibility issues if imbalance operands are to be allowed.

There are not much "reserved" states left in Mod, R/M, Reg fields to accommodate wild operand sizes.

01 Sep 2017, 15:33

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20451
Location: In your JS exploiting you and your system

revolution 01 Sep 2017, 15:36

system error wrote:

There are not much "reserved" states left in Mod, R/M, Reg fields to accommodate wild operand sizes.

Well, yes and no. SIB was successfully implemented within it. Plus movzx and movsx exist so it wouldn't be impossible, if the desire was there.

01 Sep 2017, 15:36

Furs

Joined: 04 Mar 2016
Posts: 2565

Furs 01 Sep 2017, 17:36

You don't have to fiddle with Mod R/M at all. Mod R/M doesn't specify size of operands, only which regs. The opcode does. So they could have added opcodes for add r32, r16 if they wanted to, just like they have separate opcodes for add r32, r32 and add r8, r8.

There's no "important characteristic" to preserve, since AMD64 also zeroes the 64-bit register for any 32-bit operation (which is "against the" common characteristic for other reg sizes), effectively turning it into a "64-bit register with zero extension from 32-bit", which is not much different than say, an "add r32, r16" zero-extending the r16 before performing the addition, except it's the other way around.

AMD obviously did it to get rid of dependency chains. The point is: their decisions are arbitrary and what is needed at the time. They don't give a shit about respecting rules if it's underperforming, only utility.

01 Sep 2017, 17:36

system error

Joined: 01 Sep 2013
Posts: 670

system error 01 Sep 2017, 18:54

Furs wrote:

You don't have to fiddle with Mod R/M at all. Mod R/M doesn't specify size of operands, only which regs. The opcode does. So they could have added opcodes for add r32, r16 if they wanted to, just like they have separate opcodes for add r32, r32 and add r8, r8.

There's no "important characteristic" to preserve, since AMD64 also zeroes the 64-bit register for any 32-bit operation (which is "against the" common characteristic for other reg sizes), effectively turning it into a "64-bit register with zero extension from 32-bit", which is not much different than say, an "add r32, r16" zero-extending the r16 before performing the addition, except it's the other way around.

AMD obviously did it to get rid of dependency chains. The point is: their decisions are arbitrary and what is needed at the time. They don't give a shit about respecting rules if it's underperforming, only utility.

Ok Furs, from your "talks", I am convinced that you are a master of assembler. But this one right here is my favorite;

Quote:

He's asking why the operation cannot be done. Operation is executed at runtime by the CPU and has nothing to do with the assembler.

Care to explain how "ADD EAX,BX" managed to get passed the compilation process and jump straight to become a "runtime" executable?

Please extend your "expert-like talks" below and entertain us xD

01 Sep 2017, 18:54

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20451
Location: In your JS exploiting you and your system

revolution 01 Sep 2017, 19:01

system error: The assembler follows what the CPU is capable of. So you are blocked by the assembler because the CPU can't do it. That is the root cause for the reason. So the answer to "why can't it be done?" is "because the CPU has no encoding for it, and the assembler merely follows the CPU for what it allows and what it errors on."

01 Sep 2017, 19:01

system error

Joined: 01 Sep 2013
Posts: 670

system error 01 Sep 2017, 19:04

revolution wrote:

system error wrote:
There are not much "reserved" states left in Mod, R/M, Reg fields to accommodate wild operand sizes.
Well, yes and no. SIB was successfully implemented within it. Plus movzx and movsx exist so it wouldn't be impossible, if the desire was there.

Sound like you're not sure yourself. Look,

Code:

cmp eax,dl       ;what semantics are you implying here? SIGN, ZERO, OVERFLOW, EQUALITY?
... in other case
xchg eex, bx    ;lost of information?

Are you sure that Intel has that "desire"?

01 Sep 2017, 19:04

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20451
Location: In your JS exploiting you and your system

revolution 01 Sep 2017, 19:07

system error wrote:

Look,

Code:

cmp eax,dl       ;what semantics are you implying here? SIGN, ZERO, OVERFLOW, EQUALITY?
... in other case
xchg eex, bx    ;lost of information?

Are you sure that Intel has that "desire"?

We were not discussing CMP or XCHG. We were discussing ADD. And to really know Intel's desire you would need to ask Intel.

01 Sep 2017, 19:07

system error

Joined: 01 Sep 2013
Posts: 670

system error 01 Sep 2017, 19:11

revolution wrote:

system error: The assembler follows what the CPU is capable of. So you are blocked by the assembler because the CPU can't do it. That is the root cause for the reason. So the answer to "why can't it be done?" is "because the CPU has no encoding for it, and the assembler merely follows the CPU for what it allows and what it errors on."

And what error message emitted by the assmbler while blocking it?

"Error: The CPU can't do it"? ===> MASM
"Error: No encoding for this"? ====> NASM
"Error: Nope. Sorry"? ===> FASM

Why the three different assemblers complain something about "operand size" instead of the above? Extreme co-incidence? Conspiracy? Magic? Or these authors know something that we don't when making that similar conclusion?

See, I have to repeat myself TWICE xD

01 Sep 2017, 19:11

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20451
Location: In your JS exploiting you and your system

revolution 01 Sep 2017, 19:16

The error messages are arbitrary. Is this the source of your argument, that the error message is the final word on the CPU instruction set design principles?

01 Sep 2017, 19:16

system error

Joined: 01 Sep 2013
Posts: 670

system error 01 Sep 2017, 19:17

revolution wrote:

system error wrote:
Look,
Code:
cmp eax,dl       ;what semantics are you implying here? SIGN, ZERO, OVERFLOW, EQUALITY?
... in other case
xchg eex, bx    ;lost of information?    
Are you sure that Intel has that "desire"?
We were not discussing CMP or XCHG. We were discussing ADD. And to really know Intel's desire you would need to ask Intel.

If the rules "operands sizes must be equal" is to be broken, why limit it to just ADD?

Now you're getting the idea why the rule must be preserved. xD

01 Sep 2017, 19:17

system error

Joined: 01 Sep 2013
Posts: 670

system error 01 Sep 2017, 19:24

revolution wrote:

The error messages are arbitrary. Is this the source of your argument, that the error message is the final word on the CPU instruction set design principles?

Yawnnnnn... I am sending my keyboard to continue the discussion with you. A dumb device vs a senior coder. I'll come back for the result tomorrow. hhehehe xD

01 Sep 2017, 19:24

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20451
Location: In your JS exploiting you and your system

revolution 01 Sep 2017, 19:25

It might work for ADD, and perhaps SUB, maybe even DIV, MUL, CMP, AND, OR, TEST, etc. But a good reason to limit it to only certain instructions is because you'd only implement where it actually makes sense.

01 Sep 2017, 19:25

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20451
Location: In your JS exploiting you and your system

revolution 01 Sep 2017, 19:27

system error wrote:

Yawnnnnn... I am sending my keyboard to continue the discussion with you. A dumb device vs a senior coder. I'll come back for the result tomorrow. hhehehe xD

Do you have an argument to present? I ask because right now you are badgering people instead of actually discussing.

01 Sep 2017, 19:27

Furs

Joined: 04 Mar 2016
Posts: 2565

Furs 01 Sep 2017, 20:01

system error wrote:

Care to explain how "ADD EAX,BX" managed to get passed the compilation process and jump straight to become a "runtime" executable?

The same way they did it before the first assembler even existed. Instruction opcodes and mnemonics exist before any assembler and are totally independent of *any* assembler.

Just as the C/C++ language is completely independent of *any* compiler. The language exists even if there's no compiler for it -- because the language is just a specification. (obviously the CPU uses opcodes and associated mnemonics for its "language")

Each assembler has a different syntax, more or less. In fact, FASMG doesn't even implement any instruction set. So yeah, the instructions are just macros that result in opcodes (and you can freely add your own in there). So why can't you add a "add eax, bx" instruction in FASMG then? It's just a macro after all.

Oh right. No opcode. Sorry. Wink

01 Sep 2017, 20:01

system error

Joined: 01 Sep 2013
Posts: 670

system error 02 Sep 2017, 05:18

Furs wrote:

system error wrote:
Care to explain how "ADD EAX,BX" managed to get passed the compilation process and jump straight to become a "runtime" executable?
The same way they did it before the first assembler even existed. Instruction opcodes and mnemonics exist before any assembler and are totally independent of *any* assembler.

-- snipped "expert" garbage about c++ --
-- snip "expert" garbage about FASMG---

Oh right. No opcode. Sorry.

No, I don't want to hear about "the same way" expert garbage. Just tell me how is one beginner's ("ADD EAX,BX") supposed to pass the compilation phase SYNTAX RULES and producing a "runtime" executable directly?

Again, I am having this feeling that you're trying to suggest the use of a Hex Editor. I think I have posted the right link for you in this thread. So my suspicion is true then!

hahahaha xD

02 Sep 2017, 05:18

system error

Joined: 01 Sep 2013
Posts: 670

system error 02 Sep 2017, 05:37

revolution wrote:

It might work for ADD, and perhaps SUB, maybe even DIV, MUL, CMP, AND, OR, TEST, etc. But a good reason to limit it to only certain instructions is because you'd only implement where it actually makes sense.

So why is it not making sense back and not making sense now? Because it is an architecture with high-level of consistency in maintaining its characteristics and enforcing the same rules across its products over a long period of time.

Never because they don't want to do it and "not finding good use of it". No. It's all about maintaining the same behavior, preserving the characteristics and enforcing the same rules over and over - hence an architecture. It's little-endian. byte addressable, variable-length, balanced-operands types of architecture. The rules are enforced by the assemblers so that it will stay that way. So trust your assembler! Very Happy

02 Sep 2017, 05:37

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20451
Location: In your JS exploiting you and your system

revolution 02 Sep 2017, 05:43

system error wrote:

The instructions are enforced by the assemblers so that it will stay that way.

I changed one word in your quote to fix your statement. Wink

system error wrote:

So trust your assembler!

Unless it uses the AT&T syntax and accepts any register mixed with any other register, but still assembles without an error.

02 Sep 2017, 05:43

Furs

Joined: 04 Mar 2016
Posts: 2565

Furs 02 Sep 2017, 14:43

system error wrote:

No, I don't want to hear about "the same way" expert garbage. Just tell me how is one beginner's ("ADD EAX,BX") supposed to pass the compilation phase SYNTAX RULES and producing a "runtime" executable directly?

Read the title of the thread again. Nobody asked why it doesn't compile/assemble. Only in your imagination was such question posed.

I don't know what else can I say, I've said it 3-4 times already. You're too ignorant or fail horribly at english to understand I guess.

Also FASMG has no built-in instructions AFAIK, it's all macros. So your "assembly rules" means nothing, you can change them to whatever you want and have "add eax, bx" compile if you wish -- just not to a sensible operation because it doesn't exist.

02 Sep 2017, 14:43

system error

Joined: 01 Sep 2013
Posts: 670

system error 03 Sep 2017, 07:42

revolution wrote:

system error wrote:
The instructions are enforced by the assemblers so that it will stay that way.
I changed one word in your quote to fix your statement.
system error wrote:
So trust your assembler!
Unless it uses the AT&T syntax and accepts any register mixed with any other register, but still assembles without an error.

"Syntax" is a BIG CONCERN in language rules.
Instructions violation translates to "faults".

The error: "invalid instructions" is syntax error. Not an instruction fault. FASM enforces that syntax rules and will not let it pass the compilation process.

Unless of course, you want to hard-coded it straight via DB or Hex Editor, ignoring FASM syntax rules altogether. Then it is just you, the CPU and the manual. You probably need a calculator too to manually calculate those far and near jumps.

Good luck.

03 Sep 2017, 07:42

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