Answering msg from Paul Edwards to Frank Malcolm,
on Sunday January 07 1996 at 21:12

 PE> Jesus fucking Christ!  I've been doing extensive work and test
 PE> on PDPCLIB today, and hours on one particular problem.  PDPCLIB
 PE> is absolutely creaming the opposition, except for ONE spot.  And
 PE> that was when I had a buffer of 4096, and was reading 1024 bytes
 PE> at a time.  When that happened, the opposition was getting in at
 PE> 5% - 10% improvement in ELAPSED time of my whole program (reading
 PE> from a RAM disk).  This is straight reading from disk into
 PE> an internal buffer, and then copying from memory to memory, a
 PE> fixed length, unlike the previous problem.

 PE> Anyway, after much trying and trying to get my code to go faster,
 PE> I eventually tried, just on the offchance, I didn't really think
 PE> it would make a difference, I tried padding my memory buffer to
 PE> a doubleword boundary, and voila, problem solved!!!  God only
 PE> knows what the REAL % difference is of the REP MOVSD or MOVD or
 PE> whatever it is!

Yes, you can incur severe delays if you use REP STOS[W|D] and REP MOVS[W|D]
if your source and/or destination addresses are misaligned.

A good rule of the thumb is to align everything to a word boundary. If you
are specifically creating 386+ code (as you are in this case), then a dword
boundary is far better.

There was some discussion in the newsgroups a while back about this; the
"can I code a better memmove function?" thread pops up every now
and then.

---