4
$\begingroup$

I am reading Computer Architecture & Organization by William Stallings to understand I/O operations. Stallings pretty well explains why Programmed I/O (CPU keeps checking the I/O module register status) & Interrupt I/O (CPU still has to over look data transfer between I/O module & memory) are not efficient & introduces to DMA, where DMA itself handles everything.

But, however, he also mentions that during a DMA operation, CPU sits idle & has no control over memory bus. If CPU has to sit idle, then how it is better than other two methods ?

Page no. 415, Computer Architecture & Orgazination by Morris Mano:

During the DMA transfer, the CPU is idle and has no control of the memory.

Only way it make sense to me is that, CPU can perform any operation which does not involve memory bus during a DMA operation. So, CPU will not be idle. Or am I missing something ?

I think author has formulated in a bad way. It can be phrased like:

During DMA transfer, the CPU has no control of memory buses and thus cannot perform any operations involving memory. However it can perform other operations like arithmetic, logical or can operate on data in cache.

Am I right?

$\endgroup$
3
  • $\begingroup$ Think about CPU reads from the source, then write to the destination, word by word vs the source controls the bus and write to (or read from) the memory. $\endgroup$
    – Codism
    Mar 29, 2013 at 17:32
  • $\begingroup$ When I read your question again, it seems like you had assumed CPU must be busy to achieve a higher I/O efficiency. Would you explain why do you think so? $\endgroup$
    – Codism
    Mar 29, 2013 at 19:27
  • $\begingroup$ @Codism - I have updated my question, please have a look. I was thinking that why CPU has to sit idle during DMA operation. If at all, it has to sit idle, then how DMA is better than other two approaches Programmed I/O & Interrupt I/O. In these both cases also CPU not doing any work during memory transfer. But, CPU will be performing other operations during DMA, hence DMA is better. That's what is my current understanding. $\endgroup$
    – avi
    Mar 30, 2013 at 14:06

3 Answers 3

6
$\begingroup$

The DMA engine doesn't grab the bus for the duration of the whole transfer, only while specific data is being transferred. Yes, that means CPU acces to memory is hampered, but not shut off completely. The CPU can also work with data from its cache in the meantime.

$\endgroup$
2
  • $\begingroup$ Thank you for replying. Now it makes sense. Phrasing CPU sits idle (added screenshot now) is wrong in my opinion. $\endgroup$
    – avi
    Mar 30, 2013 at 14:07
  • 1
    $\begingroup$ @avi, textbooks lie. They need to (over)simplify so at least some basic concepts make it into refractary skulls in a short term. $\endgroup$
    – vonbrand
    Mar 30, 2013 at 14:22
3
$\begingroup$

Indeed, the wording of that sentence can lead to false conclusions. "The CPU is idle" actually means that it has no part in the memory transfer and (in principle) is free todo whatever the instructionstream(s) indicate.

While this can be phrased in only a couple of words the effects are tremendous! When the CPU does not do the data transfer, the CPU is not central anymore. This indicates the change in architecture performed by introducing DMA. Further, when there are two communicating entities and neither is the CPU, components will probablby end up competing for resources at some point. In this case they compete for the memory bus. Now the previously unthinkable can happen: the CPU cannot do memory I/O as it pleases and there must be coordination. There are race conditions and system states (and all hell breaking lose gg) to consider that couldn't happen before. That's what the second part of the quoted sentence and the following sentence are hinting at.

If a real architecture ever leaves a CPU idle can be doubted, but in principle, if your instruction stream is stored in memory only and the CPU cannot access memory it actually has nothing to do. Jumps can easily point to code that is not in the (rather small) cache and then the CPU indeed has to wait (or take action) for the memory bus to become available again. So Stallings is not wrong at all. He just ships around having to discuss a CPU's options, conditions and corner cases, when the bus is busy.

$\endgroup$
1
$\begingroup$

Historically, there have been a few advantages to DMA:

  1. Many processors would require multiple cycles to copy each byte of data from an I/O device to memory, or vice versa. With a 6502, for example, even if one makes some very generous assumptions about self-modifying code and memory layout, one would be hard-pressed to manage better than 10 cycles per byte transferred per in any sort of loop. By contrast, DMA hardware would only require two cycles per byte if reads and writes had to occur on separate cycles, or one per byte if the I/O could receive a read request when memory saw a write, or vice versa. Burst DMA hardware may thus outperform optimized code by a factor of 4-10.

  2. Some I/O devices require that data be transferred at a rate which is far below the memory bus bandwidth, but still pretty fast (say once every fifty bus cycles). Even if the processor took a few cycles to give up the bus for each DMA request, and such cycles ended up being idle, spending a half-dozen cycles to process each byte would be much better than requiring that the CPU service an interrupt for each byte.

  3. Some processors don't need to use the bus on every cycle. If the DMA can be limited to cycles when the CPU isn't otherwise using the bus, it might be possible for it to run without slowing down the CPU at all. Even if that isn't possible, some processors will prefetch code on an as-convenient basis. If a prefetch request is delayed by DMA, but the data still gets fetched before it's actually needed, the DMA request won't end up slowing things down.

Many of today's processors wouldn't have much trouble moving data about as fast as DMA could do it, but the other advantages can still be significant.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.