Tomasz, can you please give some tips for writing more optimal calminstructions and macros in general (if its optimization can have any overal impact)
For example,
- is it better to use long expressions for compute/check or better to split in shorter computations across multiple commands, or doesn't really matter?
- how heavy 'elementsof' and other poly operations are? In instruction operands parsing, does it make sense to use elementsof to check if the value is an immediate or belongs to registers domain? would it make sense, for example, to compute 'operand metadata 1' to a variable rather then repeat the operation twice, etc.
Any general rules of a thumb on how to write good calminstructions? Thanks in advance!

First of all, the expression evaluator in fasmg is really not well tuned at the moment - before I introduced CALM it was not a problem, as its poor performance was generally overshadowed by preprocessing-related overhead, but with CALM I have now exposed its problems and it's a bit of a shame. I may try to improve some of the most critical paths in the future, but I do not promise anything at the moment.

Also, ALM compiler is currently not doing any expression optimization, so even if your expression contains only numeric literals and no variable references, it is still not going to be reduced and COMPUTE is going to perform all the operations. Which means that if you use an expression to compute a constant, it is better to calculate it separately at definition time. For example: vs You can compare by executing such macro a milion times or so. And I generally recommend to test things this way if you need to find out the best of the variants that you consider.

On the other hand, when your expression contains multiple operations on variables, it may be slightly better to leave it as a single complex expression instead of splitting it into multiple COMPUTE commands - there is a small overhead related to assigning results to variables. But this overhead is still likely smaller than the time needed for any actual computations, so if you can calculate a sub-expression that is common to multiple COMPUTE/CHECK commands and store it into variable, it is most likely better to do so.

All of the above could perhaps be summarized into a simple rule of thumb: first minimize the number of operations performed by your COMPUTE commands (including moving some of them to the definition-time if possible) and secondarily minimize the number of separate commands.

One more thing: when a sub-expression is inside a symbolic variable, then its computation is going to be even slower, as it needs to be parsed before it can be evaluated. If you have an argument that you use multiple times in COMPUTE/CHECK commands, start by converting it into its evaluated numeric value: You can also use this opportunity to enforce specific evaluation: And this pattern also prevents some other problems, like evaluation with a wrong value of $, etc.

A little off-topic, but I have just realized that there is a little trick that allows to easily create a mask spanning a given number of bytes. The same as: can be done with:

In one sense it seems cryptic. (the hidden truncation)
Yet, in another it seems more expository. (three bytes)

It feels weird to me that "((-1) bswap 3) bswap 3" doesn't return the original value of -1

The original -1 is arbitrary length, while with "bswap N" you introduce a fixed size. You get a -1 valid for that size, but obviously you cannot get anything longer (endianness switching does work well for "infinite" length numbers).