Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

share|improve this question
2  
Wikipedia says: "The word move for this operation is, strictly speaking, a misnomer: it has little to do with the physical concept of moving an object from A to B, with place A then becoming empty; a MOV instead makes a copy of the state of the object at A and overwrites the old state of B in this process. This is reflected in some other assembly languages by using words like load, store or copy instead of move.". –  Uwe Keim Dec 24 '13 at 11:32
    
@UweKeim hmm, I've googled for explanation before the question but wasn't fed with this article. Anyway this explains the current state but doesn't give a clue for real origins... –  Netch Dec 24 '13 at 12:35
2  
@gnat I had meant "Instruction Set Architecture", not an ISA bus. I've reedited it. –  Netch Dec 24 '13 at 12:37
    
@Netch thanks! I somehow managed to miss that in a large list of disambiguations at Wikipedia –  gnat Dec 24 '13 at 12:41
    
I doubt there's any way to find out why it was originally called a "move" instead of "copy", but speculating is fun. On the wikipedia page for assembly language, it describes MOV as an operation for "moving a copy of the data", which is an interesting interpretation. Another possibility is that in terms of actual usages of MOV, the operation is conceptually a movement of data; that we don't care about the source any more. –  Ben Lee Dec 30 '13 at 22:48

3 Answers 3

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.

share|improve this answer
    
I don't have any evidence to support your answer, but it certainly sounds just right. Load/Store operations are going to take a different path in the CPU/microcode due to going to memory/cache, but moving between registers may well be single-cycle (no need to wait on other pipeline stages) and therefore worth differentiating. But this doesn't explain move-vs-copy... –  JBRWilkinson Dec 24 '13 at 22:52
    
Agreed. Consider e.g. memory-mapped input devices. Reading a source location can modify it - e.g. discarding the item that you read from a hardware queue, replacing it with the next queued item. That sounds like a move rather than a copy - the source no longer holds that information, only the destination does. And that behavior isn't decided by the CPU, it's decided by that memory-mapped device. –  Steve314 Dec 24 '13 at 23:48
    
Assembly languages use mnemonics that are "CPU-centric". That is, everything is named from the perspective of the CPU's registers. Thus, "load" usually copies a value into a register, whereas "store" usually copies one from a register to memory. What then to call copying a value from one register to another? "Move" is an obvious choice. If the same microcode operation performs both (as in the 68000), "move" is a more generic choice for load/store. "Copy" could have been used but may be redundant since there is really no such thing as a true "move", where the source is left empty. –  DocSalvager Dec 28 '13 at 15:47
    
@DocSalvage: If a 32-bit register is a fixed bunch of 32 flip flops or latches that will always exist, "move" doesn't necessarily make sense. In architectures with register renaming, however, a "move" operand which would also invalidate the source could improve efficiency by freeing up a virtual register. I've never heard of such a thing being done, but I don't know any architectures which were designed with register-renaming in mind. –  supercat Dec 28 '13 at 18:17
    
@supercat: In computer hardware, all registers and all memory locations contain a value at all times. There is actually no such thing as "null" or "empty". We use arbitrary conventions to signify when the register or memory contents are invalid. Very often, we let "0" signify "null" but not always. The "null" state of a block of memory for example may be indicated by start and ending addresses stored in another location. There are numerous other techniques as well. Ultimately, language mnemonics are arbitrary though we try for the most widely understood option. –  DocSalvager Dec 29 '13 at 0:50

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).

share|improve this answer

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.

share|improve this answer
3  
how does this answer the question asked? –  gnat Dec 24 '13 at 12:07
2  
The only sentence ending with a question mark is 'But why it's still widely used and not replaced with "copy" or "store"?'. –  Idan Arye Dec 24 '13 at 12:12
2  
It does not explain why the instruction has been named such to begin with, by countless ISAs designed from scratch (i.e. without backwards compatibility constraints) over many decades. Also, if a vendor wanted to change the mnemonic despite backwards compatibility, they could provide an alias and promote its use. –  delnan Dec 24 '13 at 12:14
1  
What does "OP" stand for? And, I haven't seen a real explanation. –  Netch Dec 24 '13 at 15:47
1  
I'm the original poster and I shall state the copying between memory cells in S/360 is not "slightly different operation" but is only special case of the same copying. The question is so still unsolved. –  Netch Dec 24 '13 at 19:42

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.