Devpac 3: can I unwrap a loop that contains labels

[doggyfred]

Here is some pseudo-code I'd like to unwrap:

MOVE.W #15,D0
doit:
CMP.W #0,D1
BNE .skip
NOP ; (some useful code here)
.skip
DBF D0,doit

Can the macro processor in devpac automatically put an index
at the end of the labels so that I can do something like this ?

REPT 16
CMP.W #0,D1
BNE .skip
NOP ; (some useful code here)
.skip
ENDR

The problem I have at this time is that the ".skip" label is duplicated
16 times. Is there any way I can tell devpac to replace ".skip" with
".skip01", ".skip02", .... "skip16" ?

doggyfred

[unseenmenace]

If you know the size of the branch then you should be able to use an offset in the branch command rather than a label and then the Repeat directive will work properly.

[doggyfred]

Ah, I never thought about that. Will do. Thanks, unseenmenace.

[ijor]

If you know the size of the branch then you should be able to use an offset in the branch command rather than a label and then the Repeat directive will work properly.

This is not a good idea. You will need to change the offset each time you make changes in the code. And you might forget and your program might crash without knowing why. Or you might change optimization options in the assembler and the offset might also change.

Devpac has a solution for generating unique labels automatically, using the "\@" syntax. It doesn't work for REPT blocks, but it does for macros. So just put the code to be repeated in a macro:

Code: Select all

yourmacro  macro
    bne .skip\@
    nop
.skip\@
     endm

    rept 16
    yourmacro
    endr

The \@ is replaced with a different number on each macro invocations. So the labels are unique.

[unseenmenace]

I never knew about that Could be rather handy that

[doggyfred]

There! I was pretty sure there was a way to do it, but I couldn't find
any code sample. Nice!

[Zorro 2]

Here is some pseudo-code I'd like to unwrap:
MOVE.W #15,D0
doit:
CMP.W #0,D1
BNE .skip
NOP ; (some useful code here)
.skip
DBF D0,doit

Hi mister doggyfred,

When I see the source on the top, I demand myself if the code seems right like that ?

Code: Select all

	MOVE.W #15,D0
doit:
	CMP.W #0,D1
	BNE .skip
	NOP ; (some useful code here)
	bra .exit
.skip:
	sub.w	#1,d0
	bra	doit 
.exit:	

[Zorro 2]

Well, I think too much on this little code and I propose to you (mister doggy), 2 other things :

1- Call label procedure :

Code: Select all

sample:
	rept	16
	bsr	my_proc
	endr

end:
	clr.w     -(a7)
	trap      #1
	
my_proc:
	CMP.W #0,D1
	BNE .skip
	NOP ; (some useful code here)
.skip:
	rts

2- memory/stack storage access :

Code: Select all

	text
	
init:
	lea code,a0
	move.w	#$B27C,(a0)+	*	CMP.W #0,D1
	move.w	#$0000,(a0)+	*	adr/offset
	move.w	#$6600,(a0)+	*	BNE	skip
	move.w	#$0004,(a0)+	*	adr/offset
	move.w	#$4E71,(a0)+	*	nop
	move.w	#$4E75,(a0)		*	skip	:	rts

sample:

	rept	16
	bsr	code
	endr

end:
	clr.w     -(a7)
	trap      #1
		
	bss
	
code:	ds.w	6
								
	end	

Maybe I'm wrong !?!

[doggyfred]

Hi Zorro 2,

Your code:

Code: Select all

sample:
  rept   16
  bsr  my_proc
  endr

end:
  clr.w   -(a7)
  trap   #1
  
my_proc:
  CMP.W #0,D1
  BNE .skip
  NOP ; (some useful code here)
.skip:
  rts

That snippet does pretty much the same thing as my pseudo-code,
however you have 16 BSR in there, which is cycle consuming (use of
the stack in a sub call). I was looking to unwrap my loop to optimize speed.
The solution involving a macro is perfect in that regard.

Thanks,
Doggyfred

[Zorro 2]

I understand better, BSR takes 18 cycles of course

[ggn]

Hi Zorro 2,

Your code:

Code: Select all

sample:
  rept   16
  bsr  my_proc
  endr

end:
  clr.w   -(a7)
  trap   #1
  
my_proc:
  CMP.W #0,D1
  BNE .skip
  NOP ; (some useful code here)
.skip:
  rts

That snippet does pretty much the same thing as my pseudo-code,
however you have 16 BSR in there, which is cycle consuming (use of
the stack in a sub call). I was looking to unwrap my loop to optimize speed.
The solution involving a macro is perfect in that regard.

Thanks,
Doggyfred

You could use a code generator too:

Code: Select all

lea doit(pc),a1
moveq #15,d1
copyloop:
lea code,a0
move.w #(skip-code)/2-1,d0
copyloop2:
move.w (a0)+,(a1)+
dbra d0,copyloop2
dbra d1,copyloop

....

doit: ds.b (skip-code)*16

....

code:
CMP.W #0,D1 
BNE skip 
NOP ; (some useful code here) 
skip:

And this ensures that your routine between 'code' and 'skip' will be copied 16 times. A bit more messy that macros, but Turbo Assembler doesn't contain any macros

George

[Zorro 2]

You could use a code generator too:

Code: Select all

