This post is part of a series where I try to dissect computers in just enough detail so you can understand the "magic" that goes on behind the curtains when you write a "hello world" program or open up a browser.
In the last post we were talking about RAM memory and how it's different than HDDs and SSDs. The difference is: HDDs and SSDs are input and output devices.
Input and Output devices, frequently called I/O devices, are all around us, and most of what we think as "a computer" is actually just a bunch of I/O devices. To name a few: hard drives, mouses, keyboards, monitors, printers, projectors, sensors, microphones and speakers are all I/O devices.
Now the first thing to realize here is that I/O devices are very different, and I'm not only talking about how a microphone is different than a printer, but how different microphones can be when compared to each other. Just think of how different a professional ASMRtist's mic looks when compared to mine. Just as they look different, they operate differently. But you don't care about that, right? I mean, you want every microphone to be plug-and-play. That's the first challenge with I/O devices: handle all their different types and standards.
Controllers
I/O Controllers (IOC) are pieces of hardware that, you guessed it, control the I/O devices. They are responsible for sending and receiving data from and to the devices. Some examples of controllers are USB controllers, DMA controllers, etc.
Drivers
Drivers are pieces of software that control hardware, more specifically in this case, they control the controllers. Think of it this way: if a controller is the infrastructure that allows the CPU to send instructions to the I/O devices, then the driver's role is to translate those CPU instructions into ones that the controllers can understand.
Drivers help us solve the problem of having to support several different types of hardware because, with drivers, each driver manufacturer is responsible for providing, along with the hardware, a driver to control that hardware. Thus, the only thing we have to do to use the hardware is install the device's driver and pray it's supports our Operating System and doesn't have any bugs.
*cough
Nvidia
*cough
The second problem with I/O devices is speed. I/O devices are by far the slowest part of any computer (well... besides networking stuff, but that's a discussion for another post). You've heard me complain about this for a couple posts now, so it's about time I make my case.
In a computer the physical distance of components matter. The cache is closer to the CPU, so it's faster to access than the RAM (which is farther away). In terms of distance, I/O devices are connected using long cables and, on top of that, these cables (like USB and HDMI) are not as fast as a PCI connection for example, which is what's mostly used to connect graphics cards to the motherboard (more on that in future posts).
Access types
An access type is exactly what it looks like: how does the CPU access I/O devices. There are three main ways of accessing I/O: programmed I/O, interrupt initiated I/O and DMA.
Programmed I/O: Here the I/O data is read by a computer program that's running on the CPU, meaning that it's the CPU, following instructions of a particular program, that will fetch data or send it to the devices. This often requires the CPU to be constantly checking if the I/O device is done with the task (which is called busy wait), and so it's the slowest of the three access types we'll cover here.
Interrupt Initiated I/O: To avoid busy waiting for the I/O device, in the interrupt initiated I/O the I/O device will interrupt the CPU once it's done with the task. Here, the CPU does not need to check if the I/O device is done at all, and, once it's done issuing the task to the I/O device, it will go do other tasks. Finally, when interrupted by the device, the CPU comes back to the task at hand.
Direct Memory Access (DMA): What if we didn't need to involve the CPU at all after it issues the task to the I/O device? Direct Memory Access means that the CPU will tell the device where to put the data once it's done. This way, the CPU will only need to issue the task to the I/O device, but no busy waiting or interrupts or any other task needs to be done on the CPU side.
We've already covered a lot of content. We've seen about the Von Neumman architecture, CPUs, GPUs, memory, and now I/O devices. Now, I think it's about time we talk about her. On the next (and last) post of the series we'll talk about the thing that glues everything together: The Motherboard.
Top comments (1)
Would you be interested to share you thoughts on one of our book titled, Modern Computer Architecture and Organization? In return we would share a free ebook copy of the book and any other ebook as per your expertise.