Optimising ILBM decode

[Photon]

It will inescapably be faster. More than double the speed for the fill, and a little less than double the speed for the copy, on the 68000. Also, there is no faster way that's easier to code.

REPT 256 will take about 512 bytes more in code-size than before, for each of the two loops. You can make two odd- and even- aligned REPT 128 x move.w in the same code-size of one REPT 256 x move.b, but for the copy loop you need a fallback 256xmove.b code chunk for 50% of the cases - exactly one of source and destination are odd. Won't work with a word copy then.

Too much special cases and you will kill the performance of small loops. I prefer to divide by say 16 (lsr #4), do the remainder as a dbf loop, then the quotient (if non-0) for a REPT 16 loop. (I called this to "splay out" a loop in 1991, sounds silly now) If you write the code to favor early-exit (as in low cycle count) for counts < 16, you have a general-purpose and not too obfuscated reusable loop unraveling method.

[pmc]

Originally Posted by Thorham

Did you try Photon's REPT idea? Gets rid of the dbf instructions, and without caches and pipelines (68020+) this will most certainly be faster.

No, not yet - I'm very busy at the moment and have had no time but as soon as I get some of that precious commodity I will be trying it!

Thanks for that tip Photon - will let you guys know the speed improvement once I've got it implemented successfully.

EDIT: My son fell asleep early and my wife is out so I had some time this evening \o/

New routine with offset jmps instead of dbf loops now implemented and working fine and fast