Why is the processor instruction called "move", not "copy"?

Question

Many processors have an instruction called "move" (sometimes spelled MOV) which copies data from one location (the "source") to another (the "destination") in registers and/or memory. It does not do anything to the "source".

This is analogous to the "copy" (or "cp") command in a filesystem. In a "move" (or "mv") in the filesystem, the "source" would no longer be there. It is also contrary to the simple English meaning of "move"... after you move an object, it exists in its new location but no longer in its previous location.

So why call the instruction "move"?

Answer 1

Because "move" is the typical necessary function

It isn't always this way, of course, but especially with earlier CPUs, there were limited destinations for data from a particular operation - e.g., arithmetic results could only be in certain registers. Or in the other direction, certain functions could only operate on a few locations, typically registers or a "special" area of memory. So the point wasn't simply to copy in the sense that you might "copy" a file from one place to another, but more like:

I calculated a times b and now I need to move it from the register into the location in memory for c. Yes, the ALU register will still have it, and I could do something more with it there. But very often I will do a different calculation into that register now that I have moved the value elsewhere.

Assembly language programming, especially with a small CPU with a handful of key registers, is very different from high-level language programming - even though one can be translated into the other.

Answer 2

Besides the matter of semantics and personal taste, there’s a much more practical reason: some instructions sets claim to be copyrighted, as the Wikipedia Z80 article states:

Because Intel claimed a copyright on their assembly mnemonics, a new assembly syntax had to be developed for the Z80. This time a more systematic approach was used.

So, I think the mnemonic scheme of the instructions have to be unique and copyrightable.

Another important factor is the tendency to use 3-letter mnemonics in the 70’s instructions sets, probably to save source code memory and to make input quicker, while maintaining a degree of readability. In the 8080 instruction set, which uses 3 letters, the MOV mnemonic is easy understandable as "move", while the hypothetical COP mnemonic could have other meanings than "copy".

Answer 3

TL;DR

It's all about getting systematic, easy to memorise mnemonics, which may reflect some underlaying structure, but most important ease practical use. Exact language is not always a handy one - except you're asking a lawyer :)

---

So why call the instruction "move"?

Oh, the age old copy-vs-move question. A beloved friend :)

There are many different, equally plausible explanations, but before going into any it's quite important to keep in mind, that naming is not so much about being exact as being descriptive and distinctive. Also, meanings and usage evolves over time. And last but not least, people use terms they learned first.

It as well depends on the features a computer offers, like if it is a generic two address machine or restricted to certain transfers - which may as well result in other alternative, often forgotten here: Load/Store (*1) instead of Copy or Move. In a more generic view, they are all transfers - a word not really implying anything about what happens to the source (*2).

And, as with many items in computer history, the IBM /360 is deeply entrenched in the development of Move vs. Copy as well.

(points in no specific order)

Machine Structure

The copy issue usually only comes up when a machine offers more than a single accumulator. For example the Manchester Baby didn't have any mnemonics in today's notation, but as a single accumulator design some documentation used Load and Store for data transfer between accumulator and memory. A quite clear syntax - then again, not hard for a 7 instruction CPU :)

Then again, it's easy to complicate even a simple machine like that. The ERA/Atlas (Univac 1101) design(s) tried hard to confuse everyone by using a plethora of terms for transfers:

• Insert for memory (or Q) to accumulator (or Q),
• Replace for accumulator to memory,
• Transmit for accumulator to Q and,
• Store for Q (or lower half of A) to memory.

The Siemens 2002, a single accumulator machine, like the Baby and the ERA/Atlas, simplified it to an all covering Transfer for register/memory transfers ... well, plus Load to for bringing immediate values into registers (*3).

Machine operation

It can depend on the view designers had on the machine. Is it some 'fast' parts, like registers, handling temporary items that get loaded and stored, or how memory works. In fact, with core memory, data really got moved, as the original content was destroyed due the read operation and had to be restored.

Easy Recognition

Copy quite easy collides with compare when using the usual way of 'compacting' words by leaving out vowels. CP vs. CMP is rather close creating potential confusion. For machines not using the Load/Store metaphor, Move gives an easy way out, which brings...

