flat assembler
Message board for the users of flat assembler.

Index > Compiler Internals > bug in conditional assembly

Author
Thread Post new topic Reply to topic
pfranz



Joined: 13 Jan 2007
Posts: 116
Location: Italy
pfranz 04 Dec 2014, 21:03
Hello,
I updated my hwtest with the new fasm 1.71.22 and while before it compiled fine, now it gives an error at line 346 in rtl8169.asm.
This line is inside and IF 0 / END IF block, so it shouldn't give any error. If I comment it with ; there is no problem, but this looks like a bug.

Find attached my hwtest and try to run MAKEFLOP.BAT (if it compiles fine, press CTRL+C to exit).


Description:
Download
Filename: HWTEST.7z
Filesize: 465.84 KB
Downloaded: 825 Time(s)

Post 04 Dec 2014, 21:03
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20363
Location: In your JS exploiting you and your system
revolution 04 Dec 2014, 21:07
pfranz wrote:
... the new fasm 1.71.22 ...
Erm, the current version is 1.71.28.

Please try with the latest version and report again if the problem is still there.

Also, please try to post a minimal example. A 465k compressed file is not really an example to test with.
Post 04 Dec 2014, 21:07
View user's profile Send private message Visit poster's website Reply with quote
pfranz



Joined: 13 Jan 2007
Posts: 116
Location: Italy
pfranz 04 Dec 2014, 21:21
Yes, the problem is still there also with the latest version
The example is big but I pointed out where the problem is and how to solve it, so it should be easy to deal with it. Just uncompress it and run the batch file.
I haven't tried with other situations.
Post 04 Dec 2014, 21:21
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20363
Location: In your JS exploiting you and your system
revolution 04 Dec 2014, 21:26
Maybe you could just post the offending line 346 here? I'd much rather that than have to download a file, make a folder, uncompress, open a console, run a command etc.
Post 04 Dec 2014, 21:26
View user's profile Send private message Visit poster's website Reply with quote
pfranz



Joined: 13 Jan 2007
Posts: 116
Location: Italy
pfranz 04 Dec 2014, 21:31
Here it is, it's C code (that's why is inside and IF 0 block, is kind of documentation):

cfg |= (RTL_R32(RxConfig) & rtl_chip_info[tp->chipset].RxConfigMask); ff7e1880

I don't try constructing examples as the problem could be due to the big size of the program or to something somewhere else. Only Tomasz can tell ...
Post 04 Dec 2014, 21:31
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20363
Location: In your JS exploiting you and your system
revolution 04 Dec 2014, 21:39
What it appears to be is something similar to this:
Code:
if 0
x|=(&)
end if    
Which gives and "invalid expression" error. Is that what you get?
Post 04 Dec 2014, 21:39
View user's profile Send private message Visit poster's website Reply with quote
pfranz



Joined: 13 Jan 2007
Posts: 116
Location: Italy
pfranz 04 Dec 2014, 21:41
yes, "invalid expression" is the error
Post 04 Dec 2014, 21:41
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20363
Location: In your JS exploiting you and your system
revolution 04 Dec 2014, 21:46
Remember that fasm has a few different stages. preprocessor/parser/assembler. Each stage is separate. The "if 0" line is processed by the assembler, but the parser is evaluating the logical consistency of the following expression before the assembler has a chance to skip assembling the line. So the error will persist because the parser has no knowledge that the line will never be assembled.
Post 04 Dec 2014, 21:46
View user's profile Send private message Visit poster's website Reply with quote
pfranz



Joined: 13 Jan 2007
Posts: 116
Location: Italy
pfranz 04 Dec 2014, 21:48
I believe "if 0" is processed by preprocessor. Anyway, in the old versions this problem was not present
Post 04 Dec 2014, 21:48
View user's profile Send private message Reply with quote
AsmGuru62



