Hello, revolution.

Can fasmarm produce executables in common case (with arm specific relocations)?
why mov replaced with movw (is movw clears higher part???, movt stays lower part untouched)
is any source where described all instructions with clear description of what they affect (like movw above, is it clears high part or not), CPU dependent restrictions. and so that all instructions would be in one place but not as manual to one specific CPU with only instruction supported by this CPU.

fasmarm doesn't produce any relocations in the currently supported formats.

movw is for immediate constants and allows the full 16-bit lower half to be defined and the upper half is cleared. movt only sets only the upper half, leaving the lower half unchanged. This behaviour is described in the ARM manuals. I recommend you download them.

I have not reproduced the ARM instruction documentation in any format. But there are other websites that have "more friendly" descriptions of the instruction operations.

I have links to the official ARM documents on the fasmarm webpage. Other sources may be incorrect, out of date, or wrong, so beware when obtaining information from other places.

IME the ARM documents are quite tricky parse to extract the CPU dependant information. But it is still important to take note of it as there are many variants out there. One can choose to use the default mode of simply allowing all instruction variants, but I don't recommend it unless you are really confident that you will never accidentally have a longer branch than is supported, or a similar type of encoding restriction. The assembler can monitor that for you if you let it. That is it's job, to show encoding errors that would otherwise be really tedious and tricky to control manually.

Interesting, this might be another good reason to work on "fasmgARM" macros...

Perhaps if you make it faster. My measurements for fasmg vs fasm are ~160 times slower on the sources I tested. fasmg was taking almost an hour to finish vs 20 seconds for fasm.

Was it on some x86 sources? These macros are overly complex.

That was x86 code from our production sources. I would be very embarrassing to send something to the clients that takes an hour to build and requires many external support .inc files to get the desired output.

May be we try to encode some arm instructions in fasmg?
all instructions could be classified in arm specification except one - mov, because it is very overloaded:
in simplest case src could be reg or shifted reg.
then depending on arg sequence it can be interpreted as "add" or "sub" when src arg relative to reg,
in case of constant src value tryed to be encoded in instruction as i shl 12 + r shl 8, where
i=%-1
enc=src shl (2*(i and 15)) or src shr (32-(2*(i and 15)))
If value unencodable tryed variant with invertion of src, same testing formula.
Then if value still unencodable tested precedence & presence of specific instruction set via literal pool, if OK, src value compared with $FFFF and encoded if it fit.
if all previous fails to encode src operand it tested for precedence with "=" sign, if no sign - compiler should generate error, otherwise add constant to literal pool.
(that was only checking for arm mode)

instead of preceding to params branch that breacks pipeline we could encode params after call, (call breacks pipeline no matter that it return execution to next instruction), and call itself would be something as
mov lr,pc+xxx
ldmia lr,{lr,pc} - in literal pool we could place call & ret addr and params,
or making
ldmia lr,{r0-r3,lr,pc} to load everithing what call needed if it (4 params) within single instruction.
call address can have local jump elevator to import or direct call (or could be direct call itself).
import elevator is sequence (defined once within distance +/-$FFF where it could be used):
ldr ip,[pc]
ldr pc,[ip]
DTD iat_corresponding_firstchunk
that makes much more places for literal pools.

there are complex with encoding b & bl:
the way how value will be stored in instruction will be depending on mode 26bit or 32bit, ARM or THUMB.

arm could be bigendian and littleendian so for structures is no more enought to define only directive size, things that depend on endianess should be declared as DTD or DTW (dw or dh) but strings or endianess independent parts as db or du with appropriate sequence of ? after them.

Endianness does not apply to the encoding. The instructions are always little endian regardless of the mode the CPU is using for data access.

If we look at import elevator as 12 byte representation of abstract instruction, DTD part will depend on endianess.

Yall know that I toiled with aarch64+fasmg enough to get a chess program working on my phone? Its not perfect but it is a good start, and the relocations were working to some extent.
https://github.com/tthsqe12/asm/tree/master/arm/include/hello