----- Ursprüngliche Nachricht ----- > Von: William "Chops"Westfield > Gesendet am: 05 Okt 2011 11:30:44 > Betreff: Re: [Mspgcc-users] VLA in MSPGCC
> A stack is a concept (one that has proven particularly useful for > implementing function calls with local variables.) Right. But no concept that is required or mentioned in the C or C++ standard. > The stack (if any) used for the machine "CALL" instruction (if any) > need not be the same as the stack used for implementing local > variables within the function, and a hypothetical PIC compiler could > implement a software stack for local variables even though a hardware > stack (whose contents are not accessible, which is the real problem) > is used for the subroutine linkage instruction. I believe that > several commercial PCI compilers do this, even for the "braindead" > older PICs. Of course it could be omplemented, but there is no requirement to use a stack for storing local variables. The compiler could generate calls to malloc() to reserve a fixed memory portion for the local variables. However, interleaving the local variables with the function call stack is by far the easiest way to keep track of which storage area belongs to the current nesting level. > Many CPUs allow any register to be used as a stack pointer (even for > subroutine calls), so much of the behavior of function calls, argument > passing, and local variables is more up to convention and cooperation > than the details of HW support for "stacks." Indeed. The MSPGCC compiler often uses a completely different register to hold the stack frame pointer. However, usually one dedicated register keeps track of the TOS, so push and pop operations won't go wild. At least the pop could be implemented on any MSP register (MOV.W @Rx+, Ry). The 'real' POP is emulated this way, with Rx=R1. > For instance, the extremely popular ARM processor architecture does > not use a stack for its function-call primitive (the whole "push the > current PC, modify the pointer, load the new PC" is about one memory- > accessing step too long to be truly "RISC", or so the thought goes.) > ARMs put the return address in a register, and it's up to the compiler > writers to put that register on a stack as part of the function > startup code... Did you ever use the Sparc? Here the processor had a wheel of registers, organized in groups of 8 and blocks of three groups. On a call, teh wheel was turned by two groups. The third group of the calling function was becoming the first of the called, and two new sets appeared. The new PC was loaded to the third group and when the wheel turned, it became the new PC. When the wheel turned back upon funciton return, the old PC was wheeled in again. Parameter passing was done through the third group too, as well as passing return values. And local variables did go into the second group, while the unused registers in the first and third group could be used for temporary data that is clobbered on a function call. Writing a C compiler for this would be a PIA. I had to program it in assembly (write a monitor that handled an overflow/underflow of the "register wheel" when the code was nested too deep) however, the concept of a stack is only one concept (even if a successful and commonly used one) and one commonly used to store local variables. But it is not the only one and not the only way to deal with local variables. And if you don't have a stack, there is no need to simulate one, just to do C. JMGross ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
