Copymem Quick & Big Released!

[SpeedGeek]

** 8TH NEWS UPDATE **

CMQ&B040_SAFER2.3 released!

First safer version
- Added code to test for equal source and destination addresses
and avoid using Move16 for this specific case.
- Added code to test specified destination addresses and avoid
using Move16 for those cases.

[PeterK]

Originally Posted by SpeedGeek

CMQ&B040_SAFER2.3 released!
- Added code to test for equal source and destination addresses
and avoid using Move16 for this specific case.

Strange! Are you going back to 2.1 now?

v2.2 minor change
- Removed "Move16 Bug" detection code. This was a blunder due to
Ax = Ay meaning the same registers rather than the same addresses.

From the Autodocs for CopyMem() and CopyMemQuick():

Arbitrary overlapping copies are not supported.

... and the address registers are always A0 and A1, never the same.

So, what is your specific case with Move16 now?

[SpeedGeek]

Originally Posted by PeterK

Strange! Are you going back to 2.1 now?


From the Autodocs for CopyMem() and CopyMemQuick():

... and the address registers are always A0 and A1, never the same.

So, what is your specific case with Move16 now?

Yes, partially going back to 2.1 now for this specific case:

4.) If a MOVE16 instruction has both source & destination addresses
hitting in the same copyback mode cache line (effectively a cache line
push), the source is dirty in the cache line, and the access is write-
protected, then the dirty cached data may be lost.

I already explained that this is a "User Program Bug". The problem is that with Move16 there can be a loss of data which will not occur with Move.l or Movem when this bug occurs.

[PeterK]

Originally Posted by SpeedGeek

4.)If a MOVE16 instruction has both source & destination addresses
hitting in the same copyback mode cache line (effectively a cache line
push), the source is dirty in the cache line, and the access is write-
protected, then the dirty cached data may be lost.

I already explained that this is a "User Program Bug".

Yes indeed, that must be a bug in the CopyMemQuick() calling program, I guess. If it tries to copy the complete cache line over itself, then this would violate the rules for CopyMemQuick() as explained in the Autodocs, because it's an unsupported overlapping copy.

But if the calling program would just try to copy a small portion of the same cache line without using overlapping source and destination addresses then you will probably never use Move16 for that purpose, but just Move.l instructions. Right?