68000 code optimisations - Page 5

pmc · 20 June 2012, 10:46

Yes of course. Swapping adds for the lsl's is faster - in fact, I'd already mentioned that earlier in this thread

hooverphonique · 22 June 2012, 18:13

Quote:

Originally Posted by frank_b

and.w #power of 2-1,d0

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

surely this would corrupt your stack as the stack pointer will end up being off by +1.

StingRay · 22 June 2012, 18:45

This will surely not corrupt the stack! Check the 68k manual to see why. It's an old trick to save a few cycles.

hooverphonique · 22 June 2012, 20:04

Quote:

Originally Posted by StingRay

This will surely not corrupt the stack! Check the 68k manual to see why. It's an old trick to save a few cycles.

Didn't check the manual but I guess you're right.. Having the stack pointer at an uneven address would cause major problems on the lowly 68000 if subsequently a word/long is pushed/popped, so I guess sp is always even.. Apparently it's been too long since I coded 68k asm - I used to code demos and stuff in the '90s

pmc · 22 June 2012, 21:41

Yes, as Sting says, on 68000 the stack always "auto aligns" to a word boundary when a byte is pushed on.

Quote:

Originally Posted by hooverphonique

I used to code demos and stuff in the '90s

Nice one.

frank_b · 04 July 2012, 21:38

Quote:

Originally Posted by StingRay

This will surely not corrupt the stack! Check the 68k manual to see why. It's an old trick to save a few cycles.

)

Keir · 16 July 2012, 18:32

Quote:

Originally Posted by frank_b

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

Does this put garbage in the bottom byte of d0, unless you already ensured -1(sp) = 0, and have interrupts disabled? i.e., not exactly equivalent to lsl.w #8,d0 (ignoring effects on condition codes)?

StingRay · 16 July 2012, 18:39

doesn't put garbage in the lower part of d0, it will be cleared.

see toni's reply.

pmc · 16 July 2012, 19:13

Kaffer: to get the answer to your question you should try running this kind of stuff in a debugger and watching the registers. You'll see the results and learn stuff directly

Keir · 16 July 2012, 19:18

Well I'm running in E-UAE on Linux and it doesn't clear the low byte. Nor do a couple of other emulators I've pulled source for. So to confirm it I'd need to dust down my Amiga. I'm interested for my own emulator is all...

Toni Wilen · 16 July 2012, 19:25

Quote:

Originally Posted by StingRay

doensn't put garbage in the lower part of d0, it will be cleared.

No, it isn't cleared. EDIT: tested on real A500. EDIT2: 68060 tested: does not clear either.

Keir · 16 July 2012, 19:30

Quote:

Originally Posted by Toni Wilen

No, it isn't cleared. EDIT: tested on real A500.

Thank you for checking, Toni.

Also, implementing the clearing would have been a slight pain in the butt special case in my emulator.

StingRay · 16 July 2012, 20:26

Quote:

Originally Posted by Toni Wilen

No, it isn't cleared. EDIT: tested on real A500.

I checked on my A4000 long ago and it was always cleared. Time to dig deeper I guess.

Edit: checked again, lower byte is indeed not cleared. So apparently I I remembered it wrong.

hooverphonique · 16 July 2012, 22:32

sounds reasonable since all that happens is that move.b d0,-(sp) decrements sp by two before storing, so whatever was on -1(sp) before will get into the low byte when doing move.w (sp)+,d0.

StingRay · 16 July 2012, 22:34

Sure does.

Might be that I needed this behaviour once and my mind was playing tricks on me.

frank_b · 16 July 2012, 22:54

Quote:

Originally Posted by StingRay

Sure does.

Might be that I needed this behaviour once and my mind was playing tricks on me.

I tested using this code albeit on the Hatari emulator.

d1 winds up being $ff00

Code:

oddsandends
        move.l sp,d0
        move.w #$3344,-(sp)
        move.b #$ff,d1
        move.b d1,-(sp)
        move.w (sp)+,d1   ; shift by 8
        move.l d0,sp
        rts

Seems my memory and test code was fuzzy. Here's a better test case.

Code:

oddsandends
        move.l sp,d0
        move.w #$3344,-(sp)  ; set four bytes up with garbage
        move.w #$1122,-(sp)  ; " " 
        
        addq   #2,sp         ; point the stack at $1122

        move.l sp,a1         ; stuff it in a1
        move.b -1(a1),d2     ; we load $22 
        
        move.b #$ff,d1       ; then move shift value
        move.b d1,-(sp)      ; boom high byte is $22 
        move.w (sp)+,d1      ; shift by 8 and d1 is now $ff22 
        move.l d0,sp
        rts

Indeed there's garbage in the lower byte. Care must be taken when using the stack with this trick

hooverphonique · 16 July 2012, 23:09

@frank: Yes, but your example doesn't prove anything, since you don't initialize the contents of -1(sp) with a known value before using the magic trick...

move.w #$BEEF,-(sp)
move.w (sp)+,d0 ; sp back where we started, d0=$BEEF
move.b d0,-(sp)
move.w (sp)+,d0 ; d0 should now contain $EFEF if theory holds true and low byte is not cleared.

edit: seems you corrected your example while i posted this :-)

frank_b · 16 July 2012, 23:16

Quote:

