REPT in MACRO

[borchen]

when using AsmTwo, the following piece of code gives a '** Unexpected End of File' error during Pass 1:

WTF:    MACRO
    REPT    2
    dc.w    0
    ENDR
    ENDM

Main:    btst    #6,$bfe001
    bne.s    Main
    rts

Data:   
    dc.w    0
    dc.w    0

    REPT    2
    dc.w    0
    ENDR

    WTF

    dc.w    0
END

the problem is caused by the REPT 2 in the MACRO, when I replace it with REPT 1 all is fine.

Does any MACRO-guru have a clue why this is not working?

[adolfo.pa]

Originally Posted by borchen

when using AsmTwo, the following piece of code gives a '** Unexpected End of File' error during Pass 1:

WTF:    MACRO
    REPT    2
    dc.w    0
    ENDR
    ENDM

Main:    btst    #6,$bfe001
    bne.s    Main
    rts

Data:   
    dc.w    0
    dc.w    0

    REPT    2
    dc.w    0
    ENDR

    WTF

    dc.w    0
END

the problem is caused by the REPT 2 in the MACRO, when I replace it with REPT 1 all is fine.

Does any MACRO-guru have a clue why this is not working?

I'm definitely not a macro guru, but I think this is a bug. Also, I've noticed something very weird here. Try the following:

- Assemble your source as is. I get an "Unexpected EOF" pointing after the 'end' keyword.
- Add a comment to the dc.w 0 inside the rept block (e.g. 'dc.w 0 ; foo'). I get the same error.
- Remove the comment and assemble again. Note the error is slightly different (in my case there are two 'end' keywords)

If I repeat the 'comment/assemble/remove comment' at different places (e.g. in the 'wtf' macro call, in between it and the end, etc.) I get different error messages which refer to things that no longer exist in the source.

For example, if I add a '; foo' comment after the 'wtf' call and assemble I get an error message that does not include 'foo'. Now, I remove the comment, save the file and assemble, and the error message display the contents of the comment!.

So, it looks like that using rept inside a macro definition causes some piece of code to reach for data that is out of bounds in some buffer (this would explain why data from a previous assembly shows up there).

@Photon, I believe you are the author of AsmTwo, so maybe you can confirm if this is really a bug?

Thanks!

