flat assembler - DOS - FASM 1.71.58 - spurious errors (unknown regression)

Index > Compiler Internals > DOS - FASM 1.71.58 - spurious errors (unknown regression)

Author

Thread

rugxulo

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

rugxulo

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?

20 Dec 2016, 00:22

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 17716
Location: In your JS exploiting you and your system

revolution

Can you give sample code for us to assemble and test?

20 Dec 2016, 04:18

rugxulo

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

rugxulo

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.

21 Dec 2016, 13:53

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 17716
Location: In your JS exploiting you and your system

revolution

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.

21 Dec 2016, 14:49

Tomasz Grysztar

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

Tomasz Grysztar

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.

21 Dec 2016, 16:32

rugxulo

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

rugxulo

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 passes, 169 bytes.
[ FreeDOS ] G:\TONY>d2x 20816
00005150
[ FreeDOS ] G:\TONY>fasm inv-fasm.asm
flat assembler  version 1.71.57  (2734325 kilobytes memory)
4 passes, 9194 bytes.
[ FreeDOS ] G:\TONY>fasm fas17158\source\win32\fasm.asm fasmw32.exe
flat assembler  version 1.71.57  (2734325 kilobytes memory)
5 passes, 113664 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 passes, 169 bytes.
[ FreeDOS ] G:\TONY>d2x 20816
00005150
[ FreeDOS ] G:\TONY>fasmw32 inv-fasm.asm
flat assembler  version 1.71.58  (2097152 kilobytes memory)
4 passes, 9194 bytes.
[ FreeDOS ] G:\TONY>stubit fasmw32.exe >nul
[ FreeDOS ] G:\TONY>fasmw32 d2x.asm
flat assembler  version 1.71.58  (1048464 kilobytes memory)
2 passes, 169 bytes.
[ FreeDOS ] G:\TONY>d2x 20816
00005150
[ FreeDOS ] G:\TONY>fasmw32 inv-fasm.asm
flat assembler  version 1.71.58  (1048464 kilobytes memory)
4 passes, 9194 bytes.
[ FreeDOS ] G:\TONY>FAS17158\fasm d2x.asm
flat assembler  version 1.71.58  (2734325 kilobytes memory)
d2x.asm [22]:
macro MUL10 {
error: invalid 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
processed: LetterCounter DW 0
error: invalid size of operand.

13 Jan 2017, 20:19

Tomasz Grysztar

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

Tomasz Grysztar

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.

20 Jan 2017, 13:41

Tomasz Grysztar

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

Tomasz Grysztar

I think it should be fixed in 1.71.59. Please try it out.

20 Jan 2017, 14:49

comrade

Joined: 16 Jun 2003
Posts: 1137
Location: Russian Federation

comrade

What was the problem?

20 Jan 2017, 23:54

rugxulo

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

rugxulo

Tomasz Grysztar wrote:

I think it should be fixed in 1.71.59. Please try it out.

Yes, seems to work fine now. Thanks.

21 Jan 2017, 01:18

Tomasz Grysztar

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

Tomasz Grysztar

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.

21 Jan 2017, 13:27

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 17716
Location: In your JS exploiting you and your system

revolution

But why the unpredictable behaviour? Wouldn't it always still follow the same execution path?

21 Jan 2017, 13:40

Tomasz Grysztar

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

Tomasz Grysztar

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.

21 Jan 2017, 15:11

< 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