Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ptsfa!ihnp4!chinet!steinmetz!davidsen
From: davidsen@steinmetz.UUCP
Newsgroups: comp.arch
Subject: Re: Using a DMA chip in strange ways
Message-ID: <1337@steinmetz.steinmetz.UUCP>
Date: Fri, 27-Mar-87 12:13:56 EST
Article-I.D.: steinmet.1337
Posted: Fri Mar 27 12:13:56 1987
Date-Received: Sun, 29-Mar-87 11:04:23 EST
References: <4343@columbia.UUCP> <298@attila.weitek.UUCP> <518@gec-mi-at.co.uk> <246@root44.root.co.uk>
Reply-To: davidsen@kbsvax.steinmetz.UUCP (William E. Davidsen Jr)
Distribution: world
Organization: General Electric CRD, Schenectady, NY
Lines: 27

In article <246@root44.root.co.uk> njh@root44.UUCP (Nigel Horne) writes:
>In article <518@gec-mi-at.co.uk> you write:
>>In article <4343@columbia.UUCP>, dupuy@amsterdam.columbia.edu (Alexander Dupuy) writes:
>>>> [] would
>>>> there be any advantage in having a DMA chip which would simply be used for

>When doing a port of UniPlus+ on a machine with a spare channel on it's
>68450 I tried a few benchmarks. I'm afraid (with a 68k at least) it was
>slower using the 68450 than the 68010 (dbra's, moveml's etc.) for memory
>to memory copies.

What I think you mean is "takes less real time" using the CPU.
If you are doing an operation which requires waiting until the
memory has been moved this is correct. If you can make other
good use of the CPU to run another process, the system will
probably run faster using DMA. For instance, moving a process in
memory to garbage collect, might have enough overhead with
pointer fiddling in tables to make the total real time less
using DMA. The overhead of handling the interrupt is trivial:
set a flag in the interrupt handler and return. The CPU can loop
on the flag when the rest of the tasks are done.

-- 
bill davidsen			sixhub \
      ihnp4!seismo!rochester!steinmetz ->  crdos1!davidsen
				chinet /
ARPA: davidsen%crdos1.uucp@ge-crd.ARPA (or davidsen@ge-crd.ARPA)