Quote:
Originally Posted by SpeedGeek
Yes, you can. Please read the 040 manual. MOVE16 "Efficiently" moves large blocks of memory when the data is not expected to be of immediate use.
|
This is what this entire debate is all about. No, you cannot, in general, assume that MOVE16 performs correctly in an Amiga system. That is the whole point. The "precautions" on such boards are just "use the vendor supplied CPU library", and you are good.
Quote:
Originally Posted by SpeedGeek
However, if the target memory is known to be non-cachable (e.g. Chip RAM) or Cache WriteThrough RAM (e.g. MMU table RAM) then MOVE16 will always outperform MOVE.L for any block size.  |
Why would it? The output would be transfer-burst inhibited anyhow if the board supplies TBI, and thus the net speed result is absent as a MOVEM would deposit the data in the push buffer as well. In fact, on my GVP040 board a MOVE16 into graphics card memory was a bit slower than a MOVEM loop, and on my 2060, the performance of a MOVEM loop into such memory is identical to that of a MOVE16 loop, except that the latter is not necessarily robust.
In my experience, there is nothing to be gained from MOVE16 except potential instabilities. The only case where you might gain something is if you move from CPU-local (32-bit) memory into itself, thus essentially CopyMemQuick(). The best approach here is, however, not to move data around in first place, i.e. use a better algorithm.
If the data cannot be deposited in the right target buffer, for example due to DMA restrictions, or specialized hardware (graphics boards), then the advantage of MOVE16 diminishes anyhow as you run into the issue how to reach "this other data" over a Zorro II/III bus which does not support bursting.