CS255 Syllabus

How Computers execute Recursive Function...

A recursive function is actually not very different from a non-recursive one (the ones that we have written so far), except for one special property:
- there are multiple invocation of the same function active all at the same time
This causes some variables organization problems that we must deal with to make recursion work:
- We must maintain separate copies of the parameter variables and the local variables that are created each time when the recursive function is activated.
- We must destroy the copy of the parameter variables and the local variables that pertain to the proper recursive function invocation when the invocation finishes (and returns)
$6,000,000 Question:
Parameter and local variables are created each time we invocate a function, why didn't we encounter this problem in non-recursive function invocations ?
Answer:
- We did create a new parameter variable when we invoke a non-recursive function.
- Namely, we reserved registers D0, D1, etc for passing parameters.
- Once they are reserved, they are no longer available for other uses.
- (Remember: creating a variable is the same as reserving memory, in this case, the memory is reserved in the CPU...)
- As for the local variables, we have cheated... well, for a good reason, I did not want to deal with variable on the stack when I introduce you to functions - they are complicated enough and I want to separate the two issues ("how functions pass parameters and return values" and "how to create parameters and local variables") and deal with them one at a time.
- I dealt with the local variables by creating a permanent copy for use by the function using ds
- The variables created by ds exist at the beginning of the program and they remain even after the function returns.
- So these local variables that I created with ds do not go away after the function returns....
- In other words, we did not implemented the local variable correctly - in fact, we used a global/static variable as if it is a local variable
- But that was the easiest way to introduce you to the concepts of functions without having to deal with the problem of "creating variables on the stack"
- In reality (programs generated by compilers), non-recursive functions will also pass parameters using the stack and create local variables on the stack
Procedure Activation Record:
- As I have hinted above, realizing recursive functions is only a variables organization problems: how to organize the various copies of the parameter and local variables in such a way so that each function invocation operates with its own copy of parameter and local variables.
- When you organize information, it is helpful to define a common structure of the information you try to organize and use this blue print to manipulate the information.
- The information used in implementing recursive function calls is call a Procedure Activation Record or Stack Frame and it has the following format:
```
   +---------------------+ <------------ Stack pointer
   |                     |
   | 0 or more           |
   | local variables     |
   |                     |
   +---------------------+ <------------ Frame Pointer
   | Saved Frame Pointer |
   +---------------------+
   |  Return Address     |
   +---------------------+
   |                     |
   | 0 or more           |
   | parameter variables |
   |                     |
   |                     |
   +---------------------+
```
- Note that this structure is created on the system stack using push operations !!!
- I will explain below what each item contains
The items in the stack frame:
- Parameter variables:
  - These are the parameter variables for the called function.
  - They are created on the system stack by the caller function
- Return Address:
  - This is the return address that was push on the stack when the caller function executed a BSR instruction to invoke the called function.
- Frame Pointer:
  - The frame pointer is nothing more than a convenient way to gain access to the procedure activation record of the currently running function.
  - Notice that although multiple copies of a recursive function is active at the same time, there is only ONE copy that is currently running.
    (The currently running one is the last one that was called, all other copies are suspected, waiting for some other function to return)
  - The frame pointer is used by the currently running function to gain access to ITS OWN parameter and local variable.
  - In M68000, it is natural to use the register A6 as frame pointer (although it is possible to use other registers)
  - The Saved Frame Pointer item in the procedure activation record contains the Frame Pointer value of the caller function which was running when it made the function call but now has been suspended
    The called function becomes the currently running function
  - The called function will use its own procedure activation record and make the Frame Pointer (register A6) point to its own procedure activation record....
  - In other words, it will change the value in register A6.... so if we do not save the value of register A6 (which the caller function needs when the called function returns), we will not be able to restore the value back in register A6....
  - The Saved Frame Pointer slot in the procedure activation record is defined just for this purpose: save the frame pointer of the caller function so that we can restore it when the called function returns.
- Local Variables:
  - These are the local variables that are created when the function is invoked.
How the stack frame (procedure activation record) is built:
- The stack frame is constructed piece meal on the system stack
- Assume the system stack (before building any part of stack frame) looks as follows:
```
   +----------------------+ <------ Stack pointer (top of system stack)
   |       xxxxxx         |
   +----------------------+
   |       yyyyyy         |
   +----------------------+
   |       zzzzzz         |
   +----------------------+
   |       ......         |
```
  The values xxxxxx, yyyyyy, zzzzzz are the 3 most recent values that were pushed on the system stack...
- The stack frame structure is built by first pushing 0 or more parameter variable(s), creating the following structure:
```
   +----------------------+ <------ Stack pointer (top of system stack)
   | 0 or more            |
   | parameter variables  |
   |                      |
   +----------------------+
   |       xxxxxx         |
   +----------------------+
   |       yyyyyy         |
   +----------------------+
   |       zzzzzz         |
   +----------------------+
   |       ......         |
```
  Notice that the stack pointer has moved and some memory reservation is made.
  Since it is the caller function that passes the paramters to the callee, it is therefore the caller function that will create the parameter variables on the system stack.
- After pushing (and passing) the parameter variable(s), the caller executes a bsr instruction and calls the callee function. The bsr instruction pushes the return address of the caller on the system stack, creating the next item of the stack frame:
```
   +----------------------+ <------ Stack pointer (top of system stack)
   |  Return Address      |
   +----------------------+
   | 0 or more            |
   | parameter variables  |
   |                      |
   +----------------------+
   |       xxxxxx         |
   +----------------------+
   |       yyyyyy         |
   +----------------------+
   |       zzzzzz         |
   +----------------------+
   |       ......         |
```
  So the return address is also created by the caller function.
  Notice again that the stack pointer has moved further, protecting the return address.
