4.1. Computer Organization and Architecture A Pedagogical Aspect

So, welcome to the last unit of the module on addressing mode, instruction set and instruction execution flow. Throughout this module in the last 7 units basically we have covered mainly different type of instructions, their format, their operand types, what are the addressing modes and finally, in the last unit we covered a very special type of instructions which are actually called conditional instructions.

In this introduction, the instructor welcomes students to the final part of a module focused on how instructions are executed within a computer. The previous units covered a variety of topics including instruction types and addressing modes. The last unit specifically discusses conditional instructions, which alter the execution flow depending on specific conditions such as whether a flag (indicating true/false or zero/non-zero) is set.

Think of this like a traffic light (the conditional instruction). When the light is green, cars (instructions) proceed; when it's red, they must stop (change flow based on condition). Just like traffic flows differently depending on the light, computer instructions flow based on conditions set by flags.

Today, the last unit that is we are going to use such conditional instructions in a very very practical application which is called the procedure return and call. If all of us we have written some C or C++ high level language codes and we know that functions or procedures are a very very important part of all programming language because you can modularize your code.

Here, the focus shifts to practical applications of procedural calls in programming. Procedures (also called functions) allow programmers to organize and reuse code. When programming, we often invoke (call) a procedure to perform a specific task, like summing numbers or processing data. This helps us break down complex problems into manageable parts.

Imagine you are baking a cake (your main program). You need to follow several steps: first mix the ingredients, then bake them, and finally frost the cake. Each of these steps can be seen as a procedure, making the whole process easier and organized versus trying to do everything at once.

But what happens is that whenever you are writing running a main code from there you have to call to a subroutine or a function and then from that function you can call another function and it can go on. But what are the issues there the first very simple issue is that you have to know at which location I am going to jump.

When a procedure is called, the processor needs to remember where it was in the code before it jumped to the procedure. This is called saving context. The code needs specific instructions indicating where to jump (the memory address of the procedure) to ensure that after executing the procedure, execution continues seamlessly.

Consider navigating a multi-level parking garage. If you park on level 3, you need to remember your exact parking spot (context) to return. Similarly, the computer needs to remember where it left off before jumping to a new task (procedure) so it can return to the original task correctly.

So, in other words the whole context of the program has to be saved in a stack. So, very very important components of the stack are basically we call it as the program status word which will have all the values of the flags, which will have the value of the program counter or in other words the context of the current program has to be stored in a stack when you are calling a procedure.

The context of a program, including the program counter (which points to the next instruction), flag values, and register values, must be saved before executing a procedure. This is done using a stack, which is a data structure where information is stored in a Last In First Out (LIFO) manner. When the procedure finishes, this information can be retrieved from the stack to resume the original program.

Think of a stack like a stack of plates. You can only take the top plate off (the last one you put on). If you want the bottom plate, you have to take off all the plates above it first. Similarly, when executing procedures, information is pushed onto the stack and later popped off in reverse order.

And if they are nested procedure as we will see in an example, so procedure a will call procedure b, procedure b will call procedure c and at every call the context of the calling procedure will be stored in a stack and when you are returning unwinding the procedure calls.

In programming, procedures can call other procedures, leading to nested calls. When this happens, each calling procedure saves its context on the stack. When control returns from each procedure, it retrieves its context from the stack, allowing it to resume from where it left off. This helps in maintaining a clear structure, even when multiple calls are made.

Imagine a family gathering where a parent leaves the room to check on a child, then the child asks another person a question before returning to the parent. Each time someone leaves, they remember to return to their conversation as it was, just like procedures save their context before calling others so they can return to their original task.

So, these are the basic objectives which we are going to fulfill after running this unit.

To effectively utilize procedures, it is crucial to understand how to design call and return instructions. These instructions specify how a procedure should be invoked (called) and how control should return from the procedure back to the original program. Fundamental components involved include the program counter and status registers, and the design ensures that context is preserved accurately.

Think of a circuit and its switches. Correctly designed switches ensure that when you press one, the corresponding light turns on (calling a procedure) and when you turn the switch off, the light goes back to its previous state (returning to the original context). Similarly, well-designed call and return instructions ensure seamless execution flow in programs.

--