help optimising a section of code

h0ffman · 27 February 2011, 20:51

Hi guys..

can anyone help me optimise this section of code. It's part of my scope routine..

Code:

MOVEQ	#7,D3
	MOVE.B	(A0)+,D0	; get byte
	EXT.W	D0		; extend to word
	NEG.W	D0		; negate
	MULS	D5,D0		; multiply by volume
	ASR.W	#7,D0		; shift down
	MOVE.W	D0,D1
	ASL.W	#5,D0		; * 32
	ASL.W	#3,D1		; * 8
	ADD.W	D1,D0		; (32+8) = * 40
	BSET	D3,(A1,D0.W)	; set a bit

I've rolled it out of the loop and its running faster, but wondered if there was anything that could be done to speed up this process??

Cheers

frank_b · 27 February 2011, 21:14

Is d5 a constant? If so and you're on a 68k use a look up table.

h0ffman · 27 February 2011, 21:50

D5 is the volume. Min value coming in would be 1 and max would be 32.

Kalms · 27 February 2011, 23:20

Then create 32 different lookup tables, one for each possible volume level. Both the multiply and those shifts are scary slow.

StingRay · 28 February 2011, 00:05

What Kalms said. You can precalculate almost the complete innnerloop into a table (rows = volume, columns = byte), then it's just a matter of pointing to the right line in the table which you can do in the outer loop once the volume has been calculated. And in the innerloop you just read the value from the table depending on the sample byte and do the bset.

h0ffman · 28 February 2011, 00:17

7530 bytes of pre-calc data..... hmmm.. think I has room for that...

Oh and thanks for that guys. As soon as you said rows / columns.. it all made sense.

matthey · 28 February 2011, 04:26

Code:

    MOVE.B    (A0)+,D0    ; get byte
    EXTB.L    D0        ; extend to word
    NEG.L    D0        ; negate
    MULS    D5,D0        ; multiply by volume
    ASR.L    #4,D0        ; shift down
    MOVE.L    D0,D1
    ASL.L    #2,D0        ; * 32
    ADD.L    D1,D0        ; (32+8) = * 40
    ;stick an instruction that doesn't alter A1 or D0 here if possible
    BSET    #7,(A1,D0.L)    ; set a bit

Check this for correctness. It should be faster than before on 68020-68060. It makes a couple of assumptions though. MULS is going to be faster on 68060 than a lookup table. Use of long values makes the code almost twice as fast on the 68060. The (A1,D0.L) I believe is faster on 68020-68040 too. Immediate BSET is faster than adding MOVEQ.

StingRay · 28 February 2011, 09:25

Quote:

Originally Posted by matthey

Check this for correctness. It should be faster than before on 68020-68060. It makes a couple of assumptions though.

And one assumption is that he needs 020-060 optimised code.

He needs the code optimised for 68000.

h0ffman · 28 February 2011, 10:32

Well spotted stingray, yep runs fine on the 68020, plenty of raster time left. Its running it on the A600 thats where the issue is.. I think this lookup is going to pimp it right up

Will let you guys know later how it's gone.

StingRay · 28 February 2011, 11:04

I had a few seconds to spare at work, this table should do what you need. Since I don't want to spoil your fun coming up with a solution yourself, this is not the fully optimized version, i.e. I didn't precalc everything.

The code should just give you an idea how to do it.

Code:

MAKETAB	lea	TAB(pc),a0
	moveq	#0,d0		; vol
.loop	moveq	#0,d1
.loopvol
	move.w	d1,d2
	ext.w	d2
	neg.w	d2
	muls.w	d0,d2
	asr.w	#7,d2
	move.w	d2,(a0)+
	addq.b	#1,d1
	bcc.b	.loopvol
	addq.b	#1,d0
	cmp.b	#32,d0
	blt.b	.loop
	rts

TAB	ds.w	32*256		; vol -> byte

Edit:

Quote:

Originally Posted by h0ffman

7530 bytes of pre-calc data..... hmmm.. think I has room for that...

How did you calculate that number?

h0ffman · 28 February 2011, 15:10

wrongly as i found out today!

anyways, got it in, f@*k me thats quicker! Still a lot to do on it like ensuring it draws loops correctly etc... but getting there

Cheers again

pmc · 28 February 2011, 15:16

Quote:

Originally Posted by h0ffman

anyways, got it in, f@*k me thats quicker!

LOL.

True though, on 68000, the LUT is your friend

h0ffman · 28 February 2011, 15:22

Once i've finished it, i'll send it over mate

pmc · 28 February 2011, 15:24

\o/

8bitbubsy · 02 March 2011, 07:16

That snippet on the first page is actually from the ProTracker source code.. :P
/me has been reading PT1.2.asm too much!

h0ffman · 02 March 2011, 13:19

