"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.

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.

system error wrote:

"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.

Syntax rules are concerned with the textual representation of the code. All assemblers enforce their own particular syntax rules

Of course, he's a beginner. Many times, a beginner doesn't even know the correct /valid questions to ask.. You need to apply some common sense.

system error wrote:

Of course, he's a beginner. Many times, a beginner doesn't even know the correct /valid questions to ask.. You need to apply some common sense.

That's your opinion. You've no proof for it so... I'm answering questions based on what they actually are, cause I'm not his dad to know what he "wants" to ask. (you aren't either, it's simply your assumption)

It requires space from the CPU Register's memory or from the RAM ?

Thanks for the answer!

Nope. The guy clearly thinks that a CPU can execute any sort of operation and it's not bound by implementation and opcodes. Like in HLLs where you can add 16-bit number to 32-bit since there are no opcodes there.

The simplest explanation is "operands sizes are not equal".

system error wrote:

The simplest explanation is "operands sizes are not equal".

An explanation he's already aware of, given that he gets the error message. I'm sure he'll appreciate it, Captain Obvious.

especially when he's on command-line interface.

flat assembler  version 1.71.64  (1310719 kilobytes memory)
test.asm [2]:
add eax, bx
processed: add eax,bx
error: operand sizes do not match.

C:\>    

system error wrote:

especially when he's on command-line interface.

Funny:

Code:

flat assembler  version 1.71.64  (1310719 kilobytes memory)
test.asm [2]:
add eax, bx
processed: add eax,bx
error: operand sizes do not match.

C:\>    

Message exactly above the input, not obvious enough, makes sense. More excuses.

But anyway, it's still your assumption,

No. It's all about your "expert" attitude that FORCED him to ask "register's memory or RAM" in his 2nd post when you went moutfhul about "opcode space".

system error wrote:

No. It's all about your "expert" attitude that FORCED him to ask "register's memory or RAM" in his 2nd post when you went moutfhul about "opcode space".

I don't see this as a problem. I find it is better to assume more knowledge than less, and backtrack if the poster doesn't understand. If you assume immediately that someone is a complete newbie and start explaining about how bx is 16bit or something, then people can take that as condescending if they already know such things.

There is no harm if you supply more information that what is asked for. People can choose to ignore it if that don't care about it or don't understand it. It also allows them to ask follow-up questions and learn something they would otherwise might not have known to ask about.

But at the end of the day, simply trying to help is enough to encourage people to ask more and learn more. Even if it is pitched too high the first time around, people appreciate the effort and will feel comfortable clarifying their query further and learning things in the process.

Opcode space WHAT??? WTF is opcode space?

Five bits named m. Two of the m bits are used for replacing existing escape codes and for specifying the length of the instruction. The remaining three m bits are reserved for future use, such as specifying vector lengths >256 bits, specifying different instruction lengths, or extending the opcode space, however as of 2013, Intel decided to introduce a new encoding scheme, the EVEX prefix, rather than expand the remaining m bits.

Before the opcode space was exhausted [...]

system error wrote:

Opcode space WHAT??? WTF is opcode space?

When in doubt, before embarrassing yourself, always check revolution's site first.

First result: https://en.wikipedia.org/wiki/VEX_prefix

Wikipedia wrote:

Five bits named m. Two of the m bits are used for replacing existing escape codes and for specifying the length of the instruction. The remaining three m bits are reserved for future use, such as specifying vector lengths >256 bits, specifying different instruction lengths, or extending the opcode space, however as of 2013, Intel decided to introduce a new encoding scheme, the EVEX prefix, rather than expand the remaining m bits.

Obviously, this is about VEX, it was first hit so I used it, but 2nd (stackoverflow) hit explains it as well. See: https://stackoverflow.com/questions/41720529/is-there-a-pattern-to-x86-op-codes-other-than-direction-and-size-bits:

Margaret Bloom wrote:

Before the opcode space was exhausted [...]

Each x87 register, known as ST(0) through ST(7), is 80 bits wide and stores numbers in the IEEE floating-point standard double extended precision format. These registers are organized as a stack with ST(0) as the top. This was done in order to conserve opcode space, and the registers are therefore randomly accessible only for either operand in a register-to-register instruction; ST0 must always be one of the two operands, either the source or the destination, regardless of whether the other operand is ST(x) or a memory operand. However, random access to the stack registers can be obtained through an instruction which exchanges any specified ST(x) with ST(0)