25.4.1. Functionality of Memory-Mapped I/O

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.

In memory-mapped I/O, the CPU repeatedly checks the status of a device to see if it is ready to send or receive data. This process is called polling. While the CPU is doing this, it cannot perform other tasks, leading to inefficient use of CPU resources and time. Essentially, the CPU is sitting idle, waiting for devices to become ready instead of being productive.

Think of polling like waiting for a friend to reply to your text message. If you keep checking your phone every few seconds, you can't focus on anything else, and you may waste a lot of time when you could be doing something fun or interesting.

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, I/O module does not inform CPU directly...

In programmed I/O, the CPU initiates the I/O operation by sending a request. The I/O module then performs the requested operation and updates a status bit that indicates whether the device is ready. The CPU continuously checks this status bit to determine the next steps. Unlike interrupt-driven I/O, there is no direct notification from the I/O module to the CPU; instead, it relies on the CPU to check periodically.

Imagine you're waiting for an elevator. You push the button to request it, and then you keep looking at the light panel to see if the elevator has arrived. You can't do anything else while you wait, and the elevator won't knock on your door to let you know when it's there; you have to keep checking.

Already I have mentioned that we need some commands I/O commands. So, first the issues for that I/O command is like that how to identify the module. So that means, we have to have device address...

To communicate with I/O devices, the CPU must know how to identify each device uniquely, which is achieved through addressing. Each device connected to the system must have a unique address, similar to how each house has a unique address. This allows the CPU to retrieve data from or send data to the correct device during operations.

Think of it like sending a letter. You need the specific address of where you want to send it. Just as you would write the address on an envelope to ensure it reaches the right person, the CPU uses the unique address to make sure data is sent to the correct I/O device.

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...

Memory-mapped I/O uses the same address space for both memory and I/O devices, meaning some memory addresses are reserved for device communication. In contrast, isolated I/O has separate address spaces for memory and I/O devices, with an additional control signal to determine whether a specified address refers to a memory location or an I/O device.

Imagine a library where books (memory) and magazines (I/O devices) are stored in the same section: that's like memory-mapped I/O. Now imagine a library where books are on one floor and magazines on another; this separation resembles isolated I/O, where you need to remember which floor to check for specific information.

So, in most of the cases we are talking about your LDA load accumulator or say SPA store accumulator; one is your read command, another is write command...

I/O commands can be categorized into three main types: control commands to manage devices, test commands to check device status, and read/write commands to transfer data. These commands instruct the CPU on how to interact with I/O modules, enabling data exchanges between the CPU and devices.

Think of commands like different types of instructions you give to a waiter in a restaurant. You can ask them to check if a dish is available (test), give an order (control), or ask for a drink refill (read/write). Each instruction tells the waiter what you want from the menu, just as the CPU instructs the I/O module on how to handle data.

--