In quite many assemblers, a value copying instruction is usually named "MOV" and its description in manuals usually also contains "move" (however, other words can be used, like "load", "store", "extract", etc.) It's uncommon to find an ISA ) which doesn't follow this convention.
On the other hand, in other contexts, "move" differs from "copy" in sense that source is destroyed (for example, "mv" vs. "cp" in Unix, Move[F6] in Norton Commander and clones, etc.) Assembler's "move" really has semantic "copy", keeping the source value intact.
I've found that this has started at least since IBM 1401 (1959), but, IBM 360 used this word only for in-storage copying, but not for operations between registers and storage (which used "load" and "store"). But why it's still widely used and not replaced with "copy" or "store"?
Best Answer
In some instruction sets, there exist distinct instructions to load a register from memory, store a register to memory, or transfer things among registers. While some assembly language forms use the verb "load" for everything (e.g. Zilog's Z80 mnemonics use
ld a,(1234h),ld (1234h),aandld a,b) , and some use "T"ransfer (e.g. the 6502 with TXA for "transfer X to A"), some use "move" for regster-to-register operations to distinguish them from loads and stores. If one has an instruction format like the 68000 which uses the same general instruction form for register-to-register, register-to-memory, memory-to-register, and even memory-to-memory operations, the verb "move" is probably a better general-purpose verb than any of the alternatives.I have no idea about minicomputer or mainframe instruction sets prior to the 8080, but the 8080 used "load" and "store" for most memory-access instructions and "mov" for register-to-register instructions, but most instructions which could operate on an arbitrary 8-bit register could also operate on "M", which was the memory location addressed by HL, so a "MOV" to or from "M" would actually behave as a load or store.
As for the distinction between "copy" and "move", I suspect that has a lot to do with the fact that code can neither create nor destroy registers; they just exist. In describing the behavior of the code sequence
mov bx,ax / mov ax,1234, does it make more sense to say the first instruction copies bx to ax, and the second instruction destroys the value inaxand replaces it with the value 1234, or does it make more sense to view the first instruction as having moved the value from bx to ax (making the value in ax a "don't care"), and the second instruction loads ax (which had been don't-care) with 1234? Sometimes the source registers is still meaningful after a register-transfer instruction, but since there's nothing in the instruction set to indicate whether it will be, and in many common situations it isn't, "move" seems reasonable.