EDIT: I have no idea how to mention a user here :-( Using '@' doesn't seem to work? Let's hope Photon sees this message anyway

[borchen]

@adolfo.pa: thanks for confirming this (bug?)

Here's a slightly modified version to show what is going wrong:

WTF:	MACRO
	REPT	\1
	dc.w	0
	ENDR
	ENDM

Main:	btst	#6,$bfe001
	bne.s	Main
	rts

Data:	dc.w	0
	dc.w	0

	REPT	2		; no problemo
	dc.w	0		;
	ENDR			;

	WTF	1		; works fine
	WTF	2		; ** Unexpected End of File
				; armageddon starts now!
	dc.w	0
END

Time to fetch my searchlight with the Scoopex-logo attached to it and point it at the clouds and let's hope @Photon sees it.

[StingRay]

This seems to be an AsmTwo problem, your macro is fine.

[Galahad/FLT]

Try pressing RETURN so that MACRO and WTF: are not on the same line.

And your END statment is wrong, thats for signifying end of the source, try ENDM

[StingRay]

Originally Posted by Galahad/FLT

Try pressing RETURN so that MACRO and WTF: are not on the same line.

Must be on the same line!

Originally Posted by Galahad/FLT

And your END statment is wrong, thats for signifying end of the source, try ENDM

It's not wrong, it's added automatically by AsmOne/Two etc. And he has properly terminated the macro with ENDM.

[Galahad/FLT]

Originally Posted by StingRay

Must be on the same line!



It's not wrong, it's added automatically by AsmOne/Two etc. And he has properly terminated the macro with ENDM.

How the fuck did i not see that?

Does ASMone/Two not like REPT macros within a macro?

[borchen]

Does ASMone/Two not like REPT macros within a macro?

A 'REPT 1' works fine inside the WTF:MACRO

This problem also occurs with ASM-One v1.20; I just tested this.

I get the same error when putting the ENDR in the WTF:MACRO in comment, e.g.

; ENDR

and calling the MACRO with 'WTF 1'

It appears the REPT inside a MACRO is not properly terminated (the ENDR is gone?) when using it with a higher value than '1'.

[LaBodilsen]

Originally Posted by borchen

@adolfo.pa: thanks for confirming this (bug?)

Here's a slightly modified version to show what is going wrong:

WTF:	MACRO
	REPT	\1
	dc.w	0
	ENDR
	ENDM

Main:	btst	#6,$bfe001
	bne.s	Main
	rts

Data:	dc.w	0
	dc.w	0

	REPT	2		; no problemo
	dc.w	0		;
	ENDR			;

	WTF	1		; works fine
	WTF	2		; ** Unexpected End of File
				; armageddon starts now!
	dc.w	0
END

Time to fetch my searchlight with the Scoopex-logo attached to it and point it at the clouds and let's hope @Photon sees it.

As others have confirmed, this code works fine, i testet it in Asm-Pro V1.17, and no errors show. So it must be a AsmTwo problem.

[Photon]

I have been very wary about changing the assembly core stolen from Seka.

In fact, it's 100% the same, and therefore, bugs that were there (and continued also to much later versions by others) are there. AsmTwo is in a way starting over, and not because older is better but because older is smaller. It's targeted to be able to code a whole A500 demo on an A500 1.3 with 512k slowmem and up.

[StingRay]

Originally Posted by Galahad/FLT

Does ASMone/Two not like REPT macros within a macro?

At least older versions of ASM-One apparently have problems with REPT inside a macro. It works without problem in ASM-Pro V1.16d for example.


Workaround for this particular case:

WTF:    MACRO

    dcb.w \1,0
    ENDM

Main:    btst    #6,$bfe001
    bne.s    Main
    rts

Data:   
    dc.w    0
    dc.w    0

    REPT    2
    dc.w    0
    ENDR

    WTF 2

    dc.w    0

This should work as expected. And if any other value than 0 is required a second parameter for the macro could be added, e.g. WTF 2,16384.

[borchen]

@StingRay

Thanks for the solution, but this particular case is not the original case...
It's a simplified example, just to show the REPT-inside-a-MACRO bug in AsmOne/Two.

The real case was this:

SETF	MACRO
	IFEQ	NARG-2
.O	SET	0
	ENDC
.O2	SET	.O
	REPT	\1-1
	dc.w	.O2*4,(.O2+1)*4
.O2	SET	.O2+1
	ENDR
	dc.w	.O2*4,.O*4
.O	SET	.O+\1
	ENDM

; o - 8+4
	SETF	8,"STING POWAH"
	SETF	4

; r - 12+4
	SETF	12
	SETF	4

; a - 10+4
	SETF	10
	SETF	4

; c - 16
	SETF	16

; l - 7
	SETF	7

; e - 14
	SETF	14

This is part of an intro/crack made by demogroup Oracle for the game Arachnophobia, which I just tried to get running.

I had to strip out a lot of code and recompile it many times to finally find what was causing this annoying problem...which I solved by replacing the SETF calls with the content of the MACRO and replacing the \1 with the numbers after the SETF; basically reversing the usage of the MACRO.

The intro now compiles fine and runs!

Thanks for all the time you guys put into this. This is a forum with people that actually know their stuff...which is refreshing.

[StingRay]

; o - 8+4
	SETF	8,"STING POWAH"
	SETF	4

Haha, now this made me giggle. Guess who's the one responsible for your macro problems.

The source was made with ASM-Pro V1.16d, it can be assembled (!, not compiled :P) without any problems with that assembler. Any particular reason you are using AsmTwo for that?

[borchen]

Haha, now this made me giggle. Guess who's the one responsible for your macro problems.

No way. You must be kidding! Talk about coincidence

Any particular reason you are using AsmTwo for that?

Yes: [ Show youtube player ]

[!ZAJC!]

Just hit this same bug in the following assemblers:

• Asm-One v1.02
• Asm-One v1.49-rc2
• AsmTwo

Confirmed working:

• Trash'm-One v1.7
• Asm-Pro v1.20c

[Photon]

It was fixed somewhere in between Asm-One 1.20 and 1.49RC2. Had a look, but nothing had changed in AsmPro 1.17 in any relevant code portion.

A clue is that if you type as many ENDR as the REPT count (e.g. REPT2;ENDR;ENDR), it assembles but only generates the contents once. IOW it doesn't decrement the ENDR until 0, but keeps searching for ENDR until end of source.

For now, the workaround is

WTF:	MACRO
	dc.w 0
	ENDM

Data:
count:	SET 5
	REPT count
	WTF
	ENDR

I.e. put your dynamic count in a variable instead, and only the stuff inside the (previous) REPT in the macro definition, and put the REPT outside the macro invocation.

My tutorial series doesn't use REPT inside macros as far as I'm aware.

[a/b]

Did some poking, it looks like this is the problem...
ASSEM_CMDREPT:
...
move.l 12(A7),(A0)+

ASSEM_CMDENDR:
...
move.l (A0),12(A7)

Both of these should be 16. There is an extra longword on the stack that has to be skipped, so that the REPT/ENDR handlers get the correct macro source line. Went through with debugger and that pointer seemed strange (it pointed to source line, not macro source line), changed them to 16 and hoped for the best. It went through, no crash and produced output was correct.

[Photon]

Originally Posted by a/b

Did some poking, it looks like this is the problem...
ASSEM_CMDREPT:
...
move.l 12(A7),(A0)+

ASSEM_CMDENDR:
...
move.l (A0),12(A7)

Both of these should be 16. There is an extra longword on the stack that has to be skipped, so that the REPT/ENDR handlers get the correct macro source line. Went through with debugger and that pointer seemed strange (it pointed to source line, not macro source line), changed them to 16 and hoped for the best. It went through, no crash and produced output was correct.

Cheers, I looked at these specific lines, but I also noticed that the REPT_STACK had increased to 14 per stack item instead of 12, and there was another offset reference into it that had also increased, so I wasn't sure. Perhaps the last one was only for handling REPT 0, but I couldn't discern this with certainty.