This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Backend Stack-/Framepointer


Frank Riese <hippo@informatik.uni-bremen.de> writes:

This question is more appropriate for gcc@gcc.gnu.org than for
gcc-help.

> I'm writing a backend for gcc (gcc 4.0.2) for a target machine that neither 
> has its stack pointer accessible through any register visible to GCC nor does 
> it have a seperate frame pointer. The only instructions to access the stack I 
> have on that machine are PUSH and POP. 

gcc needs general access to some sort of stack frame.  It can't work
on a machine which doesn't provide that.

> I have thought about using one of the general purpose registers to substitute 
> for the stackpointer as the machine has a simple load/store architecture 
> where I can LOAD and STORE a word at an address specified in a register and 
> thus do my own POP and PUSH through LOAD and STORE. However, this seemed a 
> blind alley because the only way to return from a function on that machine is 
> through a RET instruction that takes the instruction pointer to return to 
> from that internal stack.

Using a different register as the stack pointer is the way to go.
Don't get tied up with the fact that RET doesn't use that stack.  Just
use two stacks: one for the call sequence, and one for stack frame
used for local variables.

The main drawback is that it will be rather difficult to implement
setjmp/longjmp, and unwinding the stack for exceptions.  Those are
going to be very difficult to implement on your processor now matter
how you do it, since they require the ability to set the stack pointer
to an arbitrary position higher on the call stack.

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]