30.1.2. Details of Instruction Fetching

Now, we are going to take two examples; in one example we will show that what are the advantages of having three buses and another case we will show that we do not get so much advantage, if you are considering a multiple bus architecture. Two extremes that means two different instructions we will take and show, but for most of the cases we are always going to have an advantage, because that is very obvious because if you have multiple buses things will go parallelly, but for one or two stray examples we can see where the advantage is not there in fact, you are having more hardware, but still the number of stages are not reducing.

This chunk introduces the concept of comparing two examples to demonstrate the advantages of a multiple bus architecture versus a single bus architecture for instruction fetching. The idea is to show how multiple buses allow operations to occur simultaneously, resulting in better performance. However, there are exceptions where having more buses may not yield significant benefits due to increased hardware complexity and unchanged stages in processing.

Think of a highway with multiple lanes (multiple buses) where cars can travel side by side, allowing for faster movement. In contrast, imagine a single-lane road (single bus) where only one car can go at a time. While having more lanes often allows for quicker travel, there might be unique situations, like road construction, where the extra lanes do not help if the road still has to slow down or stop.

So, the first case we are going to take is add 𝑅 into 𝑅 . So, what is the thing? So, two variables 1 2 already available in 𝑅 and 𝑅 and then one you have to do it. So, first is you have to fetch the instruction. So, how do you fetch the instruction? Basically program counter output value will go to memory address register in, that is as simple as for single bus architecture then you put the memory in read mode here you select 0; that means, you want to add the constant and increment program counter and add.

In this chunk, the focus is on the instruction fetching process, specifically for the operation add R1 into R2. The first step involves fetching the instruction by taking the output from the program counter (PC) and moving it to the memory address register (MAR). This step sets up the system to read from memory by selecting the correct mode and value to add and also incrementing the program counter to point to the next instruction.

Imagine you're following a recipe (the instruction) to make a dish. The program counter is like your bookmark in the recipe book, indicating which step you're currently on. When you fetch the instruction, it's like checking your current step in the recipe, preparing to gather the next ingredients (data) you need to proceed.

But if you look at a single bus architecture, we had another signal that is called 𝑍 . Because the output of program counter plus constant has to store in a separate temporary register which we call it Z or Y and we have to wait till this step is over then only you can write the value to the program counter. But in this case as we have already seen we do not require any kind of a temporary register.

This chunk explains the role of temporary registers in the fetching process. In a single bus architecture, a temporary register (Z or Y) would be necessary to hold an interim value while waiting to update the program counter after fetching the instruction. However, in the new architecture being discussed, this temporary register is not needed, simplifying the fetching process.

Consider a person gathering ingredients for cooking. In a single bus architecture, they might set aside some ingredients on a counter (temporary register) before moving them to the pot (program counter). In the optimized architecture, they can directly place the ingredients into the pot without the need for a temporary setting area, making the cooking process smoother and faster.

So, even if I can take the input from here, but we are not doing it, because the PC is writing through bus B; but it can also be done, but if you have to you have to take the output for program counter through bus A, you have to disconnect this line and you have to disconnect this line. So, any option you can take. So, as I told you this is a very flexible architecture you can have your own design in this case we are taking this.

This chunk discusses the flexibility of the bus architecture. It highlights that while there are preferred methods, different configurations can be chosen based on the design needs. This adaptability allows engineers to optimize the systems in ways that work best for them.

Think of a flexible electrical wiring system in a house. While it’s standard to use certain configurations for efficiency, an electrician can choose to rearrange connections to suit the needs of specific appliances or lighting configurations—just as engineers can adjust bus connections.

Next stage is simple you have to make PC in read the value of output to the PC, and wait till the memory response. And if you look at the single bus architecture, these things were very similar you have to read the value of PC, WMFC, but also you had a sin single instruction called 𝑍 . 𝑍 will go to the value of PC in, but here PC in will not require any 𝑍 , because out already bus C is carrying the value of the new value of the program counter.

In this final step of instruction fetching, the program counter is updated directly from bus C without needing a temporary register. This process is similar in a single bus architecture, but again emphasizes how the multiple bus system streamlines the fetching and updating process by reducing control signals and stages.

If we liken the program counter to a reader turning pages in a book, in a single bus architecture, the reader might pause to hold bookmarks (temporary registers) for various steps. In contrast, with a more streamlined method, readers can just flip pages directly without needing to hold their place elsewhere, making for a faster reading experience.

--