Index
> Main > Why this operation is not possible ?Goto page Previous 1, 2, 3, 4, 5, 6 Next |
| Author |
|
|
Tomasz Grysztar 30 Aug 2017, 12:51
system error wrote: The rule is never defined in the Manual anyway. 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. 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. |
|||
30 Aug 2017, 12:51 |
|
|
revolution 30 Aug 2017, 13:03
Even Intel break their own rules
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". |
|||
|
30 Aug 2017, 13:03 |
|
|
Furs 30 Aug 2017, 14:15
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. 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 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. |
|||
|
30 Aug 2017, 14:15 |
|
|
revolution 30 Aug 2017, 14:25
Furs wrote: ... in AT&T asm you can specify the "size" of the insn with a suffix, even if the registers don't match. |
|||
|
30 Aug 2017, 14:25 |
|
|
Tomasz Grysztar 30 Aug 2017, 15:41
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. |
|||
|
30 Aug 2017, 15:41 |
|
|
system error 31 Aug 2017, 04:25
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. |
|||
|
31 Aug 2017, 04:25 |
|
|
system error 31 Aug 2017, 04:29
revolution wrote:
I think I have already mentioned it twice that PUSH/POP are single-operand instructions and has nothing to do with imbalance operands. |
|||
|
31 Aug 2017, 04:29 |
|
|
system error 31 Aug 2017, 04:46
Tomasz Grysztar wrote:
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. |
|||
|
31 Aug 2017, 04:46 |
|
|
Furs 31 Aug 2017, 11:43
system error wrote: That brings us to Rule 7 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. system error wrote: The syntax is enforced by the assembler. 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.  |
|||
|
31 Aug 2017, 11:43 |
|
|
system error 31 Aug 2017, 13:29
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. |
|||
|
31 Aug 2017, 13:29 |
|
|
Furs 31 Aug 2017, 13:46
^ 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. 
Awesome insight as always. EDIT: There's a subforum for you: Compiler Internals. That's all about syntax. |
|||
|
31 Aug 2017, 13:46 |
|
|
system error 31 Aug 2017, 15:33
Furs wrote: ^ lol 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. |
|||
|
31 Aug 2017, 15:33 |
|
|
Furs 31 Aug 2017, 15:42
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 ? 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. |
|||
|
31 Aug 2017, 15:42 |
|
|
system error 01 Sep 2017, 03:54
Furs wrote: Untrue. The OP said this: 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"? |
|||
|
01 Sep 2017, 03:54 |
|
|
system error 01 Sep 2017, 04:02
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 |
|||
|
01 Sep 2017, 04:02 |
|
|
DimonSoft 01 Sep 2017, 09:56
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 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. |
|||
|
01 Sep 2017, 09:56 |
|
|
system error 01 Sep 2017, 14:08
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. |
|||
|
01 Sep 2017, 14:08 |
|
|
revolution 01 Sep 2017, 14:25
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.
|
|||
|
01 Sep 2017, 14:25 |
|
|
system error 01 Sep 2017, 14:58
@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. |
|||
|
01 Sep 2017, 14:58 |
|
| Goto page Previous 1, 2, 3, 4, 5, 6 Next < Last Thread | Next Thread > |
Forum Rules:
|