Path: utzoo!attcan!uunet!husc6!bloom-beacon!apple!amdcad!amdahl!nsc!stevew
From: stevew@nsc.nsc.com (Steve Wilson)
Newsgroups: comp.arch
Subject: Re: Sw vs. Hw BitBlit.
Message-ID: <5493@nsc.nsc.com>
Date: 8 Aug 88 16:40:09 GMT
References: <399@ma.diab.se> <1988Jul28.173301.7275@utzoo.uucp> <840@stride.Stride.COM>
Reply-To: stevew@nsc.UUCP (Steve Wilson)
Organization: National Semiconductor, Sunnyvale
Lines: 33

In article <840@stride.Stride.COM> mitch@stride.stride.com.UUCP (Thomas Mitchell) writes:
>
>This is true, and a common surprise.  Many 'DMA' processors are not
>as fast as the main processor. They commonly do not have, a
>bus interface equal to the processor or instruction cache or other
>goodies we now expect in a micro-processor.  
>
>In a system the DMA processor also must arbitrate with the processor
>for control of the bus.  Then communicate (message?) with the
>processor ....  Well--
>
>The result is that DMA processors are a loss except to the sales
>department.   

If your only moving one byte of data between interupts to the CPU
telling him you've moved some data, then your right.  A DMA controller
is a WIN when you can tell it to move a large fixed length piece of data
and then forget about it and go do something else.  Your correct about
losing memory bandwidth for the CPU, but this is a design trade-off 
point.  My favorite example is a serial I/O controller I designed
(Henry..You listening!!) where I had 12 serial I/O channels.  The
processor could handle about 7000 interupts/sec.  How ya gonna do
19.2Kb of constant data flow across 12 channels with that kind of interupt 
response time.  DMA was a cheap answer. (Henry, I'm NOT going to put
the DMA hardware on a general purpose CPU!) 

Point being that there are applications where special hardware such
as DMA makes sense, and there are applications where its a dumb idea!

Steve Wilson
National Semiconductor

[The above opinions are mine, not those of my employer! ]