Subject: Re: Quadra AV SCSI DMA Code
To: None <port-mac68k@netbsd.org>
From: Nathan Raymond <nate@portents.com>
List: port-mac68k
Date: 06/09/2003 01:43:17
At 8:32 PM -0400 6/8/03, Michael R.Zucca wrote:
>For instance, the SCSI channel appears to do DMA's 2 bytes at a time
>(as shown in the technote) and requires a 16 byte alignment (as seen
>by experience).
Hmm, this sounds like it was specifically designed for the 68040
MOVE16 instruction, which is an very efficient way of moving data
around. Here's some info on it:
http://www.mactech.com/articles/mactech/Vol.09/09.02/Efficient68040/
>Most people have at least heard about the only new instruction that
>the 68040 provides but many people aren't sure when they can use it.
>The rules are pretty simple: the source and destination addresses
>must be an even multiple of 16 and you must be moving 16 bytes at a
>time.
>
>So when is this useful? Well, if you know you're running in a 68040
>environment (use Gestalt) then you know that the Memory Manager only
>allocates blocks on 16 byte boundaries (because that's the way Apple
>implemented it). You can use this information to your advantage if
>you are copying data from one memory block to another.
>
>Why not just use BlockMove you ask? Three reasons: (1) Trap
>overhead, (2) Job preflighting to find the optimal move instructions
>for the given parameters (which we already know are Move16
>compatible) and, (3) It flushes the caches for the range of memory
>you moved every time you call it.
>
>Why does it flush the caches? Because of the case where the Memory
>Manager has called it to move a relocatable block that contains code
>(the MM doesn't know anything about the contents of a block so it
>has to assume the worst). This one case imposes an unnecessary
>penalty on your non-code BlockMoves (99% of all moves, I would
>guess) and it is this author's opinion that Apple should provide a
>BlockMoveData trap that doesn't flush the caches and that would only
>be called when the programmer who wrote the code knew that what was
>being moved was not code (and deliberately made a call to
>BlockMoveData instead of BlockMove). Write your senator, maybe we
>can do some good here.
>
>One other thing to note about the Move16 instruction is that unlike
>other Move instructions it doesn't leave the data it's moving in the
>data cache. This is great if you're moving a large amount of data
>that you're not going to manipulate afterwards (like updating a
>frame buffer for the screen or something) but may not be what you
>want if you're about to manipulate the data that you're moving
>(where it might be advantageous to have it in the cache after it's
>been moved). There is no rule of thumb on this because it depends on
>how much data you have and how much manipulation you're going to do
>on it after it's moved. You'll have to run some tests for your
>particular case.
And here's an article on a re-implimentation of Apple's BlockMove
that uses the 68040 MOVE16 instruction:
http://www.mactech.com/articles/mactech/Vol.09/09.05/68040BlockMove/
Is there any 040 optimizing done in NetBSD right now?
--
Nathan Raymond