Can it be faster?

[oRBIT]

I've been browsing to my old emulator code for optimization-possibilites. I'm moving alot of data back and forth and found this code below as an example. It's purpose is to move one character tile (8x8 chunky pixels) to it's destination screen (256x240), both located in FastRAM.
Is there a more clever way of doing this?

move.l (a5)+,(a0)
move.l (a5)+,256*0+4(a0)
move.l (a5)+,256*1+0(a0)
move.l (a5)+,256*1+4(a0)
move.l (a5)+,256*2+0(a0)
move.l (a5)+,256*2+4(a0)
move.l (a5)+,256*3+0(a0)
move.l (a5)+,256*3+4(a0)
move.l (a5)+,256*4+0(a0)
move.l (a5)+,256*4+4(a0)
move.l (a5)+,256*5+0(a0)
move.l (a5)+,256*5+4(a0)
move.l (a5)+,256*6+0(a0)
move.l (a5)+,256*6+4(a0)
move.l (a5)+,256*7+0(a0)
move.l (a5)+,256*7+4(a0)

[Kalms]

The copying operation itself is probably fairly fast the way that you've written it. Depending on the platform it might be slightly quicker to read 2-4 longwords into registers and then write them out, instead of doing read+write moves each time.

However, consider asking yourself some architectural questions.

1) could you change the code such that it writes directly to the chunkybuffer instead? (so you don't need the copying step at all)
or
2) can you have the chunkybuffer scrambled such that each 8x8 tile is stored sequentially in memory, and use a custom c2p routine which does de-scrambling inline? (If you are intending to do any further processing of the chunkybuffer - like drawing software sprites into it - then this option is probably a no-go)

[dalton]

I'm probably stretching it a bit far, but maybe if the char you are copying is planar, you could do without chunky conversion altogether. You'd probably need an equal amount of writes (only .b), but the amount of data could me smaller so you get better cache hit ratios.