It is currently Sat Oct 20, 2018 3:51 am

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 23 posts ]  Go to page Previous  1, 2
Author Message
 Post subject: Re: Palette Checker
PostPosted: Mon Mar 30, 2015 9:03 am 
Offline
User avatar

Joined: Mon Mar 02, 2015 1:11 am
Posts: 76
Location: Australia (PAL)
Khaz wrote:
My god man what do you DO to your stack? I mean I have a mostly-functional game on my hands at this point and I don't think my stack ever gets lower than about $1FD0ish. I try to avoid using it at all except to preserve registers and occasionally quickly store a value I'm going to use again in a second...


Maybe I'm being a little over-cautious in my stack space. I'm not sure where I pulled 512 bytes from.

I just ran Elevator Madness DX through a trace logger and the lowest the stack goes to $1FE2.

Somehow I kept thinking I was using more than that.

Well I'm going to change it to 128 bytes now.


Top
 Profile  
 
 Post subject: Re: Palette Checker
PostPosted: Mon Mar 30, 2015 4:11 pm 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3377
Location: Richmond, Virginia
Honestly, I never even use the stack. I originally wanted to use it to store information that would be loaded for the subroutine I was jumping to, but because it stores the value of where you jumped, it's pretty much useless for this, which is about the only thing I would use it for.


Top
 Profile  
 
 Post subject: Re: Palette Checker
PostPosted: Mon Mar 30, 2015 7:01 pm 
Offline
User avatar

Joined: Thu Dec 25, 2014 10:26 pm
Posts: 311
Location: Canada
Espozo wrote:
Honestly, I never even use the stack. I originally wanted to use it to store information that would be loaded for the subroutine I was jumping to, but because it stores the value of where you jumped, it's pretty much useless for this, which is about the only thing I would use it for.

I can't find the document anymore, but I was just reading about stack-relative addressing and ways to use it to pass variables to a subroutine. Here's a crude example that I'm probably doing wrong but should work:
Code:
    jsr subroutine
    .dw value1
    .dw value2

returnlabel:
    jmp _done

subroutine:
    plx    ;take the return address back off the stack

    inx    ;this might not be needed can't remember if jsr pushes return address or return address -1
    lda.w $0000, x    ;read the first .dw into A
    inx
    inx
    ldy.w $0000, x    ;read the second .dw into Y
    [...]
    jmp returnlabel    ;jmp back instead of rts, because the return address is no longer on the stack

Alternately, I guess you can just push all your variables, JSR, pull the return address and store it, pull all the variables off, then push the return address again. That sounds like a better idea. (EDIT: The code I wrote is stupid since it jmps back, it's not a proper subroutine. What you could do to make it work is pass #returnlabel into the subroutine as another .dw, and use it at the end to return.)

My understanding is that using the stack like that may not save in cycles but you might eliminate the need to allocate a variable to store it to? I don't know, I tried to look up a quick example but it seems like there's a dozen different ways of doing this. It didn't seem worth getting into to me...

However, the stack is great for preserving a register you want to restore later. Mostly at the start and end of subroutines and interrupts, but here and there I'll just push A X or Y when I need the register but I'm going to need the value again in a bit, generally only when there's a straight path for the code to follow so you never forget to pull again...


Top
 Profile  
 
 Post subject: Re: Palette Checker
PostPosted: Tue Mar 31, 2015 2:22 am 
Offline
User avatar

Joined: Sun Jul 01, 2012 6:44 am
Posts: 341
Location: Lion's den :3
Khaz wrote:
I can't find the document anymore, but I was just reading about stack-relative addressing and ways to use it to pass variables to a subroutine.

http://forums.nesdev.com/viewtopic.php?p=143652#p143652 :wink:

_________________
Some of my projects:
Furry RPG!
Unofficial SNES PowerPak firmware
(See my GitHub profile for more)


Top
 Profile  
 
 Post subject: Re: Palette Checker
PostPosted: Tue Mar 31, 2015 4:18 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
Khaz wrote:
My understanding is that using the stack like that may not save in cycles but you might eliminate the need to allocate a variable to store it to?

This is the main reason why high level languages store local variables in the stack, actually.


Top
 Profile  
 
 Post subject: Re: Palette Checker
PostPosted: Tue Mar 31, 2015 6:02 pm 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3377
Location: Richmond, Virginia
Sik wrote:
Khaz wrote:
My understanding is that using the stack like that may not save in cycles but you might eliminate the need to allocate a variable to store it to?

This is the main reason why high level languages store local variables in the stack, actually.

...and why they're not as good...


Top
 Profile  
 
 Post subject: Re: Palette Checker
PostPosted: Tue Mar 31, 2015 7:00 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6896
Location: Canada
Espozo wrote:
Sik wrote:
Khaz wrote:
My understanding is that using the stack like that may not save in cycles but you might eliminate the need to allocate a variable to store it to?

This is the main reason why high level languages store local variables in the stack, actually.

...and why they're not as good...

In C if you don't want the local variable on the stack, you can simply declare it "static". If you don't want to pass parameters on the stack, you can use global variables. The ability to use the stack for local variables is a feature, not a liability; you haven't lost any ability to do without it.


Top
 Profile  
 
 Post subject: Re: Palette Checker
PostPosted: Tue Mar 31, 2015 7:38 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
Espozo wrote:
...and why they're not as good...

Behaving like everything should have larger sizes than adequate (at least unless overriden) and making it easier to perform rather expensive operations (sometimes to the detriment of faster ones) probably is a much bigger issue.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 23 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group