Unique 'Encoding'

While the IBM 1401 forced the user to use single character symbols for instructions, it became already in the 1950s standard to name instructions in a way that the first letter of a mnemonic signals the general meaning or grouping, while the follow up letter(s) are used to specify variations (like L -> Load and LH -> Load Halfword) or to add readability.

Siemens 2002 and IBM /360 are great examples here as they both used that scheme throughout. On the /370 Load/Store as well as Move was used, depending on source/target. It works like this:

A*  -> Add
B*  -> Branch
C*  -> Compare
...
L*  -> Load to register from register/memory
M*  -> Memory to memory move
ST* -> Store register to Memory

The collision between add and and was solved by using N* for and-instructions.

Conclusion:

It was always more about having a nice decodable set of mnemonics than be super clear on the semantic side - after all, new usage creates new semantics, independent of prior application.

---

And then there is x86 History.

Where it All Started: Datapoint 2200

The Datapoint 2200 was developed by CTC as a tool to replace card based terminals (*4). Thus the language used for their assembler was somewhat /360 orientated, with transfer instructions called Load as they happened only between registers. In this context memory addressed by the memory pointer was just a special case. In fact, except for Jumps and Calls, the 2200 did not feature any memory addressing at all. For any random access H and L had to be loaded with separate 8 bit transfers. Further all mnemonics were created to directly represent an opcode, so each transfer had its own depending on source and destination (*5):

LA  # -> Load A with immediate #
LB  # -> Load B with immediate #
...
LAB   -> Load A with B
LBA   -> Load B with A
...
LAM   -> Load A with Memory (addressed by HL)
LBM   -> Load B with Memory (addressed by HL)
...
LMA   -> Load Memory (addressed by HL) with A
LMB   -> Load Memory (addressed by HL) with B
...

While an according assembler is thus straight forward and can be quite small (*6), this led to a 'mnemonic cloud' of 59 valid mnemonics for what most would considered a single or as maximum 4 different (*7) instructions.

Making it Smaller: Intel 8008

Intel's 8008 is a (mostly) straight forward implementation of the Datapoint 2200. No change so far compared to the Version 1 of the 2200.

Extending the Design: Intel 8080

The 8080 is a greatly enhanced version of the 8008. Most important due the addition of some 16 bit features (INX, DCX, DAD, LHLD, LXI, ...) or direct use of 16 bit addresses for other than Jump/Call (LDA, STA, SHLD, LHLD). In turn Intel simplified the mnemonic landscape by unifying all of the L** instructions into just two MVI for immediate to register and MOV for register to register (*8) transfer. Which register to be used was now encoded as parameters:

8008     8080
====     ====
LA  # -> MVI A,#
LAB   -> MOV A,B
LAM   -> MOV A,M
LMB   -> MOV M,B
...

It's easy to see that this is just a more verbose but still stringent 1:1 relation between a source line and the opcode to be generated. Intel still stopped not only short of integrating the new instructions into the MOV semantics, but even stayed back to use a single mnemonic for the new memory pointer access instructions or the direct load/stores which are at least in itself symmetric. So while cutting off 57 mnemonics, 6 more were clamped on.

Sidestep in Time Line: Zilog Z80

It seems, that the Z80 designers still had an eye on the Datapoint 2200 when designing their new CPU. Not only did they add a second register set, much like the 2200 Type 2, but they also went back to use Load to name all transfer instructions (*10). Just this time all the way with sensible parameter detection. So not only all 8080 MOV became LD, but all the separate mnemonics for other transfers were brought in line:

8008     8080        Z80
====     ====        ===
LA  # -> MVI  A,# -> LD  A,#
LAB   -> MOV  A,B -> LD  A,B
LAM   -> MOV  A,M -> LD  A,(HL)
         LDAX B   -> LD  A,(BC)
         STAX D   -> LD  (DE),A
         STA  adr -> LD  (adr),A
         LHLD adr -> LD  HL,(adr)

