flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > 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

Error compiling source with newer fasmg.hoh12

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
Assembly Artist


Joined: 16 Jun 2003
Posts: 6685
Location: Kraków, Poland

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

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
Assembly Artist


Joined: 16 Jun 2003
Posts: 6685
Location: Kraków, Poland

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
Assembly Artist


Joined: 16 Jun 2003
Posts: 6685
Location: Kraków, Poland

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
Assembly Artist


Joined: 16 Jun 2003
Posts: 6685
Location: Kraków, Poland

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
Assembly Artist


Joined: 16 Jun 2003
Posts: 6685
Location: Kraków, Poland

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 ecxsetting.size setting.op
else
        mov rcxsetting.size setting.op
end match

with something like:

Code:
match =dword?setting.size
        mov ecxdword setting.op
else match sizesetting.size
        mov rcxsize 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

Thank you, it works now.

I ended up using this form :


Code:

match =dword?setting.size
        mov ecxdword setting.op
else 
        mov rcxsetting.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
Assembly Artist


Joined: 16 Jun 2003
Posts: 6685
Location: Kraków, Poland

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


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2017, Tomasz Grysztar.