On Oct 4, 2011, at 4:07 AM, JMGross wrote: > [PICs] used to have (don't know about the current ones) a hardware > stack. > All local variables had to go to a fixed memory location too, > recursions were forbidden.
A stack is a concept (one that has proven particularly useful for implementing function calls with local variables.) 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. 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." 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... BillW ------------------------------------------------------------------------------ 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
