On 05/10/2011 18:24, JMGross wrote: > > > ----- 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. >
As a side point, since we are discussing odd implementations, some systems have more than one stack. There are several things that (conceptually, at least) go on stacks - function return addresses, preserved registers, function parameters, and local data. Some systems use more than one stack to separate these. For example, the Imagecraft AVR compiler used one stack for function return addresses and preserved registers (using the efficient push/pop instructions), and one for function parameters and local data (since the avr has no good SP+offset addressing mode, the compiler used the Y register as a data stack pointer). >> 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. > These are details of the implementation of the stack - it's still logically a stack. >> 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. > Again, that's a stack. The difference is that it only moves in fixed jumps, and that it was (originally) implemented inside the processor rather than in memory. The registers work as a window onto the stack. > 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) > That's always the problem with hardware stacks - you have a limit to their size, and if it's not big enough things get very inconvenient. > 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. > Actually, you /do/ need to simulate one to do C - there is no other way to implement recursion (while you could, theoretically, use other structures such as lists or heaps, you would still be simulating a stack). Variable argument functions also require a stack to implement fully. And while these are features that are seldom used in embedded systems, they are still required for a C implementation. There are compilers that implement C-like languages, or C subsets, without using stacks - these are generally feature-limited or require proprietary extensions and keywords to implement things like re-entrant functions. For /most/ C code, you could simply consider every local variable to be "static" and compile accordingly, putting these variables at fixed addresses in ram. But it won't work for all C code. ------------------------------------------------------------------------------ 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
