Hello,

I saw there is a new version of fasmg, strangely it has the same version number 'hoh12' as the version from the 18th of January.
The example i uploaded recently ( https://board.flatassembler.net/topic.php?t=19678 ) does not compile with this newer version.
The error is 'extra characters on line.'
I think i found what goes wrong, looks like "equ" does not replace like before.
It seems to happen only when i pass in an argument like "dword [rect.top]" to my "call64" macro.
Perhaps it is something i was doing wrong in the first place, that could also very well be the case.
Please let me know if any more information is needed.

The version number is not changed because the package still contains the same fasmg version, only the examples (including x86 macros) have been updated. I have changed the way in which size operators are processed to make macros work a bit faster, probably this is what causes the problem.

Thanks for the reply.
It does explain why other calls to the call64 macro are ok, it's indeed specifically when dword override is used.
My current version of my proc64.inc is getting a bit messy anyway so i'll do a rewrite of it.

Regards

This new implementation of size operators is more fragile in term of symbolic constant usage, it uses definitions like "define dword x86.size(4)" and "x86.size" in turn is a symbolic variable with empty value (so the next pass of symbolic replacement would make just plain "(4)").

Thus you basically need to pass exactly "dword operand" to instruction so upon MATCH it is seen as "x86.size(4) operand". To define an operand containing size operator in form of symbolic constant you need to ensure that after a replacement of symbolic variables for MATCH it contains "x86.size(#)", for example by using EQU:
I'm a bit torn on this, because this variant is less bullet-proof, as you problem demonstrates, but it works noticeably faster (because this way I got rid of MATCH sequences for sizes). And, on the other hand, if in your additional macros you use the knowledge that size operators are defined symbolically as "x86.size(#)", you may use this to simplify them too.

PS. If you need to perform MATCH without performing any symbolic replacements, use the same trick as in fasm 1, with a temporary symbolic variable: Do not use RMATCH for this purpose, since RMATCH does not preserve the context of parameter values. You could, however, use RMATCH in cases where you do not cut any parameters out of the matched expression:

Sidenote: I now feel that RMATCH name is a bit too cryptic, perhaps since fasmg now includes synonyms like ITERATE for IRP I should also make RAWMATCH as a synonym for RMATCH.

I have some ideas how to make this more resilient. I may update the macros once more.

The new variant still breaks your macros, but in a way that is much easier to fix. The keywords like "dword" are no longer re-defined symbolically. Instead, macros use variables defined in "x86" namespace - like "define x86.dword? :4" - to detect and extract sizes.

Your sample still does not assemble because neither in this variant you cannot simply pass a symbolic variable containing size operator inside to instruction macro, you need to pass the size operator directly. Adding another layer of symbolic replacement to "parse_operand" could help with that, but it would be a bit clunky. You cannot hide the other structural elements of instruction (like mnemonic or commas between operands) behind a symbolic variable anyway.

But to get you macros to work with this variant, it is enough to replace these fragments: with something like:

Thank you, it works now.

I ended up using this form :



I left out the second match for my purpose (otherwise there was no match for a non-specified size which i assume to be 8, currently i only use dword explicitly or qword implicitly)

One question left, i get that the version number is not changed when the engine is not changed, the x86 macro's are examples after all.
It's easy to check what changed doing that oneself, with "diff -r ..." for example, but would it be an idea to include a small description of the intent of the changes ?

Regards.

Well, since they are examples after all, I should perhaps keep them simple. Making them faster may actually cause them to become less readable, and that is not a good idea for an example after all. So I think I'm going to revert these changes and keep the optimizations in mind for a dedicated macro package (like my Win32 headers that I plan to get back to after I'm finished with instruction sets).