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