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 > DOS - FASM 1.71.58 - spurious errors (unknown regression)

Author
Thread Post new topic Reply to topic
rugxulo



Joined: 09 Aug 2005
Posts: 2112
Location: Usono (aka, USA)
DOS - FASM 1.71.58 - spurious errors (unknown regression)
I hadn't bothered to test latest FASM (1.71.58) until now. I had assumed everything was fine, but the DOS version is giving me false errors (while 1.71.57 works fine). Also, FASMD seems to assemble correctly whereas the normal cmdline .EXE does not. I didn't bother to diff the two to isolate the problem, but of course I felt it was important to mention anyways. I'm not sure what's wrong, internal memory error?
Post 20 Dec 2016, 00:22
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14789
Location: Lost in translation
Can you give sample code for us to assemble and test?
Post 20 Dec 2016, 04:18
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2112
Location: Usono (aka, USA)
This is not code specific, it's seemingly getting confused about perfectly valid code that used to assemble with no errors. But now it's giving false errors, even in the simplest of macros, even in the simplest of data definitions (dw or dd). I don't know what else to tell you, it's a regression.
Post 21 Dec 2016, 13:53
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14789
Location: Lost in translation
Can you show some "perfectly valid code" that it gets "confused about". Your error report is very vague.

AFAICT no one else is seeing a problem.
Post 21 Dec 2016, 14:49
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


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

revolution wrote:

AFAICT no one else is seeing a problem.

The problem probably only occurs when unreal mode variant is used, and there are probably few people that use fasm in real mode DOS. I'm going to check it when I'm back at my own DOS machine.
Post 21 Dec 2016, 16:32
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2112
Location: Usono (aka, USA)
Sorry, I'm even more disorganized these days, and I also don't have any obvious code to test.

But here's an example:


Code:

FreeDOS ] G:\TONY>fasm d2x.asm
flat assembler  version 1.71.57  (2734325 kilobytes memory)
2 passes169 bytes.
FreeDOS ] G:\TONY>d2x 20816
00005150
FreeDOS ] G:\TONY>fasm inv-fasm.asm
flat assembler  version 1.71.57  (2734325 kilobytes memory)
4 passes9194 bytes.
FreeDOS ] G:\TONY>fasm fas17158\source\win32\fasm.asm fasmw32.exe
flat assembler  version 1.71.57  (2734325 kilobytes memory)
5 passes113664 bytes.
FreeDOS ] G:\TONY>pestub -q -n fasmw32.exe
FreeDOS ] G:\TONY>fasmw32 d2x.asm
flat assembler  version 1.71.58  (2097152 kilobytes memory)
2 passes169 bytes.
FreeDOS ] G:\TONY>d2x 20816
00005150
FreeDOS ] G:\TONY>fasmw32 inv-fasm.asm
flat assembler  version 1.71.58  (2097152 kilobytes memory)
4 passes9194 bytes.
FreeDOS ] G:\TONY>stubit fasmw32.exe >nul
FreeDOS ] G:\TONY>fasmw32 d2x.asm
flat assembler  version 1.71.58  (1048464 kilobytes memory)
2 passes169 bytes.
FreeDOS ] G:\TONY>d2x 20816
00005150
FreeDOS ] G:\TONY>fasmw32 inv-fasm.asm
flat assembler  version 1.71.58  (1048464 kilobytes memory)
4 passes9194 bytes.
FreeDOS ] G:\TONY>FAS17158\fasm d2x.asm
flat assembler  version 1.71.58  (2734325 kilobytes memory)
d2x.asm [22]:
macro MUL10 {
errorinvalid macro arguments.
FreeDOS ] G:\TONY>FAS17158\fasm inv-fasm.asm
flat assembler  version 1.71.58  (2734325 kilobytes memory)
inv-fasm.asm [492]:
LetterCounter           DW      0
processedLetterCounter DW 0
errorinvalid size of operand.


Post 13 Jan 2017, 20:19
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6355
Location: Kraków, Poland
I think I know what caused these problems. I'm going to make some additional tests on my DOS machine and the I'll upload the fix.
Post 20 Jan 2017, 13:41
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6355
Location: Kraków, Poland
I think it should be fixed in 1.71.59. Please try it out.
Post 20 Jan 2017, 14:49
View user's profile Send private message Visit poster's website Reply with quote
comrade



Joined: 16 Jun 2003
Posts: 1104
Location: Russian Federation
What was the problem?
Post 20 Jan 2017, 23:54
View user's profile Send private message Visit poster's website AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2112
Location: Usono (aka, USA)

Tomasz Grysztar wrote:
I think it should be fixed in 1.71.59. Please try it out.



Yes, seems to work fine now. Thanks.
Post 21 Jan 2017, 01:18
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


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

comrade wrote:
What was the problem?

Recently I got rid of the CALL/POP pairs that fasm's core sometimes used to get the EIP value (because they required special handling in 64-bit mode), and I forgot that I cannot just use "PUSH label" instead, since the unREAL version uses different segment bases for the preprocessor and assembler modules, so the value of EIP may be different from the value of label. This is why a position-independent code was needed there and I changed it back, but this time I made it in such way that there is always RET to clean up after CALL (therefore the special handling in 64-bit mode is no longer necessary). This may also improve the predictability of CALL/RET pairings on modern processors.
Post 21 Jan 2017, 13:27
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14789
Location: Lost in translation
But why the unpredictable behaviour? Wouldn't it always still follow the same execution path?
Post 21 Jan 2017, 13:40
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6355
Location: Kraków, Poland
It would always land in the same place in code, but the data pointed to by registers could differ, so I guess that's where the unpredictability came from.
Post 21 Jan 2017, 15:11
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-2016, Tomasz Grysztar.