VASM: strange behaviour, quits with error 8

[buzzybee]

I am currently cleaning up portions of code within the RESHOOT PROXIMA 3 project. Strange things happen. For example, VASM compiles sourcecode perfectly fine when it looks like this:

    tst.b .wbclosed(pc)
    beq .reopenWB
    nop	; without this VASM quits. Wtf?
	CALLINTUITION OpenWorkBench
.reopenWB

But with this code ...

    tst.b .wbclosed(pc)
    beq .reopenWB
;    nop	; without this VASM quits. Wtf?
	CALLINTUITION OpenWorkBench
.reopenWB

... VASM quits after a few moments and prints this line:
fatal error 8: cannot resolve section <CODE>, maximum number of passes reached

Given code is just an example. I am having trouble reproducing the error, but it seems like the error happens if size of code is too small (?!) / behavour seems to be related to size of source / compiled code. Puzzled. Anyone got any idea what might happen here?

[buzzybee]

Ah, seems like the puzzle was solved. I had these lines in my startup-code

.VARS
	ALIGNLONG (align to 4-byte address)
.OldView	dc.l	0
.OldCop1	dc.l	0
.OldCop2	dc.l	0
.VBRptr		dc.l	0
...

... where I should have had those:

	ALIGNLONG (align to 4-byte address)
.VARS
.OldView	dc.l	0
.OldCop1	dc.l	0
.OldCop2	dc.l	0
.VBRptr		dc.l	0
...

Therefore, .VARS was at first only randomly aligned to .OldView etc., which is fatal as .VARS is referenced several times within startup-code like this

move.l sp,.Stack-.VARS(a5) ; save stack

I would have imagined VASM would still compile even the address of VARS is not aligned and not dividable by 4 (of course code would have crashed then), but hey ...

Should not code when I am too tired at night.

[phx]

Originally Posted by buzzybee

I would have imagined VASM would still compile even the address of VARS is not aligned and not dividable by 4

It would.

The problem here is that the combination of branch-optimizations and 32-bit alignments may get you into a situation which results in an endless oscillation of performing the optimization and having to revert it again. A special difficulty on the M68k is that a branch instruction has to become larger (Bcc.W) when the distance to the target becomes zero (even when only momentarily).

vasm has lots of strategies to deal with it. So usually it shouldn't happen, but with some weird code constructions it still seems to be possible.

I'm glad that you found the problem. Otherwise your last options would have been to set a fixed size for the branch or to disable optimizations in this area.