English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 20 June 2012, 11:46   #81
pmc
gone
pmc's Avatar
 
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
pmc is offline  
Old 22 June 2012, 19:13   #82
hooverphonique
ex. demoscener "Bigmama"

 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,002
Quote:
Originally Posted by frank_b View Post
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.
hooverphonique is online now  
Old 22 June 2012, 19:45   #83
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,246
This will surely not corrupt the stack! Check the 68k manual to see why. It's an old trick to save a few cycles.
StingRay is offline  
Old 22 June 2012, 21:04   #84
hooverphonique
ex. demoscener "Bigmama"

 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,002
Quote:
Originally Posted by StingRay View Post
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
hooverphonique is online now  
Old 22 June 2012, 22:41   #85
pmc
gone
pmc's Avatar
 
Join Date: Apr 2007
Location: completely gone
Posts: 1,596
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.
pmc is offline  
Old 04 July 2012, 22:38   #86
frank_b
Registered User
 
Join Date: Jun 2008
Location: Boston USA
Posts: 441
Quote:
Originally Posted by StingRay View Post
This will surely not corrupt the stack! Check the 68k manual to see why. It's an old trick to save a few cycles.
)
frank_b is offline  
Old 16 July 2012, 19:32   #87
kaffer
Registered User
 
Join Date: May 2011
Location: Cambridge
Posts: 581
Quote:
Originally Posted by frank_b View Post
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)?
kaffer is offline  
Old 16 July 2012, 19:39   #88
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,246
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 21:44.
StingRay is offline  
Old 16 July 2012, 20:13   #89
pmc
gone
pmc's Avatar
 
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
pmc is offline  
Old 16 July 2012, 20:18   #90
kaffer
Registered User
 
Join Date: May 2011
Location: Cambridge
Posts: 581
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 kaffer; 16 July 2012 at 22:24.
kaffer is offline  
Old 16 July 2012, 20:25   #91
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 44
Posts: 23,362
Quote:
Originally Posted by StingRay View Post
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.

Last edited by Toni Wilen; 16 July 2012 at 21:28.
Toni Wilen is offline  
Old 16 July 2012, 20:30   #92
kaffer
Registered User
 
Join Date: May 2011
Location: Cambridge
Posts: 581
Quote:
Originally Posted by Toni Wilen View Post
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.
kaffer is offline  
Old 16 July 2012, 21:26   #93
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,246
Quote:
Originally Posted by Toni Wilen View Post
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.

Last edited by StingRay; 16 July 2012 at 21:43.
StingRay is offline  
Old 16 July 2012, 23:32   #94
hooverphonique
ex. demoscener "Bigmama"

 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,002
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.
hooverphonique is online now  
Old 16 July 2012, 23:34   #95
StingRay
move.l #$c0ff33,throat

StingRay's Avatar
 
Join Date: Dec 2005
Location: Berlin/Joymoney
Posts: 6,246
Sure does. Might be that I needed this behaviour once and my mind was playing tricks on me.
StingRay is offline  
Old 16 July 2012, 23:54   #96
frank_b
Registered User
 
Join Date: Jun 2008
Location: Boston USA
Posts: 441
Quote:
Originally Posted by StingRay View Post
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

Last edited by frank_b; 29 July 2012 at 14:04. Reason: Added code block around code.
frank_b is offline  
Old 17 July 2012, 00:09   #97
hooverphonique
ex. demoscener "Bigmama"

 
Join Date: Jun 2012
Location: Fyn / Denmark
Posts: 1,002
@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 :-)
hooverphonique is online now  
Old 17 July 2012, 00:16   #98
frank_b
Registered User
 
Join Date: Jun 2008
Location: Boston USA
Posts: 441
Quote:
Originally Posted by hooverphonique View Post
@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

Last edited by frank_b; 17 July 2012 at 00:22.
frank_b is offline  
Old 19 July 2012, 17:30   #99
meynaf
son of 68k
meynaf's Avatar
 
Join Date: Nov 2007
Location: Lyon / France
Age: 46
Posts: 3,620
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
meynaf is offline  
Old 24 February 2014, 00:35   #100
NorthWay
Registered User
 
Join Date: May 2013
Location: Grimstad / Norway
Posts: 614
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.
NorthWay is offline  
 


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

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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 17:45.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.11057 seconds with 14 queries