Zilog did not only straighten up all transfers, but as well moved conditionals out of the opcode column for all Calls, Jumps and Returns. While not being any result of the improved CPU itself, but a more capable assembler, it was quite used as argument to advertise how much more advanced and comfortable the new CPU was compared to its predecessor :)) (*10)

The End of All Future: Intel 8086

The 8086 was developed as a stop gap measure until the i432 was ready, with a clear focus on existing 8080 users needing an upgrade. Its designers took the same step as Zilog did, but being used to MOV as the generic instruction for data transfer they stayed with it - but now covering every variation. After all, with the huge number of varying addressing modes and data sizes, a simple one mnemonic one opcode with a hack for RI and RR decoding couldn't do it anymore.

And the rest is history, as they say.

---

Postscript

What I like about the question is that it leads to a core issue of our age: Real vs. Virtual world. Our language developed over millennia to describe physical objects that can only exist once, with a certain uniqueness - copying is an extraordinary process involving much effort. In the digital age, copying isn't special, but the very base of everything. Not only every data item gets copied uncountable times until it's displayed, but already the software doing so is a copy moved into memory from some storage, to be moved into the CPU to be executed.

Our legal system(s) are badly torn when trying to judge the use of software and data (aka content) in terms of physical items, when they are in reality much more like a spoken word.

Next to everything still struggles to handle this, language usage being right at the core and this question pointing to it.

---

*1 - Which then again opens the question what loading does to 'the item'.

*2 - Again, but less, as a transfer paper adds copies, while a transfer ticket allows to use another transport.

*3 - Well, (next to) all assembler instructions were in German, so TAS spelled out Transferiere AR in Speicherzelle - literally: Transfer AR (accumulator register) to Storage (memory) cell.

*4 - Back then a terminal wasn't a thing on your desk, but anything remote connected to a mainframe - like a card reader in some branch office where all transactions keypunched during the day were unloaded to be read remotely.

*5 - So at the very start 80 style assembler looked much more like later Motorola/MOS sources :))

*6 - Every OP is a 1:1 encoding of the mnemonic, so it's a straight lookup in a 4 byte table. Operands are only possible for certain opcodes and come in only two flavours: 8 bit immediate and 16 bit address.

The resulting assembler was small enough to run on the machine itself, with as low as 4 KiB memory.

*7 - Immediate, Register/Register, Memory/Register, Register/Memory

*8 - Including, like before, a memory cell addressed by HL as M.

*9 - It is sometimes said this was for copyright considerations, but it's hard to justify this in any way, as it wasn't just a renaming, but a complete reorganisation of the mnemonics as well as the assembly syntax. Also, descriptive names and sensible abbreviations thereof can't be trademarked or copyrighted in any country. If at all, the architecture might qualify - or the binary representation of opcodes, something DEC tried, without much success, for the VAX instruction set.

*10 - The Game Boy uses a LR35902 is a great example how a mostly 8080 like CPU can gain from just using Z80 syntax. Likewise when restricting Z80 assemblers to 8080 features.

Answer 4

This is actually a fun little question to answer, because I get to go into how a CPU actually works, including the major difference between typical CISC and RISC architectures. In computing it is generally accepted that "moving" data is actually a copy operation, with the original remaining until overwritten; even in the bad old days of literal core memory, where the core was erased by reading it, the memory hardware automatically rewrote it to preserve that idea.

I'll talk about RISC first, or to put it more precisely, the three-operand load-store architecture. Here, the ALU is connected to the register bank (which is typically relatively large, 16 words or so) and does not have a direct path to or from external RAM. The destination register for ALU ops is specified explicitly, so a typical instruction has three operands, two inputs and one output.

There is a separate subsystem, which can usually operate in parallel with the ALU, for getting data in and out of RAM. The instructions which activate this subsystem tend to carry mnemonics of "load" and "store", indicating the direction of data movement explicitly. But there usually is not a dedicated instruction for getting data from one register to another. Instead, an ALU instruction is chosen which doesn't modify the source data, and usually the assembler provides a "pseudo mnemonic" so the programmer doesn't have to remember how to do that. Often the CPU itself will then recognise this special case and avoid having to physically pass the data through an execution pipeline.

