25.1. Programmed I/O Overview

So, basically it is a sensing of status, then using the read write command, then transferring of data; this is the way that we are going to do, but here what is the problem that we have first? CPU needs to wait and poll, it is checking it continuously. So, it cannot do any other work. So, there is a wastage of CPU time.

Programmed I/O involves the CPU actively monitoring the status of an input/output device through polling. Polling means that the CPU regularly checks to see if the device is ready for data transfer. However, this is not efficient as the CPU is not doing any productive work while waiting for the device's status to change, leading to wasted processing time and efficiency.

Imagine a chef in a restaurant who continuously checks if the oven is ready instead of preparing other dishes. This constant checking not only wastes time but also delays the preparation of several meals, just like the CPU can miss other tasks while it polls the I/O device.

So, basically this is now programmed I/O details now you just see these are the simple steps; first one CPU requests to I/O operation that in processor we have shown it, I/O module performs operation, then by looking into the state of the devices I/O module sets the status bit, CPU checks status bits periodically.

The steps of programmed I/O start with the CPU initiating an I/O request. The I/O module then performs the requested operation, checking the state of the device and setting a status bit to indicate readiness. Meanwhile, the CPU continuously checks the status bit to see if the operation can proceed. This highlights the cycle of request, action, and confirmation between the CPU and I/O module.

Think of it like a customer ordering coffee at a café. The customer (CPU) places an order (I/O request), the barista (I/O module) prepares the coffee, and the customer continuously checks if the barista is ready to serve it (status checking). Until the barista indicates the coffee is ready, the customer remains idle, just like the CPU awaits the status update.

So, basically here I/O module does not inform CPU directly, this is the way that I/O module is doing it. Now after that to perform work with the I/O module or input output devices what are the basic requirements.

For the CPU to effectively communicate with I/O devices, certain commands are necessary. These include an identification method for the device addresses, control commands to initiate actions, and read/write commands to transfer data. The I/O module does not directly notify the CPU of its readiness, which is why the CPU must regularly check the status.

It’s like calling a friend who is supposed to pick you up. You need to identify your friend's car (address identification), ask them to start driving (control command), and finally get in the car when they arrive (read/write command). Just as the friend doesn’t text you every time they make a turn, the I/O module won’t alert the CPU directly.

we need some commands I/O commands... we have to give the addresses of the I/O devices.

I/O devices require unique addresses so that the CPU can communicate with them correctly. This addressing scheme is crucial as it ensures that commands are sent to the right device. Similar to how each house on a street has a unique number, each I/O device must have an address that can be recognized by the CPU.

Consider a GPS system. Each destination (I/O device) needs a unique address or coordinates for you (the CPU) to reach it without confusion. If multiple locations shared the same coordinates, you would have no idea where you’re headed.

In that particular case we are having two different ways of doing it. One is your memory mapped I/O and second one is your isolated I/O.

There are two primary ways to handle I/O device addressing: memory-mapped I/O, where the same address space is shared between memory and I/O devices, and isolated I/O, where separate address spaces exist for memory and I/O devices. Memory-mapped I/O allows for easy integration using existing memory commands, while isolated I/O relies on specific commands to interact with I/O devices.

Think of memory-mapped I/O as a universal remote that can control multiple devices (TV, DVD player, etc.) — you use the same buttons for all. In contrast, isolated I/O is like having a different remote for each device, requiring specific commands for each, leading to more complexity in managing the controls.

Now in that particular case what will happen we are giving the addresses through this particular address bus...

In isolated I/O systems, an additional control signal is used to distinguish whether the address on the bus is for a memory location or an I/O device. This control signal is known as IO/M, which indicates if the address being accessed is for I/O operations or memory operations, thereby optimizing the addressing scheme and allowing for a larger number of devices and memory locations.

Imagine a bus system where there are dedicated stops for passengers (I/O devices) and freight (memory locations). The bus driver (CPU) uses a sign (control signal) to indicate whether they are picking up passengers or unloading freight at every stop, ensuring that the right operations occur at the right time.

In that particular scheme, it is that in out or input and output will be controlled by a program...

The Device Service Routine is a specific program written to manage the input and output operations for a device. It frequently checks the status of the device through loops until it is ready, after which it carries out the necessary transfer of data. This programmatic approach improves efficiency by automating the checking process and executing actions.

Consider a waiter checking a table in a restaurant. The waiter routinely checks on the customers (device) to see if they need anything (are ready) — once they signal they’re ready to order, the waiter takes action, similar to how the CPU waits for the device status before executing input/output operations.

--