Short: CopyMem speedup patch by *Art(no Fake) Author: Arthur Hagen (*Art) Uploader: Christopher Naas (christon powertech no) Type: util/misc Architecture: m68k-amigaos CopyMemQuicker 2.8 (21 Aug 1994) Copyright © 1991, 1992, 1993, 1994 Arthur Hagen Parts of code: Copyright © 1985-1991 Commodore Business Machines Ltd. ====================================================== Posted to the Public Domain! (by permission of Commodore Norge A/S) *** BOGUS ALERT *** BOGUS ALERT *** BOGUS ALERT *** BOGUS ALERT *** A "CopyMemQuickerV3.0" was recently released by a Mr Cor van Dijk. This is NOT the original CopyMemQuicker, but an inferior hack. Even though this patch is under *some* circumstances quicker than both CopyMemQuicker and the system routines, it will in other cases be MUCH slower, due to inadequate trailing-byte-testing and surplus instruc- tions. The speed test program was left out of Mr Dijk's archive - I wonder why... And it is unsafe. If you run it twice, it will not just remove the patch, but also free the memory allocated for it. If another task is doing a large CopyMem(Quick) when you end this patch by running it again, chances are that everything will go @($#*&@(# when the memory being run is freed. Lame - really lame. As for the "Special implementation for 68010/68020 caches" the doc-file boast of, it will actually be SLOWER on a 68010, since a few of the 6-byte latch'able loops have been made larger - i.e. too large for the 6-byte prefetch latch of the 68010. And as for "Special implementation for 68020/30/40/60 pipelined fetch", this is pure bull. Instructions are NOT in any way optimised either by ensuring maximum prefetch or by mod16-aligning the code. The code will function all right on a 68000/68020-equipped machine, but is slower than necessary on all other configurations. What baffles me most, is that this bogus file was found on Safe Hex International's BBS. Until they stop distributing bogus software (and start paying for ShareWare they boast of having and using) I can only advice you NOT to trust anything from their BBS. Use VirusZ if you need a decent virus killer. Take my word for it. ***************** On to the program... ********************* Just another small thingy to put in your Amigas S:Startup-Sequence. This one will patch the exec.library functions CopyMem and CopyMemQuick to become faster than the regular ones. These functions are two of the cornerstone functions of the operating system, so most programs should benefit from this patch. I really wonder why the routines never were optimised by Commodore in the first place! Known bugs: None. Should work with all versions of the O/S from KickStart 1.2 upto and including 3.1, and with all processors from the 68000 upto and including the 68040. Even so, SOME virus killers might just report this patch as a virus - it isn't. And, remember, if you use this program, you do it totally at your own risk - I will under no circumstances be held responsible for what this program does to any system (It should be 100% compatible with ye olde routines, though - the only difference is that this code won't bug out if you try to copy 0 bytes, the original code does...). Speed increases may vary according to the processor, but some cycles should be should be shaved off on all systems. Expect between 0 and 50 percent speed increase, depending on alignment and copy size. The patch is optimised for all 68k processors (except the 68008), and relies upon the loop-mode and instruction cache for the faster pro- cessors. Usage: 1> CopyMemQuicker This will act like a switch, and turns the program on/off (but I don't know why it ever should be turned off). The memory used will NOT be freed when turning the function off, as some other part of your multitasking system might still be using the routine. I think you could live with the loss of 2-300 bytes, though... To test the routine on your machine, run "testit" from CLI (This requires that you have version 2.0 of the O/S). It might take some time to complete (depending on the processor), but should give fairly accurate test results. (The reason for the test taking longer time than the figures printed on-screen indicate, is that the time to execute the timing loop itself is timed and deducted before printing (to give as accurate a result as possible).) There WAS a severe bug in versions 1.4 and 1.5 of this patch, which caused a guru on all machines except those fitted with a 68010. This was due to a bug in the Aztec assembler, which could not handle ad- dresses like "*-2" properly. The bug has been worked around, and the current version has been properly tested before release. Sorry! Enjoy, *Art