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
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16699
Location: In your JS exploiting you and your system
system error wrote:
Push <operand>
Pop <operand>

When does the POP 's operand have in contact with a source operand? I am eager to know.
Oops, I guess I meant to say PUSH. But anyhow, both push and pop only state one of the source/destination arguments. The other is implied. Both of them seem to break the "rule".
Post 30 Aug 2017, 12:48
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7310
Location: Kraków, Poland
system error wrote:
The rule is never defined in the Manual anyway.
fasm's documentation directs you to the Intel manual for a more ground-up explanation of everything. And the rule concerning destination and source order is still there. I just consulted my collection of Intel manual revisions and here's how the rules was stated back in 1986:
Intel 80386 Programmer's Reference Manual, section 1.3.3 wrote:
When two operands are present in an instruction that modifies data, the right operand is the source and the left operand is the destination.
And how it looks in the modern one, 30 years later:
Intel® 64 and IA-32 Architectures Software Developer’s Manual, section 1.3.2.1 wrote:
When two operands are present in an arithmetic or logical instruction, the right operand is the source and the left operand is the destination.
Post 30 Aug 2017, 12:51
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16699
Location: In your JS exploiting you and your system
Even Intel break their own rules Sad

It should be more like this: When two operands are present in an arithmetic or logical instruction, the right operand is one of the sources and the left operand is the other source and the destination.
FTFI

But it has no relevance for non-arithmetic or non-logical instructions, which have different "rules". Sad
Post 30 Aug 2017, 13:03
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1424
Tomasz Grysztar wrote:
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.
I'm not talking about syntax. I was pointing out that many more operations have differently-sized operands. i.e. almost all immediates in 64-bit operations are 32-bit. However the syntax is doesn't matter -- you can use macros for it to make up your own anyway (and every assembler is different). So when someone asks, why can't I add a 16-bit number to 32-bit number, that question has nothing to do with syntax.

There is no syntax that can add a 16-bit number to 32-bit in one instruction using an add insn, there simply doesn't exist an encoding for it. Even if you make "add eax, bx" valid with a macro, it won't perform what you expect in one instruction.

Just an example, in AT&T asm you can specify the "size" of the insn with a suffix, even if the registers don't match.

Code:
addl %ax, %cx  ; add 32-bit eax to ecx (reversed operands)
addq %ax, %cx  ; add 64-bit rax to rcx    
In this case, the addl and addq are two different instructions with two different names: one 32-bit, the other 64-bit.

I'm not saying that I like AT&T asm -- simply saying that all assemblers obviously encode the same stuff in the end (same CPUs, same assembly), so syntax doesn't really matter here for validity of an instruction -- the encoding does.
Post 30 Aug 2017, 14:15
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16699
Location: In your JS exploiting you and your system
Furs wrote:
... in AT&T asm you can specify the "size" of the insn with a suffix, even if the registers don't match.
OMG, I didn't know that. Such a bad syntax made worse.
Post 30 Aug 2017, 14:25
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7310
Location: Kraków, Poland
Furs wrote:
I'm not saying that I like AT&T asm -- simply saying that all assemblers obviously encode the same stuff in the end (same CPUs, same assembly), so syntax doesn't really matter here for validity of an instruction -- the encoding does.
Again we have two layers here - the validity of a machine instruction (whether such operation is possible to encode and execute at all) and the validity of a language construction in the assembly language, which is also usually called instruction (though, strictly speaking, it is a separate entity). Obviously the latter has all to do with syntax, what is legal in one assembler may not be legal in another. Assembler may even implement some instructions or variants that do not exist in machine language, but may be translated to another instruction that performs the required operation. "IMUL reg,imm" is an example - Intel defines no such machine instruction, but assemblers usually allow it and translate it to "IMUL reg,reg,imm".
Post 30 Aug 2017, 15:41
View user's profile Send private message Visit poster's website Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
Quote:
I'm not talking about syntax. I was pointing out that many more operations have differently-sized operands.


That brings us to Rule 7

Rule 7 - x86 is a variable-length instruction machin

I bet you didn't know about this either.

Quote:
you can use macros for it to make up your own anyway (and every assembler is different).


I haven't seen you creating any macro so far. All talk and empty impressions.

Quote:
So when someone asks, why can't I add a 16-bit number to 32-bit number, that question has nothing to do with syntax.