Originally Posted by hooverphonique

@frank: Yes, but your example doesn't prove anything, since you don't initialize the contents of -1(sp) with a known value before using the magic trick...

move.w #$BEEF,-(sp)
move.w (sp)+,d0 ; sp back where we started, d0=$BEEF
move.b d0,-(sp)
move.w (sp)+,d0 ; d0 should now contain $EFEF if theory holds true and low byte is not cleared.

edit: seems you corrected your example while i posted this :-)

Indeed.

Fired up Hatari and went straight into devpack to check if my assumption was incorrect.
I then realised the missing piece of the puzzle

I was thinking of something else too but then realised I was wrong about that

Anything subtle like that that could require hours of debugging to find/fix is a worthwhile trick

meynaf · 19 July 2012, 16:30

Something perhaps few people know : if A7 points to an odd address and you byte access it, it will still work !

This will just add/subtract 2 to it as usual, allowing you to read/write one byte out of two (this time at an odd address).

But you must be *very* careful because no other stack access must be made while you do that

NorthWay · 23 February 2014, 23:35

Use movep to get a byte to the upper half of a word.

A series of subrutine(OS?) calls like
jsr sub1
jsr sub2
jsr sub3
rts

can be turned on the head as
pea sub3
pea sub2
jmp sub1

optionally push the continue address first. I did this for my Exec optimizes.

16 July 2012, 18:39	#88
StingRay move.l #$c0ff33,throat Join Date: Dec 2005 Location: Berlin/Joymoney Posts: 6,863	doesn't put garbage in the lower part of d0, it will be cleared. see toni's reply. Last edited by StingRay; 16 July 2012 at 20:44.

16 July 2012, 19:18	#90
Keir Registered User Join Date: May 2011 Location: Cambridge Posts: 682	Well I'm running in E-UAE on Linux and it doesn't clear the low byte. Nor do a couple of other emulators I've pulled source for. So to confirm it I'd need to dust down my Amiga. I'm interested for my own emulator is all... Last edited by Keir; 16 July 2012 at 21:24.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
68000 boot code	billt	Coders. General	15	05 May 2012 20:13
Wasted Dreams on 68000	sanjyuubi	support.Games	5	27 May 2011 17:11
680x0 to 68000	Counia	Hardware mods	1	01 March 2011 10:18
quitting on 68000?	Hungry Horace	project.WHDLoad	60	19 December 2006 20:17
3D code and/or internet code for Blitz Basic 2.1	EdzUp	Retrogaming General Discussion	0	10 February 2002 11:40

20 June 2012, 10:46	#81
pmc gone Join Date: Apr 2007 Location: completely gone Posts: 1,596	Yes of course. Swapping adds for the lsl's is faster - in fact, I'd already mentioned that earlier in this thread

22 June 2012, 18:45	#83
StingRay move.l #$c0ff33,throat Join Date: Dec 2005 Location: Berlin/Joymoney Posts: 6,863	This will surely not corrupt the stack! Check the 68k manual to see why. It's an old trick to save a few cycles.

16 July 2012, 19:13	#89
pmc gone Join Date: Apr 2007 Location: completely gone Posts: 1,596	Kaffer: to get the answer to your question you should try running this kind of stuff in a debugger and watching the registers. You'll see the results and learn stuff directly

16 July 2012, 22:32	#94
hooverphonique ex. demoscener "Bigmama" Join Date: Jun 2012 Location: Fyn / Denmark Posts: 1,624	sounds reasonable since all that happens is that move.b d0,-(sp) decrements sp by two before storing, so whatever was on -1(sp) before will get into the low byte when doing move.w (sp)+,d0.

16 July 2012, 22:34	#95
StingRay move.l #$c0ff33,throat Join Date: Dec 2005 Location: Berlin/Joymoney Posts: 6,863	Sure does. Might be that I needed this behaviour once and my mind was playing tricks on me.

16 July 2012, 23:09	#97
hooverphonique ex. demoscener "Bigmama" Join Date: Jun 2012 Location: Fyn / Denmark Posts: 1,624	@frank: Yes, but your example doesn't prove anything, since you don't initialize the contents of -1(sp) with a known value before using the magic trick... move.w #$BEEF,-(sp) move.w (sp)+,d0 ; sp back where we started, d0=$BEEF move.b d0,-(sp) move.w (sp)+,d0 ; d0 should now contain $EFEF if theory holds true and low byte is not cleared. edit: seems you corrected your example while i posted this :-)

19 July 2012, 16:30	#99
meynaf son of 68k Join Date: Nov 2007 Location: Lyon / France Age: 51 Posts: 5,323	Something perhaps few people know : if A7 points to an odd address and you byte access it, it will still work ! This will just add/subtract 2 to it as usual, allowing you to read/write one byte out of two (this time at an odd address). But you must be very careful because no other stack access must be made while you do that

23 February 2014, 23:35	#100
NorthWay Registered User Join Date: May 2013 Location: Grimstad / Norway Posts: 839	Use movep to get a byte to the upper half of a word. A series of subrutine(OS?) calls like jsr sub1 jsr sub2 jsr sub3 rts can be turned on the head as pea sub3 pea sub2 jmp sub1 optionally push the continue address first. I did this for my Exec optimizes.

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