On 10/20/2020 8:54 AM, Charles Mills wrote:
@Ed, can you elaborate a little on your reasoning? (Not doubting it; just
curious.) Is it that the interruptibility provides a significant improvement
over MVCL? Or the support for lengths greater than 16M? Or ... ?
MVCL with anything other than zero pad requires an extra instruction and
we've been burned more than once with >16M lengths not being handled right.
When I asked Dr. Shum about move strategies he seemed to indicate that for
data that was already or would soon anyway be in cache an MVC loop was
generally faster than MVCL. (I did not ask about MVCLE at the time; not sure
why. He did not suggest it.)
Oh yes, we have code in a performance path that moves 4K blocks on a 4K
boundary using 16 256-byte MVCs.
I did say "almost" exclusively... ;-)
What I meant to say is we've replaced nearly all MVCLs with MVCLEs. The
biggest exception is the x'B0' and x'B8' stuff for non-padded moves we
use in a few places. To be honest, we didn't even research those to see
if there were MVCLE equivalents. We just left that working code alone...
--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/
--------------------------------------------------------------------------------
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.
