68000 code optimisations

[pmc]

Thread title says it all really.

I'm interested in the quickest ways to do things on the 68000 processor.

I imagine that an optimisation that is valid for 68000 might not necessarily be valid for > 68000 processors but my main interest is in vanilla 68000 coding.

So, if you have any, please post them here.

In the meantime, some from me. Right hand operand(s) accomplish (according to my own testing, correct me if I'm wrong! ) the same as the left hand operand(s) only faster:

 
68000 code speed optimisations
------------------------------
 
clr.l     d0     -->     moveq.l     #0,d0
 
lsl.w     #1,d0  -->     add.w       d0,d0
 
lsl.w     #2,d0  -->     add.w       d0,d0
                         add.w       d0,d0
 
adda.w    #10,a0 -->     lea         10(a0),a0
 
moveq.l   #16,d0 -->     swap        d1
ror.l     d0,d1
 
moveq.l   #15,d0 -->     swap        d1
ror.l     d0,d1          rol.l       #1,d1

[phx]

I could add a longer list here, but you could also refer to
http://sun.hasenbraten.de/vasm/release/vasm.html
which shows most of vasm's optimizations in chapter 13.5.

[pmc]

Thanks phx - been reading those optimisations at that link you posted - nice!

So far I haven't used your VASM assembler (sorry about that ) but I have to say it looks pretty cool, might be time to change my old habits.

[Cosmos]

addq.l #,ax --> addq.w #,ax

b/jsr subroutine --> bra/jmp subroutine
rts

[phx]

Originally Posted by Cosmos

addq.l #,ax --> addq.w #,ax

Vasm is generally optimizing all instructions of the form "<op>.L #x,An" to "<op>.W #x,An". But I doubt that it makes a difference for ADDQ (I haven't checked the manual) ?

[pmc]

According to the manual:

addq.l #x,An = 8 clock cycles
addq.w #x,An = 4 clock cycles

[Toni Wilen]

Originally Posted by pmc

According to the manual:

addq.l #x,An = 8 clock cycles
addq.w #x,An = 4 clock cycles

It is wrong. (compare it with SUBAQ in same page). 68000/010 can't execute one instruction with two ALU operations in 4 cycles (ALU is only 16-bit and all address register operations are always full 32-bit)

[pmc]

Originally Posted by Toni Wilen

It is wrong.

OK, if anyone would know, it would be you.

Have you told Motorola their manual's wrong...?

[Galahad/FLT]

How about:

add.w d4,a0
move.l (a0),a1

as

move.l 0(a0,d4.w),a1

Also using the movem.l instruction to move lots of longwords in one instruction as opposed to a more processor intensive loop

[Cosmos]

... move.l 0(a0,d4.l),a1

[TheDarkCoder]

Originally Posted by Toni Wilen

It is wrong. (compare it with SUBAQ in same page). 68000/010 can't execute one instruction with two ALU operations in 4 cycles (ALU is only 16-bit and all address register operations are always full 32-bit)

I can confirm what Toni says. Finding suspicious the difference with SUBAQ, I mesured time spent by repeating a lot od ADDAQ and there is no difference between .w and .l
Also, I think that in the 68010 manual both are reported 8 cyles

[Toni Wilen]

"Undocumented un-optimization": bset x,dn (and friends) take 2 cycles more if x >= 16.

[Lonewolf10]

I heard that the movem instruction can be used to clear screens quickly. Is this true and how would it be done?


Regards,
Lonewolf10

[frank_b]

Originally Posted by Lonewolf10

I heard that the movem instruction can be used to clear screens quickly. Is this true and how would it be done?


Regards,
Lonewolf10

Set sp to the top of memory you want to clear.
Zero all registers and

rept lots of times
movem.l d0-a6,-(sp)
endr

For added fun switch to supervisor and use the usp too

[Galahad/FLT]

Originally Posted by Lonewolf10

I heard that the movem instruction can be used to clear screens quickly. Is this true and how would it be done?


Regards,
Lonewolf10

Used in the early days of Amiga, and used extensively on the Atari ST.

[frank_b]

and.w #power of 2-1,d0

A quick way to get the remainder on a power of two div

      move.w x,d0
      and.w   #$f,d0   ; blitter shift value

It's a tad faster than a div.

       move.b  d0,-(sp)
       move.w (sp)+,d0  ; magic fast shift :)

Reduce system call overhead (not really relevant on the Amiga but cool on the ST)
If you call functions and pass params via the stack might be useful.

       move.w #something,-(sp)
       trap      #x


       move.w  #some other param,-(sp)
       trap       #x

       addq.l      #4,sp   ; clean up both params at once

Absolute short addressing to set ST IO registers. Don't try this on anything other than a vanilla 68k

      move.w    #val,$ffff8240.w

Relying on the cpu flags to avoid a compare

      move.l   somevar,d0
      beq.s     itiszero

itiszero
      blah blah blah

[Lonewolf10]

Originally Posted by frank_b

Set sp to the top of memory you want to clear.
Zero all registers and

rept lots of times
movem.l d0-a6,-(sp)
endr

For added fun switch to supervisor and use the usp too

Thanks for that.


Regards,
Lonewolf10

[Cosmos]

How many penality cycles on 68000/010 for :

ax = $00005000
move.l #$12345678,3(ax)


And for 020+ with datacache ??

[StingRay]

Originally Posted by Cosmos

How many penality cycles on 68000/010 for :

ax = $00005000
move.l #$12345678,3(ax)

A lot since it will generate an address error exception and your code will crash (68000 only allows byte moves to odd addresses).

[pmc]

Originally Posted by Lonewolf10

I heard that the movem instruction can be used to clear screens quickly. Is this true and how would it be done?

Originally Posted by frank_b

Set sp to the top of memory you want to clear.
Zero all registers and

rept lots of times
movem.l d0-a6,-(sp)
endr

But on a 68000 equipped Amiga this wouldn't be faster than using the blitter to clear memory surely.

Originally Posted by frank_b

Relying on the cpu flags to avoid a compare
move.l somevar,d0
beq.s itiszero

itiszero
blah blah blah

This should be just standard coding practice in my opinion. Moves, and various other commands, affect the condition codes so no need for compares on the results of those for things like zero, not zero, plus or minus number etc.

Comparing for a specific value would still be needed of course.