use32
add eax, [dword 0] ;choosing addressing mode. OK.
add eax, [word 0]  ;choosing addressing mode. OK.
use64
add rax, [qword 0] ;WTF? This does not exist, but still compiles. Not OK.
lea rax, [qword 0] ;same problem. Not OK.
mov rbx, [qword 0] ;same problem. Not OK.

use32
;Is there a way to generate 0xFFC0 at all in 32 bit mode?
inc dword eax ;not documented. However expected long opcode analogous to e.g. push    

use64
org 0
;Obviously there's an attempt to generate a rip-relative address,
;but it fails. The instruction however still exists. Thus failed
;optimization should not result in failed compilation.
mov rax, [$123456789] ;does not compile without qword. Not OK.

;This one is even worse. There are 2 ways to encode the instruction,
;but fasm does not find any of those.
org 100000000h
lea edx,[0]        ;fails to compile. Not OK.

;absolute addressing enforced:
org 100000000h
lea edx,[dword 0]  ;OK. But not the expected encoding for the previous one.

;eip-relative addressing enforced:
org 100000000h
lea edx,[eip - @F and 0xFFFFFFFF + 0] ;kinda perverse way. This is the expected encoding for lea edx,[0]
@@:    

struc x .
{
        local .,.
                display `.,13,10
}
a x b    

"""aaaaaaaa    

display .world
hello:
.world = 'a'    

HKEY_CLASSES_ROOT     = 80000000h or -80000000h
HKEY_CURRENT_USER     = 80000001h or -80000000h
...    

org $100000000
use32
dd 'xxxx'
load xxxx dword from $-4 ;fails to compile    

1. I know, that in some cases semantics of the size modifiers is to produce a longer instruction encoding. And sometimes is to choose the corresponding addressing mode. Here are some examples of that behaviour beeing seemly inconsistent:

Code:

use32
add eax, [dword 0] ;choosing addressing mode. OK.
add eax, [word 0]  ;choosing addressing mode. OK.
use64
add rax, [qword 0] ;WTF? This does not exist, but still compiles. Not OK.
lea rax, [qword 0] ;same problem. Not OK.
mov rbx, [qword 0] ;same problem. Not OK.
    

        lea     rax,[dword -1]          ; RAX := 0x00000000FFFFFFFF
        lea     rax,[qword -1]          ; RAX := 0xFFFFFFFFFFFFFFFF    

Code:

use32
;Is there a way to generate 0xFFC0 at all in 32 bit mode?
inc dword eax ;not documented. However expected long opcode analogous to e.g. push    

2. In some cases fasm fails to compile correct instructions because of a failed optimization attempt.

5. I don't know if it's a documentation lack, but the behaviour of dotted numeric constants is unclear. I acutally didn't expect the following one to fail:

Code:

display .world
hello:
.world = 'a'    

The documentation states, that numeric constants are "very much like labels", but does not really define the borders of this "very much like". For example, "global" numeric constants do not become prefixes for dotted labels or numeric constants. Why then dotted numeric constants are prefixed by "global" labels?[/code]
What would one expect to be displayed here? Empirically it seems like the struct name a is overridden by the argument b, which is in turn overridden by the first local symbol . and then by the second local symbol . . Additional identically named local symbols will override the previously defined. But I didn't find any documentation on that.

3. This one is rather a documentation lack. The order of preprocessing is undefined when symbols with identical names are used for different purposes. The most critical case seems to be this one:

Code:

struc x .
{
        local .,.
                display `.,13,10
}
a x b    

What would one expect to be displayed here? Empirically it seems like the struct name a is overridden by the argument b, which is in turn overridden by the first local symbol . and then by the second local symbol . . Additional identically named local symbols will override the previously defined. But I didn't find any documentation on that.

In long mode it is choosing addressing mode, the same. Please compare the results of these two instructions in long mode

fasm's assembly language focuses primarily on what the instruction does, not how it is encoded.

However I'm not happy with this feature, as it breaks the general rule of abstraction that I chose to follow stricly in other places.

There is however one relic in fasm's syntax that breaks this rule    

This is most probably related to this discussion

This was later changed due to users' request, so that the numeric variable would not create a new locals prefix

Details like this are documented in the section 2.3.7 of official manual

What if an instruction is on a page boundary and the next page would be not executable? What about all those multibyte nop's specifically introduced by Intel for code alignment? Disregarding their sizes those are all functionally equivalent. Would you want to optimize those out?

Or why woudn't you optimize xchg rbx,rbx into a nop?

Compilation problems described there are related to forward referencing labels. In my examples, fasm can't compile just normal instructions.

you provide the guidelines for assembler and it tries to find the best solution

Assembler's main purpose is to provide the highest level of control over the output, while giving as much as possible of coding simplification features.

That may be the definition that you chose, but for me the assembly was primarily the abstraction that I mentioned.

The code resolving idea [...] was at the core of fasm since the beginning.

It is much better to say "I want to have that instruction aligned to paragraph boundary" than to say "I want this instruction to be five bytes long" - the first one shows the true reason behind the request

OK. But would you then clarify your understanding of the difference between an assembler and high level languages?

The difference is that you use native machine *commands*. Commands, not encodings.

programmer should express the intent with native machine commands (mnemonics) and assembler should choose the most optimal encodings

Besides, definition of the word "mnemonic" is flexible. Are push and push dword the same mnemonic?

Would you accept an assembler to compile a nop instead of xchg rbx,rbx?

If not, why do you accept push dword 1 to be compiled into a short form push 1 without giving you any possibility to specify the longer form?

I don't know any other definition of mnemonic than the one that states that it is that first word of assembly command

BUT, I decided to generally not implement optimizations that would cause the instruction in disassembly to look completely different from the one in source

I added it solely for the purposes of SMC.

I planned to separate the assembly instruction syntax from the additional hints for the encoder, which would be specified as annotations beside the main instruction.

E.g. the processor documentation does not specify different mnemonics for (differently behaving) instructions CC and CD 03. Therefore you had to extend the conventional syntax making the '3' a part of the first token. The point is that if you claim to be willing to abstract from the encoding, you actually could do it the opposite way: int3 for CD 03 and int 3 for CC.

Sounds really nice. I'm a little confused about the word "hint"? Does it mean, that I could provide a hint and the encoder would still ignore it for the sake of optimization?

I created two different mnemonics, because they are actually two different instructions - they differ a bit in what they do, this is not simply a matter of choice between longer or shorter encoding.

I only thought about the case when you specified a hint "encode immediate as 32-bit value", but instruction had no immediate at all

It seems like you have some cases in mind, where the presence of an immediate is not obvious for the programmer. Otherwise this situation is rather a subject to fail compilation and to report an error.

rb 1
space::
org 0
store byte 'A' at space:$$    

Code:

use64
org 0
;Obviously there's an attempt to generate a rip-relative address,
;but it fails. The instruction however still exists. Thus failed
;optimization should not result in failed compilation.
mov rax, [$123456789] ;does not compile without qword. Not OK.