lea doit(pc),a1
moveq #15,d1
copyloop:
lea code,a0
move.w #(skip-code)/2-1,d0
copyloop2:
move.w (a0)+,(a1)+
dbra d0,copyloop2
dbra d1,copyloop

....

doit: ds.b (skip-code)*16

....

code:
CMP.W #0,D1 
BNE skip 
NOP ; (some useful code here) 
skip:

And this ensures that your routine between 'code' and 'skip' will be copied 16 times. A bit more messy that macros, but Turbo Assembler doesn't contain any macros

George

Yep mister George, it much easier to use your code that mine !

[ijor]

A bit more messy that macros, but Turbo Assembler doesn't contain any macros

Hmm, then why not better switch to a different assembler?

What is special about Turbo assembler? Not arguing, just asking. Never used Turbo assembler.

[ggn]

ijor,

Just a few points I can think of now are:

- Uses custom display routines ==> much faster than GEM
- Assembling each line when you press ENTER + syntax checking (much faster assembly times)
- "Foldable" parts (like GFA BASIC - define multiple blocks which you can hide and unhide, so they won't get in your way)
- Jump to label
- Symbol find/replace (much better than doing text find/replace)
- Badass debugger (Bugaboo)
Just for the debugger I could write a small novel! Needles to say that it's reset proof, doesn't use GEM at all, has its own custom mouse driver, it has a hybrid cli/hotkey enviroment, inline assembly etc, etc, etc

Of course, if you want macros, 'INCLUDE's, 030 compatiblilty (although tSCc have done that), and some other stuff, then yeah, go for Devpac. Just don't expect me to do that.

George

[simonsunnyboy]

I actually only miss the INCLUDEs in Turbo Assembler.

One cool feature: TA can directly assemble your code to a GFA inline without the unneeded header. Very handy!

[ijor]

Just a few points I can think of now are:

Interesting. But you don't mention any actual assembler feature. They are all Editor features, plus the debugger. But the assembler is one thing and the editor is other (There are very good assembler without editor). I normally use Devpac assembler, but I rarely use Devpac editor. Actually, nowadays, I assemble/compiler under Steem and use my favorite Windows editor.

The debugger looks interesting. Can you (or somebody else) make a quick comparison with Monst?

then yeah, go for Devpac. Just don't expect me to do that.

Of course not. I should have added a smiley on my previous post. We are just chatting. After all, personal preferences matter a lot in these issues.

Personally, I would consider lack of Include and Macro support, as very severe limitations for large projects. Strange that a package with such a powerful debugger and editor has a non-macro assembler.

[ggn]

Just a few points I can think of now are:

Interesting. But you don't mention any actual assembler feature. They are all Editor features, plus the debugger. But the assembler is one thing and the editor is other (There are very good assembler without editor). I normally use Devpac assembler, but I rarely use Devpac editor. Actually, nowadays, I assemble/compiler under Steem and use my favorite Windows editor.

Well, the editor pays a major role for me, and even more in the past, where I only had a STE with a floppy. I wanted an intergrated package where I could code, assemble, run, debug and do it all over again in no time. Loading up program after program to do that tires me a lot. That's why I emphasize on the Editor part.

The assembler assembles pretty much everything you throw at it, except that it needs a ';' or a '*' for comments (so pressing one tab and writing comments after the code - as SO many people who use devpac do - will yield an error) and it has a small incombatibility with conditional assembly (no ELSE handling). And of course, no macros

The debugger looks interesting. Can you (or somebody else) make a quick comparison with Monst?

Well, I don't dare compare it with plain monst. It's just unfair. Bugaboo can recover from very severe crashes. I remember once setting a breakpoint inside an interrupt and then the program crashed after tracing a couple of instructions. Bugaboo didn't break a sweat though and I was allowed to exit back to the editor without losing any data. Another extreme experiment I once did is tracing through a running program with a STF module playing. When you are at Bugaboo's gui everything is frozen (gem, interrupts, everything except hardware registers - then it would have STEem's abilities ). So whenever I pressed F1 to trace an instruction I could hear the module playing briefly, then freezing again, untill I pressed F1 again! That's what I call 'robust' Another cool feature is that you can execute any instruction on the spot, without hex editing or changing PC or affecting SR! Wanna change the background color? Just type |move.w #$fff,$8240.w and you're done . It also has a back history, and the bonus is that you can for example go back two steps in the code and execute it again (a la VCR ). Finally (I could go on for hours you know ), it has some powerfull conditional breakpoints. Example: b0=^a0+30,?d0=1 will set a breakpoint at address at a0+30 and will stop ONLY when D0=1!!!

then yeah, go for Devpac. Just don't expect me to do that.

Of course not. I should have added a smiley on my previous post. We are just chatting. After all, personal preferences matter a lot in these issues.
[/quote]

I should have added a smiley too. Also just chatting. I sorry if I sounded too hostile.

Personally, I would consider lack of Include and Macro support, as very severe limitations for large projects. Strange that a package with such a powerful debugger and editor has a non-macro assembler.

There is a simple explanation for this. Macros and just-in-time assembly don't mix too well

Regards, George

[tobe]

Using Devpac, it is possible to use REPT and SET to generate incremental labels or constants ?

[herrv]

yes my dear
this was the way i used when i didn't know the "@" option