So in PowerPC he can write mr rD,rS and the assembler converts that to ori rD,rS,0. The mnemonics here are "move register" and "OR immediate". ARM has MOV for this purpose, but still uses "load" and "store" mnemonics for memory operations.

Typically CISC is instead a two-operand accumulator architecture. Here, the ALU notionally has two physical operand buses, one connected directly to the register bank and the other to complex addressing mode logic that can take data directly from a register or from RAM. The result bus leads directly from the ALU output to the write port of the register bank, and also to the writeback buffer on its way to RAM.

Consequently, the only way to get data into a register or back into RAM is to pass it through the ALU. So one of the ALU's functions is to ignore one of the operands and pass the other through unchanged. This function is selected by the MOV or MOVE opcode. A very similar ALU mode is responsible for the NOT and NEG instructions, except that the data is then not unchanged, but the data path is the same. One advantage of this approach is that the same complex addressing modes are available for any ALU operation, of which MOV is just one.

The 6502 is a one-operand accumulator architecture; because there is only one register (normally) accessible to the ALU, it doesn't need to be specified explicitly as the destination for ALU results. Hence all 6502 instructions have at most one operand following the opcode, though that operand may be either one or two bytes.

Its mnemonics therefore adopt the "load" and "store" convention also used in RISC, and to get data from one register to another the instructions have mnemonics beginning with T for "transfer" (rather than M for "move") followed by two letters indicating the source and destination (eg. TAX transfers from Accumulator to X Index). Indeed there are no 6502 mnemonics beginning with M at all.

However there are several that begin with C, and these are instructive as to why "copy" was not used in this CPU. CMP performs a comparison involving the accumulator, but CPX and crucially CPY perform similar comparisons involving the index registers. With all 6502 mnemonics being 3 letters, CPY would have been the obvious contraction of "copy".

Answer 5

Copy implies at the end you care about having 2 independent copies. Move implies at the end you care only about having the destination.

In assembly language, and particularly in register-starved architectures such as the 6502, you are moving (not wanting to copy) stuff around a lot because data has to be in a certain register to do something.

Additional implementation circuitry is needed to perform an actual move where the source contents are destroyed. Real moves would be something like "Copy src->dest, set src to 0" whereas simple copies are just the "Copy src->dest." So even though a move is what's meant, it's cheaper to implement as a copy.

Inconsistent words have been used in various assembly language mnemonics to describe what is a copy over the history of CPUs.

• 6502 uses "load" (LDA) and "transfer" (TXA, etc.)

• MIPS uses "load" (lui) and "move" (mfhi, mflo)

• Intel and many others used MOV, including the PDP-8 and VAX.

• 68000's was MOVE.

• Z80 had LD

• POWER's instructions use ld for load and st for store.

• The Intel 4004 has mnenomics that refer to "Load" (not "Store" though), Fetch, Read and Write.

So it's really up in the air.

Answer 6

Assembly language was initially just a tiny step up from machine programming and its main function was to convey a bit more meaning when drafting code and when dumping disassembly. As a result, it tended to be very matter of fact and directly and mechanically translatable with little effort to machine code.

If you take a look at the 8080 mnemonics, sort of the most widespread microcomputer mnemonics at their time due to CP/M's availability, you don't have various "overlaid" meanings of "LD" like the Z80 mnemonics had but rather every code point has its own mnemonic.

The operators working with fixed registers (add/subtract, even things like exchange-top-of-stack-with-memory-pointed-to-by-HL) don't name those fixed registers as operands but, if at all, have them hardwired into the mnemonic.

Mnemonics are generally only 3 letters (with exceptions "CALL", "PUSH", "SPHL", "XCHG", and "XTHL") for more compact printouts, with the 4 letter mnemonics having at most one argument.

To load register B with the value 7, you'd write MVI 7,B. The respective mnemonic CPI (if one wanted to use "copy" as basis for the mnemonics) is already taken by "compare accumulator to immediate value", with CPI 3 comparing the accumulator with the value 3 and setting the flags according to the result of the comparison.

As a note aside, there are CP, CPE, and CPO instructions for "call when positive, parity even, parity odd". This kind of high density in the "CP" realm may well have triggered a desire to search for a different synonym.

