Date   : Tue, 24 Nov 2009 16:28:27 +0000
From   : rs423@... (Mick Champion)
Subject: Quine

Ian Stocks wrote:
> Mick Champion wrote:
>   
>> Ian Stocks wrote:
>>     
>>> Mick Champion wrote:
>>>   
>>>       
>>>> Sorry, I should have done PLP there as opposed to PLA. So if I wanted to 
>>>> save A and its flags and do something else
>>>>
>>>> PHA
>>>> PHP
>>>> //do other code
>>>> PLA
>>>> PLP
>>>>
>>>> ?
>>>>     
>>>>         
>>> Nope, think of a stack of plates, the last one you pushed onto the pile 
>>> will be the first one you pop off the pile. So the push and pop need to 
>>> be nested.
>>>
>>> PHA
>>>    PHP
>>>      //do other code
>>>    PLP
>>> PLA
>>>   
>>>       
>> Got you! So a dodgy sub-routine could plant something else in the stack 
>> and cause problems if it then leaves it there.
>>     
>
> Possibly, but remember the return address is also pushed and popped on 
> to the stack for a subroutine call. So your code would have to work 
> quite hard to leave data on the stack as well as a valid return address. 
> Probably just find your RTS goes somewhere unintended.
>   
Oh right. So you couldn't PLA from within a subroutine when you had 
PHA'd from the outside it,  unless you pulled it twice amd remembered to 
push the 1st byte back?

Would this work

PHA      // send A to stack
JSR sub1
         // other code

.sub1
    // do so other code  requiring A then ;
TSX // take RTS address out of the stack
PLA // get the byte I put in in main section and put in to A
PHA // put the A byte back I we need to
TXS // put the RTS back last 
// whatever
RTS


Whenever I've written assembly before, if I wanted to use A or X or Y 
after using them in between, I've always saved them to a memory 
location, then loaded them when needed. Never touched the stack.



Mick



> Ian.
>
>
> _______________________________________________
> bbc-micro mailing list
> bbc-micro@...
> http://lists.cloud9.co.uk/mailman/listinfo/bbc-micro
>   
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 9.0.709 / Virus Database: 270.14.80/2523 - Release Date: 11/24/09
07:46:00
>
>