The syntax is enforced by the assembler. You failed to separate the concepts of machine binaries and a programming language / compiler. The implementation of machine binaries is carried out by the assembler because Intel doesn't offer any assembler. They only offer definitions and specifications. Don't you get it?

The error message: "Error: Operand sizes are not equal" comes from the assembler. Not from the CPU. So in this case, it is the assembler that enforces that rule. And since the assembler is a programming language, it enforces the rules through its SYNTAX RULES.

Quote:
There is no syntax that can add a 16-bit number to 32-bit in one instruction using an add insn,


There is. "add eax,127" (literally means add a 16-bit number to a 32-bit register)

Here you need the assembler to implicitly force the immediate to become a dword so the rule: operands must be of equal size can be enforced. If you used the WRONG SYNTAX like

"add eax, byte 127"

the assembler will throw in your face the SYNTAX ERROR MESSAGE due to imbalance operands. See, the syntax does matter, because you are using a PROGRAMMING LANGUAGE.

Quote:
Just an example, in AT&T asm you can specify the "size" of the insn with a suffix, even if the registers don't match.


AT&T syntax is not defined in the OFFICIAL MANUFACTURERS MANUAL. Don't over-extend your garbage to something that you do not understand.
Post 31 Aug 2017, 04:25
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
revolution wrote:
system error wrote:
Push <operand>
Pop <operand>

When does the POP 's operand have in contact with a source operand? I am eager to know.
Oops, I guess I meant to say PUSH. But anyhow, both push and pop only state one of the source/destination arguments. The other is implied. Both of them seem to break the "rule".


I think I have already mentioned it twice that PUSH/POP are single-operand instructions and has nothing to do with imbalance operands.
Post 31 Aug 2017, 04:29
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
Tomasz Grysztar wrote:
system error wrote:
The rule is never defined in the Manual anyway.
fasm's documentation directs you to the Intel manual for a more ground-up explanation of everything. And the rule concerning destination and source order is still there. I just consulted my collection of Intel manual revisions and here's how the rules was stated back in 1986:
Intel 80386 Programmer's Reference Manual, section 1.3.3 wrote:
When two operands are present in an instruction that modifies data, the right operand is the source and the left operand is the destination.
And how it looks in the modern one, 30 years later:
Intel® 64 and IA-32 Architectures Software Developer’s Manual, section 1.3.2.1 wrote:
When two operands are present in an arithmetic or logical instruction, the right operand is the source and the left operand is the destination.


IMHO, assembler is an INTERFACE to the machine binaries / CPU to make things easier and more understandable to human sense. Assembler is the one that makes the CPU accessible and programmable.

I am surprised that some people here are so passionate in dumping the beginners with advanced things like instruction prefixes, operand sizes and instruction groupings just for a simple error like imbalance operands. They might as well teach how to figure out the SIB byte, ModR/M bits and pieces and Instruction Length engine.
Post 31 Aug 2017, 04:46
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1424
system error wrote:
That brings us to Rule 7

Rule 7 - x86 is a variable-length instruction machin

I bet you didn't know about this either.
Yeah I'm sure ARM has only one size for all operands, because operand sizes is what matters, for some reason. Since it's a fixed-length instruction set. It is inconceivable that you could map two opcodes (say, 0xCC and 0xCD) to "mov r32, r32" and "mov r16, r16" respectively. Too hard for you. (which is exactly what x86 does with r8, a totally separate opcode for it, if you'd actually read Intel's official instruction tables instead of technobabbling)

I'm sick of your technobabble, you're on total ignore mode from now on except when I can humiliate you. (and yes, you "bet" I didn't know this when my 2nd post in this thread before your ass even posted showed how one insn is 2 bytes (opcode + mod R/M) and the other has extra prefix meaning it's 3 bytes -- way to wreck your own arguments).

In fact, I wasn't even talking to you. You mad or what? Get your attention from someone else (but nobody will since they don't want to deal with you).

system error wrote:
I haven't seen you creating any macro so far. All talk and empty impressions.
Says mr. "pseudo code".

system error wrote:
The syntax is enforced by the assembler.
I don't care about the assembler, I'm talking about the CPU.

