Why is the copying instruction usually named MOV?

Question

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"?

Answer 1

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),a and ld 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 in ax and 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.

Answer 2

You are certainly right. Most if not all instances of a mov instruction are actually a copy.

Some dont actually even have a mov it is a pseudo instruction for

add dest=source+zero.

Also understand that the ascii syntax is arbitrary, the machine code means something and is defined and fixed for that processor. Most if not all of the time the processor creator/vendor creates a syntax in part to define the instruction set (machine code) and in part to define a syntax that works with a tool they also created or commissioned to convert that assembly language into machine code for their processor. You can certainly for example go into the gnu assembler (which has a tendency to do its own thing and not follow the processor vendors syntax anyway) and add a copy pseudo instruction.

Use cases: well these days most assembly language code is compiler generated, and the mov instruction is most often used to actually move a value from one register to another so that the source register (memory location, etc) can be re-used. For reasons of the calling convention for that processor or because some instructions or instruction sets are not orthogonal, so you have to move things around. Certainly there are times where a copy of a value is desired and the mov may be used to make that copy.

I doubt seriously we will ever know what individual or team came up with the term first and why they chose move over copy. Because we have become accustomed to it we tend to re-use it with every new instruction set. As already mentioned some instruction sets use register based load and store instructions where one operand is a register and the other is an address, and mov for just the register to register case(s). And other instruction sets use mov for register or mem for either operand. Although you can certainly add copy to any/many of the open source assemblers, getting traction on its use will be more difficult. If you work somewhere where you have control over the original syntax (work for a place making a new processor) where you can dictate the register to register move is called copy, you are likely to end up with the gnu assembler for example including a mov since there is so much of a comfort level with it someone will add it (and gas often goes against the processor vendors syntax and does its own thing).

Answer 3

Replacing an instruction means breaking backward compatibility. An assembler with the new syntax will not be able to assemble code written with the old syntax - unless that code doesn't use that instruction(and the only place where you'll see an assembly code that doesn't use MOV is in syntax examples that show other instructions...)

Compilers usually generate assembly code and automatically pass it to the assembler, so they'll have to be modified as well to fit the new assembler. If a language allows inline assembly, old source code that uses inline assembler with MOV instructions won't work anymore.

So, we are talking about a gigantic code breakage, and for what? it won't make the language any more readable, because unlike some high level language you have no chance of telling what an assembly code does without knowing assembly, and if you know assembly you know what MOV does.

Huge cost with zero gain easily explains why the instruction hasn't been renamed.