- Now the called function begins its execution !!!
  (How do we know this ? Well, the caller function just executed the bsr instruction and this instruction make the computer execute the first instruction that pertains to the called function.)
  Notice that the stack frame is not yet complete
  The called function must finish building the stack frame before it can start executing the instructions of the function itself !
  So there is always a fragment of code (instructions) at the start of a recursive function that is used to complete the stack frame.
  This fragment is called the pre-lude (or pre-amble) of the function.
- In step 1 of the pre-lude, the called function will push the frame pointer (register A6) onto the stack, creating the following structure:
```
   +----------------------+ <------ Stack pointer (top of system stack)
   |  Saved Frame Pointer |
   +----------------------+
   |  Return Address      |
   +----------------------+
   | 0 or more            |
   | parameter variables  |
   |                      |
   +----------------------+
   |       xxxxxx         |
   +----------------------+
   |       yyyyyy         |
   +----------------------+
   |       zzzzzz         |
   +----------------------+
   |       ......         |
```
  - In order to understand why the called function must do this, you need to look into the future. Let me elaborate using fac(120) as example.
  - The invocation of "fac(120)" will create a stack frame to store its parameter 120.
  - The invocation of "fac(120)" will also use a frame pointer to access its stack frame - it will change register A6 to point to the stack frame that "fac(120)" built on the system stack.
  - Now... "fac(120)" will sooner or later call "fac(119)"....
  - ...."fac(119)" will also create a stack frame to store its parameter 119...
  - The invocation of "fac(119)" will also change register A6 to point to its own stack frame - and it is different one than the stack frame that "fac(120)" built...
  - Sooner or later, "fac(119)" will return back to "fac(120)" (with the result 119!) and "fac(120)" continues....
  - Uh oh... the frame pointer A6 was changed by "fac(119)" and without the proper value in the frame pointer A6, "fac(120)" cannot find its parameters and local variables.
  - That is the reason why the first step of the pre-lude saves the frame pointer on the stack
    (you will see later that the saved frame pointer value will be used restored the frame pointer A6 to its original value when the called function returns to its caller function)
- If you compare the stack at this moment to the finish stack frame that we are building, you will understand the next step of the pre-lude:
```
   What we have built until now:        What we want:

					+-----------------------+ <-- Stack
					|			|     pointer
					|			|
					|			|
					|			|
   +----------------------+ <-- Stack	+-----------------------+ <-- Frame
   |  Saved Frame Pointer |     Pointer	| Saved Frame Pointer   |     pointer
   +----------------------+		+-----------------------+
   |  Return Address      |		|  Return Address       |
   +----------------------+		+-----------------------+
   | 0 or more            |		| 0 or more             |
   | parameter variables  |		| parameter variables   |
   |                      |		|			|
   +----------------------+		+-----------------------+
   |       xxxxxx         |		|	xxxxxx		|
   +----------------------+		+-----------------------+
   |       yyyyyy         |		|	yyyyyy		|
   +----------------------+		+-----------------------+
   |       zzzzzz         |		|	zzzzzz		|
   +----------------------+		+-----------------------+
   |       ......         |		|	......		|
```
  - Notice that the top of the stack (address contained by the stack pointer register A7) is precisely the value we want to assign to the frame pointer register A6
  - Therefore, NOW is the golden opportunity to initialize the stack frame register A6, and the instruction that will do this is:
```
    MOVE.L   A7, A6
```
  This will result in the same structure, except now we have the frame pointer initialized:
```
   +----------------------+ <------ Frame pointer and Stack pointer
   |  Saved Frame Pointer |
   +----------------------+
   |  Return Address      |
   +----------------------+
   | 0 or more            |
   | parameter variables  |
   |                      |
   +----------------------+
   |       xxxxxx         |
   +----------------------+
   |       yyyyyy         |
   +----------------------+
   |       zzzzzz         |
   +----------------------+
   |       ......         |
```
- After this little bookkeeping execise (initializing the frame pointer), the stack frame is completed by allocating the local variables.
  This is done by pushing the stack pointer further upwards and the resulting structure is:
```
   +----------------------+ <------ Stack pointer (top of system stack)
   | 0 or more            |
   | local variables      |
   |                      |
   +----------------------+ <------ Frame pointer
   |  Saved Frame Pointer |
   +----------------------+
   |  Return Address      |
   +----------------------+
   | 0 or more            |
   | parameter variables  |
   |                      |
   +----------------------+
   |       xxxxxx         |
   +----------------------+
   |       yyyyyy         |
   +----------------------+
   |       zzzzzz         |
   +----------------------+
   |       ......         |
```
  Notice that the stack pointer and frame pointer are seperated. The stack pointer is used to "protect" the reserved memory spaces while the frame pointer is used to locate (access) the parameter and local variables.
Program Warning:
You may (or may not) have notice that I quoted "protect" in the last sentence.
That is because the stack pointer itself cannot "protect" the reserved memory spaces.
It is up to the programmer to respect the reservation.
The stack pointer simply gives the limit of the memory space after which all location is reserved.
It is up to the programmer to respect this. If he does (no bugs), the reservation is honored. And if the programmer made an error and its program allocate some PREVIOUSLY reserved space AGAIN, then the protection is violated.
(It's somewhat comparable to a sign that says "No Trespassing" - it's up to the individual to honor this request or not. And just like the sign example, there are consequences if you do not honor the reservation.... Your program will usually crash and burn if you do not maintain the reservation correctly, since the memory location has been assigned for multiple use and multiple values will overwrite one another... It is not gonna be pretty to debug such a program either...)
OK, enough theory, let's see some concrete examples.... next...