CompuServe Thread

#89706From: John FreemanOct 17, 1987 2:22 AM

So what is? DMA? Or another instruction?

#89721From: John DraperOct 17, 1987 3:43 AM

The MOVEM instruction is much faster, saving significant time otherwise spent fetching the MOVE instructions over and over.

#89782From: John FreemanOct 17, 1987 1:02 PM

How about on the 68010/68020 with the following sequence: LOOP: MOVE.B (A0)+,(A1)+ DBF D0,LOOP (where D0 has been appropriately set up as a counter) According to Motorola, this will be placed in a small internal cache (don't know about the relation of it to the 68020 which has a 256 byte internal cache, assume the same principle) and thus the loop will not generate external memory fetches for the instructions. Is MOVEM still faster? (I don't know the answer, myself). Also, for general block moves, I think it would be difficult to create a routine which used MOVEMs repetitively to accomplish the move. Not impossible, though. Don't know if it would be worth it.

#89792From: Nick Sullivan/TransactorOct 17, 1987 1:42 PM

I could be wrong about this, but I believe one of the 1.2 memory move functions _does_ implement a block move with MOVEM.

#89792From: Nick Sullivan/TransactorOct 17, 1987 1:42 PM

I could be wrong about this, but I believe one of the 1.2 memory move functions _does_ implement a block move with MOVEM.

#89928From: John DraperOct 18, 1987 3:56 AM

The operation you speak of, being a BYTE oriented move, would be improved by making it a WORD or LONG operation, regardless of processor. Comparing a MOVEM with repetetive MOVE.L shows a large gain in speed on a 68000. Not too sure what the difference would be, if any, on a 68010 using the DBRA. As for actually writing the routine, it isn't such a tough one. Say I have (through saving the registers I need with a MOVEM, to be restored after the operation) 8 registers available. Also suppose i know that the transfer is always 512 bytes (this is a rela life case), and that the source block is always longword aligned. First, I check the alignment of the destination. If it is even, I can simply set up a counter for the DBRA, then… MOVEM.L source,reglist MOVEM.L reglist,dest ADD #8,source ADD #8,dest DBRA back to the label I forgot to put in. If the alignment needs work, I simply transfer 1 byte, transfer a large block, (getting as close as I can within the 8 bytes at a time limitation), transfer a smale even number, then 1 nore byte to make it work out even. If the destination is always even, this techniques will increase the transfer rate by a large amount. The hard disk driver I am working on improved by about 8 or 9K per second using it, and on pure memory moves, a much greater speed increase woud be realized.

#90007From: John FreemanOct 18, 1987 9:01 PM

I thought about this last night and realized it wasn't as tough as I originally thought. I came up with a (untested) 20 instruction routine which does an arbitrary non-overlapping block move, using 32 bytes (8 long word registers) at a time. 32 bytes is a nice number because if the byte count is in D0.L, then doing: MOVE.L D0,D1 and then LSR.L #5,D0 to get the # of iterations for the MOVEM block move (using A0 as source and A1 as dest, use: MOVEM.L (A0)+,D2-D7/A2-A3 and MOVEM.L D2-D7/A2-A3,(A1)+). Then a simple AND.W #31,D1 will get any leftovers to be moved using D1.W as a counter, if any. I tend to use MOVE.B's for simple general purpose block moves because (1) the alignment doesn't then count, and (2) the byte count can be anything from 1 to n. Of course if you assume word alignment (which the MOVEM must anyway) and an integral multiple of 2 or 4, then you should of course use MOVE.W's or MOVE.L's as appropriate. I spent about 3 years hacking 68000's, including Amiga… I never really needed to get the very fastest speed, so never really investigated the fastest possible way. (On block moves of memory).

#90007From: John FreemanOct 18, 1987 9:01 PM

I thought about this last night and realized it wasn't as tough as I originally thought. I came up with a (untested) 20 instruction routine which does an arbitrary non-overlapping block move, using 32 bytes (8 long word registers) at a time. 32 bytes is a nice number because if the byte count is in D0.L, then doing: MOVE.L D0,D1 and then LSR.L #5,D0 to get the # of iterations for the MOVEM block move (using A0 as source and A1 as dest, use: MOVEM.L (A0)+,D2-D7/A2-A3 and MOVEM.L D2-D7/A2-A3,(A1)+). Then a simple AND.W #31,D1 will get any leftovers to be moved using D1.W as a counter, if any. I tend to use MOVE.B's for simple general purpose block moves because (1) the alignment doesn't then count, and (2) the byte count can be anything from 1 to n. Of course if you assume word alignment (which the MOVEM must anyway) and an integral multiple of 2 or 4, then you should of course use MOVE.W's or MOVE.L's as appropriate. I spent about 3 years hacking 68000's, including Amiga… I never really needed to get the very fastest speed, so never really investigated the fastest possible way. (On block moves of memory).

