But this meant that the callee has to know how many parameters the caller supplied. Other compilers required the called function to remove the parameters before returning to the caller. The C language designers chose this method (which, by the way, was different than most other compilers at the time) for at least two good reasons: In C, these are arranged so that \$P_1\$ is closest to the FP activation frame reference pointer and \$P_\text\$ is furthest away from it. It's a "fixed" pointer to the current activation frame of the current instantiation of the function.Īll parameters ( \$P_i\$) to the function are known at compile-time and will have fixed, positive offsets relative to the FP. The activation frame pointer, FP, is kept unchanged throughout the duration of an activation of a function. Instead, I'm keeping this relatively limited.) Here's a stack diagram that is typical (an expanded and more readable diagram is available here.) (I won't provide a complete discussion of the entire scope of possibilities. (From the first days, in fact, 50 years ago.) In order to implement all of the above in a relatively simple fashion and in a way that the C compiler can generate recursive call support, as well as making it possible for re-entrant support (at least on a single-threaded machine model), the concept of a function activation frame has long been in wide use. For example, many will reserve out a few registers in the CPU for the first couple of parameters to be passed to a function and require that those functions obey that choice.)
#HOW TO WRITE C CODE OF PALINDROME INTO MIPS ASSEMBY FREE#
(Note that while I say all these things above, C compilers are also free to make more sophisticated rules, too. The C compiler also has agreements about how function values are returned, which registers in the CPU must be preserved by the called function and which can be simply used as "scratch" registers, and some other agreements such as which registers may be used for a stack pointer, activation frame pointer (I'll get to this), and any other special purposes that a C compiler author may come up with. This is also usually done by using the stack. And the C compiler compiling the function itself is responsible for knowing the size of the automatic variable space that the function requires and for allocating that space whenever the function is invoked. The C compiler compiling the function call is responsible for handling the parameters to the function in an agreed way - usually by pushing them onto the stack in a certain order and using agreed methods for the various types of values and pointers. All it knows is that it must compile this function, now. The same C compiler generating code for the function itself, again running in a completely separate compilation step - perhaps on a completely different day of the week, will not know anything about whether or not anyone is actually calling the function. The C compiler generating code for the function call, running in a completely separate compilation step, may only have access to the declaration for the function. In order to allow for local (automatic) variables for the function when compiling it, the C compiler usually reserves space for these also on the stack. So the following is in-scope for the site.įor others (and I can't tell if this helps you, too, but you may already know all this), a C compiler will (it doesn't have to, as there are often other mechanisms that a creative compiler author may also apply while staying within the required machine model for C) place parameters onto the stack before calling a function.
EESE, when programming is at question, is more about embedded programming.
0 kommentar(er)