Well spotted fella. Thats exactly where it came from. I've had to fix a lot of bugs with it.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Optimising ILBM decode	pmc	Coders. Asm / Hardware	21	12 October 2011 20:24
Wanted Section	Fiery Phoenix	HOL suggestions and feedback	1	15 July 2011 06:15
Section 8 ???	plasmatron	Nostalgia & memories	4	04 June 2004 20:40
[perhaps bad section]	bobbybearing	request.Old Rare Games	1	11 October 2003 17:45
3D code and/or internet code for Blitz Basic 2.1	EdzUp	Retrogaming General Discussion	0	10 February 2002 11:40

27 February 2011, 20:51	#1
h0ffman Registered User Join Date: Aug 2008 Location: Salisbury Posts: 746	help optimising a section of code Hi guys.. can anyone help me optimise this section of code. It's part of my scope routine.. Code: MOVEQ #7,D3 MOVE.B (A0)+,D0 ; get byte EXT.W D0 ; extend to word NEG.W D0 ; negate MULS D5,D0 ; multiply by volume ASR.W #7,D0 ; shift down MOVE.W D0,D1 ASL.W #5,D0 ; * 32 ASL.W #3,D1 ; * 8 ADD.W D1,D0 ; (32+8) = * 40 BSET D3,(A1,D0.W) ; set a bit I've rolled it out of the loop and its running faster, but wondered if there was anything that could be done to speed up this process?? Cheers

27 February 2011, 21:14	#2
frank_b Registered User Join Date: Jun 2008 Location: Boston USA Posts: 466	Is d5 a constant? If so and you're on a 68k use a look up table.

27 February 2011, 21:50	#3
h0ffman Registered User Join Date: Aug 2008 Location: Salisbury Posts: 746	D5 is the volume. Min value coming in would be 1 and max would be 32.

27 February 2011, 23:20	#4
Kalms Registered User Join Date: Nov 2006 Location: Stockholm, Sweden Posts: 237	Then create 32 different lookup tables, one for each possible volume level. Both the multiply and those shifts are scary slow.

28 February 2011, 00:05	#5
StingRay move.l #$c0ff33,throat Join Date: Dec 2005 Location: Berlin/Joymoney Posts: 6,863	What Kalms said. You can precalculate almost the complete innnerloop into a table (rows = volume, columns = byte), then it's just a matter of pointing to the right line in the table which you can do in the outer loop once the volume has been calculated. And in the innerloop you just read the value from the table depending on the sample byte and do the bset.

28 February 2011, 00:17	#6
h0ffman Registered User Join Date: Aug 2008 Location: Salisbury Posts: 746	7530 bytes of pre-calc data..... hmmm.. think I has room for that... Oh and thanks for that guys. As soon as you said rows / columns.. it all made sense.

28 February 2011, 04:26	#7
matthey Banned Join Date: Jan 2010 Location: Kansas Posts: 1,284	Code: MOVE.B (A0)+,D0 ; get byte EXTB.L D0 ; extend to word NEG.L D0 ; negate MULS D5,D0 ; multiply by volume ASR.L #4,D0 ; shift down MOVE.L D0,D1 ASL.L #2,D0 ; * 32 ADD.L D1,D0 ; (32+8) = * 40 ;stick an instruction that doesn't alter A1 or D0 here if possible BSET #7,(A1,D0.L) ; set a bit Check this for correctness. It should be faster than before on 68020-68060. It makes a couple of assumptions though. MULS is going to be faster on 68060 than a lookup table. Use of long values makes the code almost twice as fast on the 68060. The (A1,D0.L) I believe is faster on 68020-68040 too. Immediate BSET is faster than adding MOVEQ. Last edited by matthey; 28 February 2011 at 04:32.

28 February 2011, 10:32	#9
h0ffman Registered User Join Date: Aug 2008 Location: Salisbury Posts: 746	Well spotted stingray, yep runs fine on the 68020, plenty of raster time left. Its running it on the A600 thats where the issue is.. I think this lookup is going to pimp it right up Will let you guys know later how it's gone.

28 February 2011, 15:10	#11
h0ffman Registered User Join Date: Aug 2008 Location: Salisbury Posts: 746	wrongly as i found out today! anyways, got it in, f@*k me thats quicker! Still a lot to do on it like ensuring it draws loops correctly etc... but getting there Cheers again

28 February 2011, 15:22	#13
h0ffman Registered User Join Date: Aug 2008 Location: Salisbury Posts: 746	Once i've finished it, i'll send it over mate

28 February 2011, 15:24	#14
pmc gone Join Date: Apr 2007 Location: completely gone Posts: 1,596	\o/

02 March 2011, 07:16	#15
8bitbubsy Registered User Join Date: Sep 2009 Location: Norway Posts: 1,711	That snippet on the first page is actually from the ProTracker source code.. :P /me has been reading PT1.2.asm too much!

02 March 2011, 13:19	#16
h0ffman Registered User Join Date: Aug 2008 Location: Salisbury Posts: 746	Well spotted fella. Thats exactly where it came from. I've had to fix a lot of bugs with it.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)