#89928From: John DraperOct 18, 1987 3:56 AM

The operation you speak of, being a BYTE oriented move, would be improved by making it a WORD or LONG operation, regardless of processor. Comparing a MOVEM with repetetive MOVE.L shows a large gain in speed on a 68000. Not too sure what the difference would be, if any, on a 68010 using the DBRA. As for actually writing the routine, it isn't such a tough one. Say I have (through saving the registers I need with a MOVEM, to be restored after the operation) 8 registers available. Also suppose i know that the transfer is always 512 bytes (this is a rela life case), and that the source block is always longword aligned. First, I check the alignment of the destination. If it is even, I can simply set up a counter for the DBRA, then… MOVEM.L source,reglist MOVEM.L reglist,dest ADD #8,source ADD #8,dest DBRA back to the label I forgot to put in. If the alignment needs work, I simply transfer 1 byte, transfer a large block, (getting as close as I can within the 8 bytes at a time limitation), transfer a smale even number, then 1 nore byte to make it work out even. If the destination is always even, this techniques will increase the transfer rate by a large amount. The hard disk driver I am working on improved by about 8 or 9K per second using it, and on pure memory moves, a much greater speed increase woud be realized.

#89782From: John FreemanOct 17, 1987 1:02 PM

How about on the 68010/68020 with the following sequence: LOOP: MOVE.B (A0)+,(A1)+ DBF D0,LOOP (where D0 has been appropriately set up as a counter) According to Motorola, this will be placed in a small internal cache (don't know about the relation of it to the 68020 which has a 256 byte internal cache, assume the same principle) and thus the loop will not generate external memory fetches for the instructions. Is MOVEM still faster? (I don't know the answer, myself). Also, for general block moves, I think it would be difficult to create a routine which used MOVEMs repetitively to accomplish the move. Not impossible, though. Don't know if it would be worth it.

#89721From: John DraperOct 17, 1987 3:43 AM

The MOVEM instruction is much faster, saving significant time otherwise spent fetching the MOVE instructions over and over.

#89706From: John FreemanOct 17, 1987 2:22 AM

So what is? DMA? Or another instruction?

#89761From: Ben BlishOct 17, 1987 12:12 PM

No, but it's one of the best… when you have a register available, I _believe_ that MOVE (ax),(ax)+ is… not so? (in a 68000) –Ben–

#89761From: Ben BlishOct 17, 1987 12:12 PM

No, but it's one of the best… when you have a register available, I _believe_ that MOVE (ax),(ax)+ is… not so? (in a 68000) –Ben–

#89762From: Ben BlishOct 17, 1987 12:13 PM

Unless you want to be "nasty" and use the movem stuff… -1-Ben–

#89923From: John DraperOct 18, 1987 3:28 AM

MOVEM is definitely not "nasty". It is a perfectly legitimate technique and can shave many cycles off if you move a large block of memory. For the instance you cited in the last message (move (ax),(ax)+), ie. moving from a fixed single location to a block of addresses, this is indeed the fastest way I know of. Of course I had to convince myself that it was by attempting to use shifts and such to "fill up" a register before storing it.

#90072From: Ben BlishOct 19, 1987 3:18 AM

It's limited to word boundries, wich makes it useless in many cases. –Ben–

#90202From: John DraperOct 19, 1987 10:27 PM

Ben, It really depends on the amount of data to be moved. The small overhead required to align the transfer at the beginning and end is more than made up for in the savings if the block is long enough. Regards, Larry.

#90254From: Ben BlishOct 19, 1987 11:34 PM

Yeah, and if the block could be any size, the use of a routine like that under multiple small-block conditions (common) would deteriorate the system. –Ben–

#90301From: John DraperOct 20, 1987 2:17 AM

Except for one thing Ben…. the original thread was directed at moving data from disk, so the smallest will be 512 bytes… plenty of saving in the MOVEM. Regards, Larry.

#90446From: Ben BlishOct 21, 1987 10:10 AM

I think the original thread was directed at moving data from the disk controller (a single address), and so the move (ax),(ay)+ I mentioned earlier wins. If you're transferring buffers you already recieved to some other buffer in the system, yes, you can increase the performance somewhat. –Ben–