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
|