Joined: 28 Jan 2004
Posts: 1638
Location: Toronto, Canada
AsmGuru62 04 Dec 2014, 23:27
Strange, why not just comment the C code?
Post 04 Dec 2014, 23:27
View user's profile Send private message Send e-mail Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 05 Dec 2014, 12:18
Correction uploaded as 1.71.29 release.
Post 05 Dec 2014, 12:18
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc 05 Dec 2014, 13:00
A fix is good, but I suppose, there's a need in a bit of clarification.

pfranz
It's still not like you are allowed to put arbitrary things into an "if 0" block.
Quote:
I believe "if 0" is processed by preprocessor.

No it's not. It's handled by the assembler. That's why the following code will still fail to compile:
Code:
macro x {}
if 0 
x|=(&) 
end if    


A colon at the beginning of a line will fail to compile because of it's special handling as well:
Code:
if 0
:
end if    


For unclear reasons $% is an invalid name (contrary to %$) and for the same unclear reasons the following also fails to compile:
Code:
if 0
$%
end if    

_________________
Faith is a superposition of knowledge and fallacy
Post 05 Dec 2014, 13:00
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 05 Dec 2014, 13:17
l_inc wrote:
A fix is good, but I suppose, there's a need in a bit of clarification.
Thank you for this, I endorse everything you've written here.

l_inc wrote:
For unclear reasons $% is an invalid name (contrary to %$) ...
Names starting with "$" (and having at least one additional character) are currently always treated as numbers (the same way as ones starting with digit), hence the "invalid name" error.
Post 05 Dec 2014, 13:17
View user's profile Send private message Visit poster's website Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc 05 Dec 2014, 13:48
Tomasz Grysztar
Quote:
Names starting with "$" (and having at least one additional character) are currently always treated as numbers

Oh, sure. Thanks. I could have though about this.

P.S. Still I'm unable to explain it failing the compilation in an "if 0" block. It should be of no interest for the preprocessor. Is it the following parsing stage, that fails it? But aren't you aiming the parsing stage to be inseparable/indistinguishable from the assembly stage?

_________________
Faith is a superposition of knowledge and fallacy
Post 05 Dec 2014, 13:48
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland
Tomasz Grysztar 05 Dec 2014, 14:19
l_inc wrote:
P.S. Still I'm unable to explain it failing the compilation in an "if 0" block. It should be of no interest for the preprocessor. Is it the following parsing stage, that fails it? But aren't you aiming the parsing stage to be inseparable/indistinguishable from the assembly stage?
Yes, this one could be improved, too. But it's not such an immediate fix as the above one, I would need to think about it a bit.
Post 05 Dec 2014, 14:19
View user's profile Send private message Visit poster's website Reply with quote
pfranz



Joined: 13 Jan 2007
Posts: 116
Location: Italy
pfranz 05 Dec 2014, 17:52
Thanks, now it works. I forgot that here IF is an assembler directive, I was used to other compilers where it's a preprocessor one. Maybe MATCH is the one?
Post 05 Dec 2014, 17:52
View user's profile Send private message Reply with quote
l_inc



Joined: 23 Oct 2009
Posts: 881
l_inc 06 Dec 2014, 00:47
pfranz
Quote:
Maybe MATCH is the one?

match is a preprocessor directive that could allow you to skip some source code locations (except for the implications of the fix directive). But it's important to remember that the closing brace character ends the scope of macroblocks. The braces are too common for the C code, which makes macroblocks (including match) not well suitable for skipping C code processing.

The best way to comment out the C code is (surprise-surprise!) to use comments.

_________________
Faith is a superposition of knowledge and fallacy
Post 06 Dec 2014, 00: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 07 Dec 2014, 13:20
Tomasz Grysztar wrote:
l_inc wrote:
P.S. Still I'm unable to explain it failing the compilation in an "if 0" block. It should be of no interest for the preprocessor. Is it the following parsing stage, that fails it? But aren't you aiming the parsing stage to be inseparable/indistinguishable from the assembly stage?
Yes, this one could be improved, too. But it's not such an immediate fix as the above one, I would need to think about it a bit.
The bug was actually in the other place than I thought, a forgotten piece of code that was very outdated. I'm fixing it with the 1.71.30 release.
Post 07 Dec 2014, 13:20
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.