68000 code optimisations
 

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:

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.

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. :great

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

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

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) ?

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)

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

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

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

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

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

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

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

For added fun switch to supervisor and use the usp too ;)

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

A quick way to get the remainder on a power of two div
It's a tad faster than a div.
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.

Absolute short addressing to set ST IO registers. Don't try this on anything other than a vanilla 68k
Relying on the cpu flags to avoid a compare

Thanks for that.


Regards,
Lonewolf10

How many penality cycles on 68000/010 for :

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


And for 020+ with datacache ??

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

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

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. :)