Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!sun-barr!texsun!texbell!killer!elg
From: elg@killer.DALLAS.TX.US (Eric Green)
Newsgroups: comp.arch
Subject: Re: DMA on RISC-based systems
Message-ID: <8328@killer.DALLAS.TX.US>
Date: 10 Jun 89 00:45:16 GMT
References: <188@dg.dg.com>
Organization: The Unix(R) Connection, Dallas, Texas
Lines: 46

in article <188@dg.dg.com>, rec@dg.dg.com (Robert Cousins) says:
> In article <620@biar.UUCP> jhood@biar.UUCP (John Hood) writes:
>>>Where does the DMA pay off given that all three examples have approximately
>>>identical throughput?  
>>My other thought is that regardless of the CPU cost, programmed I/O is
>>often acceptable on single-user machines anyway.  The situation often
> I strongly disagree here.  In the modern Unix world, multitasking is
> of critical importance
> of jobs up to and including gettys for each user's terminal.  Programmed
> I/O is the enemy of multitasking since it effectively keeps the CPU from
> servicing tasks for a potentially long interval killing the ability
> for another task to service a request.

I have a non-DMA hard disk controller on the multitasking machine that
I use (so multitasking that each filesystem and device driver runs as
seperate tasks, albeit high-priority tasks). I'll agree that
programmed I/O sucks the wind out of any other task (of lower
priority) that is running, but it's not quite as bad as you put it.
The CPU can fetch data from buffer on the disk controller faster than
it can do anything with that data, so most things, e.g. compiles,
consist of long moments of Deep Thought by the process, punctuated by
occasional disk hits.  This is hardly the "disaster" that you claim,
although I do wish I had been able to get a DMA controller (I couldn't
trust one with the bus expander I'm using, alas).

And for the person who thought that the buffer on the disk controller
would have to be double-ported -- nope. Just bus oriented, with access
from either the disk side or the bus. I'm no hardware wiz (beware of
programmers with slaughtering irons!), but I can think of a couple of
ways to do it with standard TTL. E.g., use '273s as the "data port",
and loadable counters to address the RAM buffer sequentually (without
having to do math on it for each additional byte). 

> The truth is that all alternatives need to be considered.  Sometimes
> the answers will fool you.

Yep. And the "answer", in this case, is that while programmed I/O is
certainly nothing to be proud of (at least with a slow processor like
my 8mhz 68000), it's not the big disaster to multitasking that you
might expect. 

--
    Eric Lee Green              P.O. Box 92191, Lafayette, LA 70509     
     ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg     (318)989-9849    
"I have seen or heard 'designer of the 68000' attached to so many names that
 I can only guess that the 68000 was produced by Cecil B. DeMille." -- Bcase