On 2022-03-18, Johnny Billquist <bqt@softjar.se> wrote:
> On 2022-03-17 01:48, Simon Clubley wrote:
>> On 2022-03-16, Rich Alderson <news@alderson.users.panix.com> wrote:
>>>
>>> ALL the PDP-10 mnemonics for instructions which access memory have the same
>>> form (taking MOVE as a canonical example):
>>>
>>> MOVE load accumulator with contents of memory at effective address
>>> MOVEI load accumulator with immediate effective address calculation
>>> MOVES load accumulator with swapped halfwords of contents of memory
>>> at effective address
>>> MOVEM store accumulator into memory at effective address
>>>
>>> Look at the last character of the instruction. You don't even have to remember
>>> the difference between "load" and "store".
>>>
>>
>> Doesn't anyone else find it strange that the mnemonic across all
>> architectures is some variant of MOVE or MOV instead of COPY or CPY ?
>
> You mean across all of these two (or three) DEC architectures (PDP-10,
> PDP-11 and VAX)?
>
> Because some others use LOAD, LD, or some variant thereof. And then you
> have (as mentioned) the PDP-8 which only have TAD (two complement add),
> so if you want to read something out of memory, you better make sure the
> AC is 0 before you do. Which of course is helped by the store
> instruction which implicitly also clears the AC (DCA - Deposit and Clear
> AC).
> And there are other things out there as well, if we talk about "all
> architectures".
>

Yes, but that doesn't change my point that with every architecture
I know (both DEC and non-DEC) that uses a MOV/MOVE mnemonic variant,
then MOV/MOVE is actually a copy to destination instead as the source
is not destroyed during the copy.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-03-18 20:22, Simon Clubley wrote:
> On 2022-03-18, Johnny Billquist <bqt@softjar.se> wrote:
>> On 2022-03-17 01:48, Simon Clubley wrote:
>>> On 2022-03-16, Rich Alderson <news@alderson.users.panix.com> wrote:
>>>>
>>>> ALL the PDP-10 mnemonics for instructions which access memory have the same
>>>> form (taking MOVE as a canonical example):
>>>>
>>>> MOVE load accumulator with contents of memory at effective address
>>>> MOVEI load accumulator with immediate effective address calculation
>>>> MOVES load accumulator with swapped halfwords of contents of memory
>>>> at effective address
>>>> MOVEM store accumulator into memory at effective address
>>>>
>>>> Look at the last character of the instruction. You don't even have to remember
>>>> the difference between "load" and "store".
>>>>
>>>
>>> Doesn't anyone else find it strange that the mnemonic across all
>>> architectures is some variant of MOVE or MOV instead of COPY or CPY ?
>>
>> You mean across all of these two (or three) DEC architectures (PDP-10,
>> PDP-11 and VAX)?
>>
>> Because some others use LOAD, LD, or some variant thereof. And then you
>> have (as mentioned) the PDP-8 which only have TAD (two complement add),
>> so if you want to read something out of memory, you better make sure the
>> AC is 0 before you do. Which of course is helped by the store
>> instruction which implicitly also clears the AC (DCA - Deposit and Clear
>> AC).
>> And there are other things out there as well, if we talk about "all
>> architectures".
>>
>
> Yes, but that doesn't change my point that with every architecture
> I know (both DEC and non-DEC) that uses a MOV/MOVE mnemonic variant,
> then MOV/MOVE is actually a copy to destination instead as the source
> is not destroyed during the copy.

Ok. Fair enough. You have a point there. I've never considered it
strange, but I can see that it could be seen that way.

I would think of COPY as being much stranger though, even if it
semantically would be more appropriate.
You could also consider DEPOSIT, or STORE, or something along those
lines. But for some reason I prefer MOVE.

Johnny

On Friday, March 18, 2022 at 12:22:10 PM UTC-7, Simon Clubley wrote:

(snip)