NO ASSEMBLER will work with "add eax, bx" and perform the operation intended (macros or AT&T can use it, but the instruction itself is forced in the suffix, i.e. "addl" for 32-bit, so it's not "add 16-bit to 32-bit number"). EACH ASSEMBLER has its own syntax and enforces it in its own way, yet NONE OF THEM will provide that operation.

Your answer is pure trash since the answer must be *independent* of any assembler, it's a CPU thing, not assembler. It's not a syntax enforced thing, it's a CPU thing, because all assemblers, regardless of syntax, won't perform that operation (add 16-bit to 32-bit). Because it doesn't exist.

Read OP's post again, he is asking why he can't add a 16-bit number to 32-bit number. He's talking about the actual operation performed, not the syntax. Like I said, AT&T allows you to use such a syntax, but the operation is still not what you'd expect -- it will add 32-bit to 32-bit (or 16-bit to 16-bit). I agree with revolution that it's retarded, since it will definitely confuse people like you who think syntax means anything (lol) and then wonder why the actual operation is not what you expect.

Oh, and AT&T is very successful unlike your "pseudo code", don't be hating on real code bro. Wink
Post 31 Aug 2017, 11:43
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
Quote:
I don't care about the assembler, I'm talking about the CPU.


You're in the wrong forum then. This is an assembler forum, as in "flat assembler" (see top of page).

You want electronics, there is one:

https://forum.allaboutcircuits.com/

They talk electronics, flip-flops, capacitors and NAND gates. Sign up there and you can go as mouthful as you want about the CPUs. Their main focus is on CPU and microprocessors.

Enjoy.
Post 31 Aug 2017, 13:29
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1424
^ lol

So if someone asks "why does this code segfault when ran?" it's off topic on this forum, says system error.

Why? Because it assembles fine. So there's no error in the assembler: it gives you what you want. So it has nothing to do with FASM directly.

The segfault happens when ran by a CPU (and depending on CPU, some might fault while others won't, i.e. illegal instructions or misalignment). So obviously such questions should be posted on electronics boards (lol!). It's not like FASM runs any of your assembled code so... all such runtime questions are off topic. Rolling Eyes

Awesome insight as always.


EDIT: There's a subforum for you: Compiler Internals. That's all about syntax.
Post 31 Aug 2017, 13:46
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
Furs wrote:
^ lol

So if someone asks "why does this code segfault when ran?"


Because it has committed a semantic error of the program.

See, SEMANTIC ERROR and SYNTAX ERROR are not CPU / Electronic terminologies. They are very specific terminologies in programming language and extremely important to Language authors like Tomasz Gryzstar and Gosling (the author of JAVA). And "flat assembler" is a programming language xD

There's one software for you if you DO NOT CARE about ASSEMBLER and only concern about CPU and opcodes --> Use Hex Editor to communicate with the CPU directly by using hard coded opcodes! No syntax errors. No semantic errors. No rules.

Here's one:
https://mh-nexus.de/en/hxd/

Good luck and take your time.
Post 31 Aug 2017, 15:33
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1424
Untrue. The OP said this:
The_Unknown_Member wrote:
Why I can't add the number stored in the 16bit bx register to the number stored in the 32bit eax register and store the result in the eax register ?
He's talking about the operation, not the syntax. He didn't ask: "why can't I assemble with this syntax?" or "why does this fail to assemble?" -- I'm sure he can read the error message already.

That syntax (given a suffix) is allowed in AT&T asm for example -- so he could have asked that if he came from AT&T asm (I know he didn't, I'm just saying, it's a valid hypothetical question).

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.
Post 31 Aug 2017, 15:42
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
Furs wrote:
Untrue. The OP said this:
The_Unknown_Member wrote:
Why I can't add the number stored in the 16bit bx register to the number stored in the 32bit eax register and store the result in the eax register ?
He's talking about the operation, not the syntax. He didn't ask: "why can't I assemble with this syntax?" or "why does this fail to assemble?" -- I'm sure he can read the error message already.

That syntax (given a suffix) is allowed in AT&T asm for example -- so he could have asked that if he came from AT&T asm (I know he didn't, I'm just saying, it's a valid hypothetical question).

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.


The status of the faulty operation is posted by the Error Message. The first question that you should ask is "what's the error message". Not extending your garbage to instruction prefix and the opcodes. See, how your extended garbage can induce an even steeper learning curve for beginners?

Why not extend your garbage to General Protection(GP), Undefined (UD, Non-Encodable (NE) and all those low-level CPU stuff?

Or just follow the lead provided by the Assembler: "Error: Operands sizes do not match"?
Post 01 Sep 2017, 03:54
View user's profile Send private message Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
Furs wrote:
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.


Runtime?? Hahahahaha!

The assembler will not even let it pass the compilation phase. No. No executable for you! Guess WHY!!

What a clown! xD
Post 01 Sep 2017, 04:02
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 552
Location: Belarus
system error wrote:
The rules of the INTEL INSTRUCTION SYNTAX is implemented by the assemblers. So the "OPERAND SIZE MUST OF OF EQUAL SIZE" is not my opinion. So this error message

Error: Operand sizes do not match

is not Tomasz Gryzstar's "opinion" either.

He takes that rules from Intel/AMD. And every single ASM programmers out there know this extremely important rule.

You definitely have no idea of the difference between syntax and semantic analysis. Being rude won’t help.

And I guess you’ll be kind enough to give us the exact page of the Intel/AMD specifications/manuals, where the rules (which, of course, are useful shortcuts for newbies) are stated explicitly. It’s not that difficult for you, if you say it in such a manner.
Post 01 Sep 2017, 09:56
View user's profile Send private message Visit poster's website Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
uh geezz, I don't know... maybe we can ask 3 different assembler authors how did they come up with the same conclusion of imbalance operand SIZES and stop the compilation process immediately.

Code:
x dw 5
...
add eax,word[x] ;NASM =======> error : Mismatch in operand sizes
add eax,x       ;MASM =======> error A2022:instruction operands must be the same size
add eax,[x]     ;FASM =======> Error: Operand sizes do not match    


Wait, these IMBALANCE operands errors are never directly mentioned in the manuals either but yet 3 different authors agree to the same rule violation conclusion or "opinion" according to "Furs". Magical extreme coincidence??

They must have known something that we don't from their first-hand experience dealing with raw instructions and encoding.

Or maybe they "definitely have no idea of what they are doing" as you claimed them to be? 3 different authors + me... seemed to be clueless.

Take your pick.
Post 01 Sep 2017, 14:08
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16699
Location: In your JS exploiting you and your system
system error: I'm not sure what you are arguing. No one is disputing that for the current instruction set in x86 with ADD that the register sizes need to match. Where you seem to differ is the reason for that restriction. All the way back in this thread Furs stated (correctly) that it is because the CPU has no encoding for ADD with different registers sizes. However you seem to be stating (and please correct me if I am wrong here) that the reason is because the assembler refuses to assemble such instructions. In a sense both are correct, but the assembler's refusal stems directly from the root cause, which is that the CPU instruction encodings currently don't have this capability. But there is no fundamental reason why in the future such a thing could not exist if the desire and purpose was strong enough to make it worthwhile. If Intel/AMD decide to implement ADD with different sized registers then they could, there is no law or rule that prevents them doing such a thing. Such a scenario has yet to happen, but that doesn't mean it is somehow verboten for ever and ever. And as has been stated previously ARM have in fact done exactly this with saddw and uaddw, so perhaps Intel/AMD will one day see a need for it. We don't know. Maybe they won't. We also don't know.
Post 01 Sep 2017, 14:25
View user's profile Send private message Visit poster's website Reply with quote
system error



Joined: 01 Sep 2013
Posts: 671
@revo

I also explained that...
Quote:
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 / preserve that rule and characteristics

This characteristics is important to be preserved / observed in x86 architecture if you're involved in making assemblers and disassemblers. The fact that 3 different authors come up with the same conclusion shows that this is indeed an important RULE and a CHARACTERISTICS of x86 Instruction Set Architecture, hence my Rule #1.

If you're involved in making a disassembler, 90 percent of the time you'll have to assume that this rule is correct. The same goes with assembler authors. This is a shared / common rule being relied upon by both ASM and DISASM authors.

This is even more important to DISASM authors because they have to rely on unpredictable open-ended streams of bytes where one can never anticipate where and when an instruction exist and ends as a valid unit without having the correct lookup table, offset calculations and instruction prefixes. But this assumption or RULE help effectively ease thing a lot in extracting a valid instruction unit out of those instruction streams, except for a few exceptions.

So when an author of a ASM or DISASM says that it is a RULE, then it is a valid "opinion" because they have first-hand experience dealing with it --> hence the error message "Error: Operand sizes are not equal" being emitted by 3 different assemblers even if it has never been explicitly stated in the manuals.

Tomasz don't really want to argue against my Rule #1 because he knows exactly what I was talking about and he, as an ASM author, agrees to it most of the time.
Post 01 Sep 2017, 14:58
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.