Hi Tomasz,

I have symbols like this:


MOV P32 [SIGNAL.TYPE],.MSG.NOTMAPPED
.._IMPORT_SIGNAL_051 = $-8

MOV P32 [SIGNAL.CNT],ECX
.._IMPORT_SIGNAL_063 = $-4

When I have few tens of such symbols (differing only in the terminating part), FAsm says:

---

flat assembler version 1.39
error: code cannot be generated.

---

After some experimenting, I found this even more weird fix:



MOV P32 [SIGNAL.TYPE],.MSG.NOTMAPPED
.._IMPORT_SIGNAL_051 = $-8
.._IMPORT_SIGNAL_051 = .._IMPORT_SIGNAL_051

MOV P32 [SIGNAL.CNT],ECX
.._IMPORT_SIGNAL_063 = $-4
.._IMPORT_SIGNAL_063 = .._IMPORT_SIGNAL_063


---

Q1: Will the above produce correct code at least?
Q2: Is there a real fix for this problem?

---

PS: I played a bit more and found the error: there's a limit ( = 100 ) in the maximum number of passes of ASSEMBLE.INC. I increased it to 255 (because it's stored in a byte.. I didn't remove the limit check code because the variable is referenced elsewhere, so it may not work anyway) and reassembled the FAsm source.

Tomasz: it appears unnecessary to add passes for things like the above.. as also proven by the fix of the extra "symbol = symbol" solution. Nor it would be wise to limit the maximum number of *practically* usable symbols. I can imagine that equ may require additional passes in such cases.. but "=" should really not, in my understanding of how FAsm internally works.

Please don't limit FAsm in such ways.

Greets,
Fabio
Posted on 2002-08-06 11:51:44 by Maverick
Like it is stated in my new docs, when the constant is defined (using the = operator) only once, it can be accessed anywhere in source (it means that forward references are allowed). Because of it, when in the later passes fasm founds this constant is defined with different value than in previous pass, it is forced to do one more pass, because this constant may have been used previously and therefore that code should be generated once again. When the size of code changes, the value of $ in your constant definitions changes and it may cause them to force the next pass. I don't know what exactly caused the problem in your sources. Could you reproduce the error with minimum possible source and send it to me?
Posted on 2002-08-06 13:30:28 by Tomasz Grysztar


; PROBLEM = additional, unnecessary passes are created

FORMAT COFF ; omitting this removes the problem (but omits also required functionality)

..SYMBOL1 = $+0 ; these symbols if placed here don't cause the problem
..SYMBOL2 = $+0
..SYMBOL3 = $+0
..SYMBOL4 = $+0

DD ANYLABEL

..SYMBOL5 = $+0 ; the symbols, placed here, cause the problem
..SYMBOL6 = $+0
..SYMBOL7 = $+0

ANYLABEL:

..SYMBOL8 = $+0 ; the symbols, placed here, cause the problem
..SYMBOL9 = $+0

;ANYLABEL: could be here as well, nothing changes

..SYMBOL10 = $+0 ; the symbols, placed here, cause the problem
..SYMBOL11 = $+0

..SYMBOL12 = $+0
..SYMBOL12 = ..SYMBOL12 ; this fixes the problem for a single symbol

..SYMBOL13 = $+0
..SYMBOL14 = $+0

..SYMBOL15 = $ ; this doesn't cause the problem although is equivalent to $+0

..SYMBOL16 = $+0
..SYMBOL17 = $+0

;ANYLABEL: could be here as well, nothing changes

..SYMBOL18 = $+0
..SYMBOL19 = $+0

;ANYLABEL: could be here as well, nothing changes

;In substance the n additional passes are created in the same quantity as the
;number of "=" statements after the DD statement that forward-references ANYLABEL.
;
;Weirdly, if instead of $+0 I use just $, the problem (additional passes) don't
;appear. Also if after the lines with "xxx = $+0" (where +0 can be anything else,
;of course) I add a simple "xxx = xxx" the additional pass won't be generated.
Posted on 2002-08-07 04:06:46 by Maverick
Now I see! Yes, it was a bug hidden in the routine for adding values, occuring in rare situation, but your code caused exactly that rare situation. It's now fixed (1.40 beta 5). Thanks for the bug-report!
Posted on 2002-08-07 05:01:22 by Tomasz Grysztar
Hi Tomasz,

Now I see! Yes, it was a bug hidden in the routine for adding values, occuring in rare situation, but your code caused exactly that rare situation. It's now fixed (1.40 beta 5). Thanks for the bug-report!
You're wellcome, I'm always glad to support FAsm in any possible way, and I'd do more if I only had the time.
Posted on 2002-08-07 10:32:11 by Maverick
Tested FAsm 1.40b5.. now my sources don't even assemble anymore :(


flat assembler version 1.40 beta 5
t.asm [5]:
REPEAT 3-(($-mylabel+3) and 3)
error: invalid use of symbol.


---

Minimum test source:



FORMAT COFF

mylabel: DD mylabel.e-mylabel
REPEAT 3-(($-mylabel+3) and 3)
DB 0
END REPEAT
.e:
Posted on 2002-08-07 10:52:43 by Maverick
I just downloaded beta 5, and I also experience errors:
when compiling a file (it includes antoher file at the end of the file)


D:\FASM\FASM.exe \test\dt0.asm \test\dt0.bin [enter]
flat assembler version 1.40 beta 5


and nothing happens, when pressing crtl-c (or ctrl-break) and when i look in the dir where the output file is located the file is much larger (old 1kB -> new ~11 kB) than it was when I compiled it with beta 4. The output format is the default (thus flat binary).
Posted on 2002-08-07 11:59:46 by scientica
My fault, I have made it too strict when removing that bug, please download it once again, now everything should work correctly.
scientica: If the error still occurs, please send me the source.
Posted on 2002-08-07 14:23:48 by Tomasz Grysztar
Privalov, after looking closer at my code I saw that the error.
When I compiled it with the updated version i got an "out of memory"-error after along time of compiling.
The code that caused the error is as follows:


if $ > 7C00h+512
display "Error! $ > 512",0Dh,0Ah
end if
times 7C00h+512-2-$ db 0
db 055h,0AAh ;the signature itself

And I rewrote it as follows and the compilation preccess take 0-secs (but I still have to shrink the code :) ).


if $ > 7C00h+512
display "SiMBoL: Error! $ > 512",0Dh,0Ah
[COLOR=green]else
times 7C00h+512-2-$ db 0
db 055h,0AAh ;the signature itself
end if[/COLOR]


BTW, Is there a command (to the compiler) that prints an error and then aborts the compilation process?
Posted on 2002-08-07 15:30:02 by scientica
Hi Privalov,
Now it assembles OK but, on most sources, it probably produces a different COFF structure because the COFF2REL utility you sent me time ago now crashes. :grin:

<EDIT>
I found that COFF2REL now crashes when there are no relocations, although it checks for this occurrence anyway. If you have a quick fix good, otherwise I'll rewrite the util by myself when I have some time (which is not soon).
</EDIT>
Posted on 2002-08-08 03:07:12 by Maverick
I fixed it by myself, don't worry.
Posted on 2002-08-08 04:33:45 by Maverick