flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > Error compiling source with newer fasmg.hoh12

Author
Thread Post new topic Reply to topic
Jerry



Joined: 24 Dec 2016
Posts: 18
Location: Zeist, Netherlands
Jerry 31 Jan 2017, 08:50
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.
Post 31 Jan 2017, 08:50
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 31 Jan 2017, 11:28
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.
Post 31 Jan 2017, 11:28
View user's profile Send private message Visit poster's website Reply with quote
Jerry



Joined: 24 Dec 2016
Posts: 18
Location: Zeist, Netherlands
Jerry 31 Jan 2017, 11:47
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
Post 31 Jan 2017, 11:47
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 31 Jan 2017, 11:58
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:
Code:
operand equ dword [ebx]
add operand,1 ; works, because "operand" is now "x86.size(4) [ebx]"    

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.
Post 31 Jan 2017, 11:58
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 31 Jan 2017, 12:06
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:
Code:
define tmp arg
match sizespec [memref], tmp    
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:
Code:
rmatch =dword?, size    


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.
Post 31 Jan 2017, 12:06
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 31 Jan 2017, 15:17
I have some ideas how to make this more resilient. I may update the macros once more.
Post 31 Jan 2017, 15:17
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 31 Jan 2017, 17:05
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:
Code:
match =dword?, setting.size
        mov ecx, setting.size setting.op
else
        mov rcx, setting.size setting.op
end match    
with something like:
Code:
match =dword?, setting.size
        mov ecx, dword setting.op
else match size, setting.size
        mov rcx, size setting.op
end match    
Post 31 Jan 2017, 17:05
View user's profile Send private message Visit poster's website Reply with quote
Jerry



Joined: 24 Dec 2016
Posts: 18
Location: Zeist, Netherlands
Jerry 01 Feb 2017, 05:43
Thank you, it works now.

I ended up using this form :

Code:
match =dword?, setting.size
        mov ecx, dword setting.op
else 
        mov rcx, setting.op
end match
    


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.
Post 01 Feb 2017, 05:43
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 01 Feb 2017, 19:30
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).
Post 01 Feb 2017, 19:30
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.