> Yes, but that doesn't change my point that with every architecture
> I know (both DEC and non-DEC) that uses a MOV/MOVE mnemonic variant,
> then MOV/MOVE is actually a copy to destination instead as the source
> is not destroyed during the copy.

In the case of overlapping operands, the source might get,
at least partially, destroyed.

In the days of magnetic core memory, which has a destructive read
cycle, one could have designed processors that did clear the source.

On 03/19/22 01:21, gah4 wrote:
> On Friday, March 18, 2022 at 12:22:10 PM UTC-7, Simon Clubley wrote:
>
> (snip)
>
>> Yes, but that doesn't change my point that with every architecture
>> I know (both DEC and non-DEC) that uses a MOV/MOVE mnemonic variant,
>> then MOV/MOVE is actually a copy to destination instead as the source
>> is not destroyed during the copy.
>
> In the case of overlapping operands, the source might get,
> at least partially, destroyed.

The whole original point that was being made was that for sequences
like mov (a5)+. (a5), the (A5)+ always completes before the store to
(A5). That's how one would expect it to work, but it does require
a scratchpad store for the result of the first half of the expression.

Vax and pdp11 would work that way, as would later micros like 68000...

Chris

>
> In the days of magnetic core memory, which has a destructive read
> cycle, one could have designed processors that did clear the source.
>
>

In article <t12m4v$7g0$4@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2022-03-18, Johnny Billquist <bqt@softjar.se> wrote:
>> On 2022-03-17 01:48, Simon Clubley wrote:
>>> On 2022-03-16, Rich Alderson <news@alderson.users.panix.com> wrote:
>>>>
>>>> ALL the PDP-10 mnemonics for instructions which access memory have the same
>>>> form (taking MOVE as a canonical example):
>>>>
>>>> MOVE load accumulator with contents of memory at effective address
>>>> MOVEI load accumulator with immediate effective address calculation
>>>> MOVES load accumulator with swapped halfwords of contents of memory
>>>> at effective address
>>>> MOVEM store accumulator into memory at effective address
>>>>
>>>> Look at the last character of the instruction. You don't even have to remember
>>>> the difference between "load" and "store".
>>>>
>>>
>>> Doesn't anyone else find it strange that the mnemonic across all
>>> architectures is some variant of MOVE or MOV instead of COPY or CPY ?
>>
>> You mean across all of these two (or three) DEC architectures (PDP-10,
>> PDP-11 and VAX)?
>>
>> Because some others use LOAD, LD, or some variant thereof. And then you
>> have (as mentioned) the PDP-8 which only have TAD (two complement add),
>> so if you want to read something out of memory, you better make sure the
>> AC is 0 before you do. Which of course is helped by the store
>> instruction which implicitly also clears the AC (DCA - Deposit and Clear
>> AC).
>> And there are other things out there as well, if we talk about "all
>> architectures".
>>
>
>Yes, but that doesn't change my point that with every architecture
>I know (both DEC and non-DEC) that uses a MOV/MOVE mnemonic variant,
>then MOV/MOVE is actually a copy to destination instead as the source
>is not destroyed during the copy.

OMFG! Stop!

Your beloved 'C' language that you proselytize a posteriori is chock full
of pedant pondering palter. Ref::

MEMMOVE(3) BSD Library Functions Manual MEMMOVE(3)
---^^^^
NAME
memmove -- copy byte string
--------^^^^----^^^^
LIBRARY
Standard C Library (libc, -lc)

SYNOPSIS
#include <string.h>

void *
memmove(void *dst, const void *src, size_t len);
--------^^^^
DESCRIPTION
The memmove() function copies len bytes from string src to string dst. The two strings may overlap; the copy is
------------^^^^------------^^^^^^----------------------------------------------------------------------------^^^^
always done in a non-destructive manner.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

