Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!cbmvax!daveh
From: daveh@cbmvax.commodore.com (Dave Haynie)
Newsgroups: comp.sys.amiga.hardware
Subject: Re: 68010 Questions...
Message-ID: <10720@cbmvax.commodore.com>
Date: 9 Apr 90 19:56:38 GMT
References: <40109@iuvax.cs.indiana.edu> <12667@mcdphx.phx.mcd.mot.com> <801@auto-trol.UUCP> <700@sagpd1.UUCP> <10604@cbmvax.commodore.com> <12077@vdsvax.crd.ge.com>
Reply-To: daveh@cbmvax (Dave Haynie)
Organization: Commodore, West Chester, PA
Lines: 43

In article <12077@vdsvax.crd.ge.com> perley@trub.crd.ge.com (Donald P Perley) writes:

>Just a quicky on the "is a 68010 any better" question.  There is supposed to
>be some improvement on tight loops.  Would the data transfer loop for a 
>non-DMA disk driver be likely to fit in the cache? (GVP in particular, maybe
>I should ask them)  Would this make a difference in transfer speed, CPU
>available to other tasks, etc?  How about chip memory contention?

This is one of the places a 68010 might show you significant performance gains.
One of the most obvious uses of 68010 loop mode is for faster large block
transfers; if you can avoid reading instructions, and just deal with data in
and out, you can't help but go faster.

The problem with this theory, of course, is that some of the unrolled loop
tricks used to make block transfers go faster on a plain 68000 would go
slower on a 68010 than a simple DBNZ loop which can exploit loop mode on
the '010.  My best guess would be that, if a program were to use the CopyMem()
or CopyMemQuick() routines in Exec, the transfer could be about as fast as
possible on a 68000, and even faster than that on a 68010.

Chances are, the nature of the performance gain would be more towards the
"CPU available to other tasks" than anything else.  The disk controller on
a good programmed I/O drive like the GVP isn't taking any CPU time until
the transfer is complete, then it activates the CPU to do the transfer.  As
compared to the CPU time spent seeking an all, you won't notice that much
of a delay in CPU copying, but you could easily spend lots of CPU time on
the copy itself.  If loop mode made the transfer take 1/2 the normal time
(I doubt it's that effective, but take that as a guess), then the 20% of
CPU time you might have spent on disk service might now be only 10%.  In other
words, only a good benchmarking program could tell you just how much of a
help this would be.  I expect the 68010 to help you out more on this kind
of thing than any arbitrary CPU operation, but the extent of help is hard
to guess.

>-don perley
>
>perley@trub.crd.ge.com


-- 
Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests"
   {uunet|pyramid|rutgers}!cbmvax!daveh      PLINK: hazy     BIX: hazy
                    Too much of everything is just enough