Re: [cc65] CC65 and Stack Pointer

From: Ullrich von Bassewitz <>
Date: 2006-11-29 08:52:28
Good morning.

On Wed, Nov 29, 2006 at 11:43:35AM +0900, Hiroji Kimura wrote:
> oz,
> Thank you for your quick reply. I really appreciate it.
> > 3. Upon entering the interrupt handler do we need to push registers
> and pop them before RTI?
> >If you're calling C code, you will also have to save the zero page
> >locations used by the compiler. If your interrupt handler doesn't use
> C >code, saving just the registers is ok.
> What locations in the zero page does CC65 use?  Could you tell me which
> document has that information?

Any space in the ZEROPAGE segment. See the linker config and the zeropage.s
module on how big it is and where it is located.

> Also I wonder why our calculator works
> even without saving registers and zero page locations.  We are calling a
> c function within an interrupt and I am pretty sure that it will use
> real 6502 registers. I guess we only have "while(1);" in our main function.

Probably. If your main function doesn't do any actual calculations, there's
nothing that can be destroyed in an interrupt.

> Now, I am just curios. Why does cc65 generate codes which depend on
> subroutines like pushax and the secondary stack?  I understand Small-c
> implementation assumes a primary and a secondary registers.  I guess the
> reason is to make porting the c compiler to different architectures
> easier. Is it one of the reasons?

The main reason is that the 6502 doesn't have many registers, all of them are
just 8 bit and specialized. So it is for example impossible to do a
int=int+int calculation just by using registers. The solution is to keep the
values in main storage. This is why cc65 uses the software stack. And since
the code to push and pop values onto this stack is rather large, subroutines
are used.



Ullrich von Bassewitz                        
To unsubscribe from the list send mail to with
the string "unsubscribe cc65" in the body(!) of the mail.
Received on Wed Nov 29 08:52:34 2006

This archive was generated by hypermail 2.1.8 : 2006-11-29 08:52:37 CET