68000 code optimisations

[pmc]

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

[hooverphonique]

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]

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]

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]

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

Originally Posted by hooverphonique

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

Nice one.

[frank_b]

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.

)

[kaffer]

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]

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

see toni's reply.

[pmc]

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

[kaffer]

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]

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.

[kaffer]

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]

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]

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]

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

[frank_b]

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

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.

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]

@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]

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]

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