On 2022-03-19 02:21, gah4 wrote:
> On Friday, March 18, 2022 at 12:22:10 PM UTC-7, Simon Clubley wrote:
>
> (snip)
>
>> Yes, but that doesn't change my point that with every architecture
>> I know (both DEC and non-DEC) that uses a MOV/MOVE mnemonic variant,
>> then MOV/MOVE is actually a copy to destination instead as the source
>> is not destroyed during the copy.
>
> In the case of overlapping operands, the source might get,
> at least partially, destroyed.

That is just because the source would then also be the destination. And
it's being destroyed for being destination, so that don't count.

> In the days of magnetic core memory, which has a destructive read
> cycle, one could have designed processors that did clear the source.

The PDP-8 do. But then again, the instruction isn't called MOVE either.
And it only applies to the accumulator, which isn't in core.

But machines like the PDP-11 actually do take advantage of the
destructive behavior of core memory. Instructions which modifies the
destination will not refresh the old data back after it have been read
out, since a new value will be written soon anyway. (Think stuff like
ADD...)
If someone knows Unibus transactions, that's what the DATIP transaction
is there for.

Johnny

On 2022-03-19, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
> In article <t12m4v$7g0$4@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>
>>Yes, but that doesn't change my point that with every architecture
>>I know (both DEC and non-DEC) that uses a MOV/MOVE mnemonic variant,
>>then MOV/MOVE is actually a copy to destination instead as the source
>>is not destroyed during the copy.
>
> OMFG! Stop!
>

Yep. :-) I'm living rent-free in your head alright. :-)

> Your beloved 'C' language that you proselytize a posteriori is chock full
> of pedant pondering palter. Ref::
>
>
> MEMMOVE(3) BSD Library Functions Manual MEMMOVE(3)
> ---^^^^
> NAME
> memmove -- copy byte string
> --------^^^^----^^^^
> LIBRARY
> Standard C Library (libc, -lc)
>
> SYNOPSIS
> #include <string.h>
>
> void *
> memmove(void *dst, const void *src, size_t len);
> --------^^^^
> DESCRIPTION
> The memmove() function copies len bytes from string src to string dst. The two strings may overlap; the copy is
> ------------^^^^------------^^^^^^----------------------------------------------------------------------------^^^^
> always done in a non-destructive manner.
>
>

How does that invalidate my original observation ?

You've just found another example of it.

Thanks Brian. :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

In article <t1afeu$947$1@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2022-03-19, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
>> In article <t12m4v$7g0$4@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>>
>>>Yes, but that doesn't change my point that with every architecture
>>>I know (both DEC and non-DEC) that uses a MOV/MOVE mnemonic variant,
>>>then MOV/MOVE is actually a copy to destination instead as the source
>>>is not destroyed during the copy.
>>
>> OMFG! Stop!
>>
>
>Yep. :-) I'm living rent-free in your head alright. :-)
>
>> Your beloved 'C' language that you proselytize a posteriori is chock full
>> of pedant pondering palter. Ref::
>>
>>
>> MEMMOVE(3) BSD Library Functions Manual MEMMOVE(3)
>> ---^^^^
>> NAME
>> memmove -- copy byte string
>> --------^^^^----^^^^
>> LIBRARY
>> Standard C Library (libc, -lc)
>>
>> SYNOPSIS
>> #include <string.h>
>>
>> void *
>> memmove(void *dst, const void *src, size_t len);
>> --------^^^^
>> DESCRIPTION
>> The memmove() function copies len bytes from string src to string dst. The two strings may overlap; the copy is
>> ------------^^^^------------^^^^^^----------------------------------------------------------------------------^^^^
>> always done in a non-destructive manner.
>>
>>
>
>How does that invalidate my original observation ?
>
>You've just found another example of it.
>
>Thanks Brian. :-)

We should also abolish the CLR (clear) instruction too because it doesn't
"clear" a memory location or register, it zeroes it.

You're too chock full of pedant semantics. How about discussing something
useful instead of all the balderdash littering comp.os.vms? Of course, it
would probably mean that you would have had to use VMS, or develope product
or code, or provided support, or read a manual.

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.