REPT directive in vasm

[phx]

I'm thinking about rewriting the REPT directive and I'm interested in your opinion about it.

Currently REPT works on the parser level in vasm. This has the advantage that you can put absolutely everything between REPT and ENDR. The disadvantage is that the number of repetitions must evaluate as a constant in the first pass (label1-label2 is not a constant here).

Devpac allows REPT with label1-label2, as long as these labels are defined on top of the directive.

With some effort I could make any variable expression work with REPT (even when defined after the repeat-block). But the disadvantage would be that the repeat-blocks could no longer cross section boundaries. For example this would become impossible, which currently works:

        rept    10
        code
        move.b  (a0)+,(a1)+
        data
        dc.b    1,2,3,4
        endr

Do you think it would be an improvement?

[Leffmann]

I've never needed either of the two cases, but being able to do "label1-label2" seems to me like it could be more useful, whereas the latter case with section statements less so and seems very rare, so I think it would be an improvement.

[phx]

Ok, thanks. So I should work on this improvement now.

[Apollo]

Never had a case where I had to put a 'section' statement between REPT/ENDR. I see an advantage in having label arithmetic between REPT/ENDR blocks.

[phx]

Ok. After several days of work I have to admit that I failed. My new idea didn't cover all the functioniality of the current implementation.

This works nicely now:

        rept    end-start
        bsr     start
        endr

start   move.l  #0,d0
end     rts

Although the labels are defined after the rept directive and the distance changes due to an optimization to moveq.

But the price is too high. Changing symbols with SET or accessing the next macro macro argument with \+ no longer works correctly inside a rept-block. So the following code would generates four bytes with 1:

x       set     0
        rept    4
x       set     x+1
        dc.b    x
        endr

This is impossible to fix with my new approach, as rept no longer works on the parser-level, so I reverted all my changes. Back to V1.7a.

[Apollo]

anyway, thanks for your efforts

[Photon]

(Side note: Second example is missing the first letter which should be x. Right?)

You do need this set thing, so supporting that is the right thing to do, even if there's a @\ variable (in Asm-One). I don't know how many assemblers support it, but it returns the string "0000" the first time, "0001" the second time, and so on (16 bit counter, hex format so you can put "$" before it and use for calculations).

Check so that local variables (.x) works with set in REPT. At least I always use local variables for my REPT statements.

[phx]

Originally Posted by Photon

(Side note: Second example is missing the first letter which should be x. Right?)

Correct. I fixed that. Thanks.

You do need this set thing, so supporting that is the right thing to do,

Yes. It is much more frequent in source texts than using the difference between two labels as repeat-count.

even if there's a @\ variable (in Asm-One). I don't know how many assemblers support it

Nearly all of them do (but it's usually written as "\@").

but it returns the string "0000" the first time, "0001" the second time, and so on (16 bit counter, hex format so you can put "$" before it and use for calculations).

A hex-notation for that is rather unusual. The assemblers I checked count decimal. \@ is replaced by:
Devpac: _001 .. _999
PhxAss: _0001 .. _9999
vasm: _000001 .. _999999
Barfly: _0001 .. _9999

All of them precede the string by an underscore, which allows using \@ directly as a label.

Check so that local variables (.x) works with set in REPT.

They do.

[Photon]

Correction: Asm-One's \@ starts counting at 0001. I was at work, so I was unable to check.

Also, it seems only version 1.02+ corrected the reverse digits order. Asm-One 1.20 has limited support, reverse digits, only for labels and PRINTV (inside quotes, no less!) and then it gets unsupported for anything but labels upto latest AsmPro...

So I guess having a f* counter but not supporting it for anything but labels was the way of the future.

Anyway, here's a test macro if anyone wants to report some Asm-One version that does support it properly like 1.02+:

ROCKETSCIENCE:	MACRO
	dc.w $\@
	ENDM
	
ITSNOT:
	REPT 42
	ROCKETSCIENCE
	ENDR

Don't forget to also support the \@/ directive which outputs a cheerful message to keep the coder enthused about his creation.