MOVE - when addr1 = addr2

[dxforth]

The spec for MOVE says do nothing when u=0.

But what about addr1 = addr2 ? The spec doesn't mention it so the presumption
is the copy should go ahead.

I don't recall seeing a MOVE implementation that tests addr1 = addr2, so no
past practice that I'm aware. The only situation I can think where it might
be a problem is 'ROM over RAM' i.e. where the read is from ROM but the write
is to RAM. In such case however one might opt to use CMOVE instead which is
typically dumb.

Any thoughts/experience?

[Anton Ertl]

The specification says to copy, and what the result is. So copying is
certainly a correct way to implement it. Checking for addr1=addr2
seems to be a waste of time to me; it is unlikely to be a
frequent-enough case to merit optimizing it, and when it occurs, it
may be such a case as you describe, where the prorammer's intention is
to actually make the copy. So there's two reasons against
special-casing the addr1=addr2 case.

OTOH, if you feel the urge to special-case this case, and you know
that your MOVE is only used for memory that behaves like conventional
RAM, not doing anything satisfies the description of the result:

|After MOVE completes, the u consecutive address units at addr2 contain
|exactly what the u consecutive address units at addr1 contained before
|the move.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

[dxforth]

On 19/09/2021 01:12, Anton Ertl wrote:
> dxforth <dxf...@gmail.com> writes:
>>The spec for MOVE says do nothing when u=0.
>>
>>But what about addr1 = addr2 ? The spec doesn't mention it so the presumption
>>is the copy should go ahead.
>>
>>I don't recall seeing a MOVE implementation that tests addr1 = addr2, so no
>>past practice that I'm aware. The only situation I can think where it might
>>be a problem is 'ROM over RAM' i.e. where the read is from ROM but the write
>>is to RAM. In such case however one might opt to use CMOVE instead which is
>>typically dumb.
>>
>>Any thoughts/experience?
>
> The specification says to copy, and what the result is. So copying is
> certainly a correct way to implement it. Checking for addr1=addr2
> seems to be a waste of time to me; it is unlikely to be a
> frequent-enough case to merit optimizing it, and when it occurs, it
> may be such a case as you describe, where the prorammer's intention is
> to actually make the copy. So there's two reasons against
> special-casing the addr1=addr2 case.
>
> OTOH, if you feel the urge to special-case this case, and you know
> that your MOVE is only used for memory that behaves like conventional
> RAM, not doing anything satisfies the description of the result:
>
> |After MOVE completes, the u consecutive address units at addr2 contain
> |exactly what the u consecutive address units at addr1 contained before
> |the move.

MOVE checking for overlap is an optimization difficult to justify on
the frequency! Given ANS mandates the test, exiting early amounts to
a conditional branch typically not taken - a small cost should one
choose to implement it.

old code:

mov dx,di
sub dx,ax
cmp dx,cx
jc bmovu ; overlap and moving-up

new code:

mov dx,di
sub dx,ax
jz ... ; dest=src
cmp dx,cx
jc bmovu ; overlap and moving-up


What prompted me to consider the addition was this:

(.) 20 (S.R) ( adr len)

(.) converts a number to a string in the HOLD buffer and (S.R) right-
justifies it with blanks whose result is also in the HOLD buffer.
Since the source string for (S.R) was already in place, the copy phase
which involved MOVE became redundant.