Zilog did considerably decompressed mnemonics for its upwards compatible Z80 processor (where most of the data transfer stuff ran through LD) even though TDL assembly mnemonics designed an Intel-style mapping of the Z80 machine code.

"Load" and "store" were actually also in use early on but more used for indicating memory->register and register->memory transfers, respectively. So instructions between registers were looking for alternative names early on.

The strong move/copy distinction made it into computer science later than assembly language, with the UNIX cp/mv instructions for entire files and with the copy/move/cut/paste idioms from early graphical user interfaces.

Answer 7

At first glance it just seems a matter of taste.

The question actually starts off with an incorrect presumption: "The" "processor" instruction isn't called MOV(e), it's on some instruction sets where it was called move, on others there is load, store, and transfer.

Having grown up with 6502, I totally feel that "load" for load register from memory vs. "store" to store register into memory vs. "transfer" between registers is the best way to put it. Looking at the PDP-8 instruction set, apart from the odd fact that it has no no "load" at all (you always use TAD, add), it had "store" and "transfer" (though no other general register to transfer to).

"Register transfer" is a well understood concept, and usually thought different from "load" and "store" from and to memory, as the external address / data bus is not involved in the transfers.

But now setting my quaint taste aside, I can also see the rationale for a single op-code mnemonic "MOV" (copy or transfer) because the source and destination are simply thought to be parameters, which is just an extension of the "addressing modes" (immediate, absolute/direct, indirect, indexed ...) there already are. Just include the registers into the domain of source and destinations, and hence a single "move" opcode is elegant, it's parameter polymorphic in what it does exactly.

If you continue thinking along those lines, understanding that "load" and "store" and "transfer" had already been used and have specific meanings, you'll begin to appreciate that for the abstract generalization of these opcodes, a new word had to be found.

The word "copy" (vs. move) may be known from the file system world, but copy is too specific because it implies that after the operation you will have 2 copies of the value, and that might not even always be true. For example, there are registers that clear themselves once they have been read (e.g., in memory-mapped I/O chips as were common in the 6502 world). So, the closest common English word to transfer is move.

I believe thinking that way it all makes a lot of sense.

Now you can wonder why they didn't also rename the "jump" instruction into "move" source to IP?

Answer 8

In many machines, there are three primary forms of operation that cause something to hold a copy of something else:

1. Causing a register to hold a copy of something in memory, called "loading".
2. Causing memory to hold a copy of something in a register, called "storing".
3. Causing one register to hold a copy of another, called ... ?

All three operations involve copying something. If one recognizes that the first two operands move something to a new location but leave behind a copy that may or may not be useful, then describing the third operation as "Move a value from one register to another, leaving a copy behind" would fit that pattern.

Note that in terms of semantic usage, code may sometimes want to make a backup copy of the value in a register but remain focused on the primary copy, but there's generally no need to have instruction sets worry about whether purpose of an operation is to have two copies of a value, as opposed to having the value available in a new place, while a useless copy is left behind.

Answer 9

It is important to notice that the MOV instruction isn't actually a single one : it actually corresponds to different opcodes according to what you're handling and which addressing mode you follow.

On the most rudimentary processors, if you can almost always read/store values from/to memory, you're very often unable to perform direct transfers from a register to another one, especially because these registers are meant to retain the read value to store it again elsewhere. And because of this same reason, you're almost never able to directly move/copy a value from an address to another one in a single operation (requires two distinct bus transactions with value retainment in between).

On 6809 processors, we had:

LDx : Load - Load register "x" with a value from memory (even immediate) ;
STx : Store - Store register "x"'s content in memory ;
TFR x,y : Transfer - Copy content of register x into register y ;
EXG x,y : Exchange - Swap content of register x and y.

This makes senses but all combinations are available, and it remains consistant as long as instructions set and addressing modes are orthogonal enough. When there's too many exceptions to this schema, all these operations are considered as moves in a global way. Thus the assembler mnemonic MOV, which then recognizes what's to be done by looking at its operands.

But this has never been a move by opposition with a copy.