¿Por qué la instrucción de copia suele llamarse MOV?

En muchos ensambladores, una instrucción de copia de valores generalmente se denomina "MOV" y su descripción en los manuales también suele contener "mover" (sin embargo, se pueden usar otras palabras, como "cargar", "almacenar", "extraer", etc. ) Es raro encontrar un ISA ) que no sigue esta convención.

Por otro lado, en otros contextos, "mover" difiere de "copiar" en el sentido de que la fuente se destruye (por ejemplo, "mv" frente a "cp" en Unix, Move [F6] en Norton Commander y clones, etc. ) El "movimiento" del ensamblador realmente tiene una "copia" semántica, manteniendo intacto el valor fuente.

Descubrí que esto comenzó al menos desde IBM 1401 (1959), pero IBM 360 usó esta palabra solo para copiar en el almacenamiento, pero no para operaciones entre registros y almacenamiento (que usaba "cargar" y "almacenar") . Pero, ¿por qué todavía se usa ampliamente y no se reemplaza con "copiar" o "almacenar"?

history assembly

— Netch
fuente

Wikipedia dice : "La palabra mover para esta operación es, estrictamente hablando, un nombre inapropiado: tiene poco que ver con el concepto físico de mover un objeto de A a B, con el lugar A que luego se vacía; un MOV en su lugar hace una copia de "el estado del objeto en A y sobrescribe el estado anterior de B en este proceso. Esto se refleja en algunos otros lenguajes de ensamblaje mediante el uso de palabras como cargar , almacenar o copiar en lugar de mover".

— Uwe Keim

@UweKeim hmm, busqué en Google la explicación antes de la pregunta pero no me alimentaron con este artículo. De todos modos, esto explica el estado actual, pero no da una pista de los orígenes reales ...

— Netch

@gnat Me refería a "Arquitectura de conjunto de instrucciones", no a un bus ISA. Lo he reeditado.

— Netch

@Netch gracias! De alguna manera logré señorita que en una larga lista de desambiguaciones en Wikipedia

— mosquito

Dudo que haya alguna forma de averiguar por qué originalmente se llamaba "movimiento" en lugar de "copia", pero especular es divertido. En la página de Wikipedia para lenguaje ensamblador , describe MOV como una operación para "mover una copia de los datos", lo cual es una interpretación interesante. Otra posibilidad es que, en términos de usos reales de MOV, la operación es conceptualmente un movimiento de datos; que ya no nos importa la fuente.

— Ben Lee

Respuestas:

En algunos conjuntos de instrucciones, existen instrucciones distintas para cargar un registro de la memoria, almacenar un registro en la memoria o transferir cosas entre registros. Mientras que algunas formas en lenguaje ensamblador usan el verbo "cargar" para todo (por ejemplo, el uso de mnemónicos Z80 de Zilog ld a,(1234h), ld (1234h),ay ld a,b), y algunas usan "T" ransfer (por ejemplo, el 6502 con TXA para "transferir X a A"), algunas usan "mover" para operaciones de registro a registro para distinguirlos de cargas y tiendas. Si uno tiene un formato de instrucción como el 68000 que usa la misma forma de instrucción general para operaciones de registro a registro, registro a memoria, memoria a registro e incluso memoria a memoria, el verbo "mover" es probablemente un mejor verbo de propósito general que cualquiera de las alternativas.

No tengo idea acerca de los conjuntos de instrucciones de minicomputadora o mainframe anteriores al 8080, pero el 8080 usaba "cargar" y "almacenar" para la mayoría de las instrucciones de acceso a memoria y "mov" para las instrucciones de registro a registro, pero la mayoría de las instrucciones que podían funcionar en un registro arbitrario de 8 bits también podría funcionar en "M", que era la ubicación de memoria dirigida por HL, por lo que un "MOV" hacia o desde "M" en realidad se comportaría como una carga o almacenamiento.

En cuanto a la distinción entre "copiar" y "mover", sospecho que tiene mucho que ver con el hecho de que el código no puede crear ni destruir registros; ellos solo existen. Al describir el comportamiento de la secuencia de código mov bx,ax / mov ax,1234, ¿tiene más sentido decir que la primera instrucción copia bx a ax, y la segunda instrucción destruye el valor axy lo reemplaza con el valor 1234, o tiene más sentido ver la primera la instrucción como haber movido el valor de bx a ax (haciendo que el valor en ax sea "no importa"), y la segunda instrucción carga ax (que no había sido importada) con 1234? A veces, los registros de origen siguen siendo significativos después de una instrucción de transferencia de registro, pero dado que no hay nada en el conjunto de instrucciones que indique si será,

— Super gato
fuente

No tengo ninguna evidencia que respalde su respuesta, pero ciertamente parece correcta. Las operaciones de carga / almacenamiento van a tomar una ruta diferente en la CPU / microcódigo debido a la memoria / caché, pero el movimiento entre registros puede ser de un solo ciclo (no es necesario esperar en otras etapas de la tubería) y, por lo tanto, vale la pena diferenciarlo. Pero esto no explica mover-vs-copiar ...

— JBRWilkinson

Convenido. Considere, por ejemplo, dispositivos de entrada mapeados en memoria. La lectura de una ubicación de origen puede modificarla, por ejemplo, descartando el elemento que leyó de una cola de hardware, reemplazándolo por el siguiente elemento en cola. Eso suena como un movimiento en lugar de una copia: la fuente ya no contiene esa información, solo el destino lo hace. Y ese comportamiento no lo decide la CPU, lo decide ese dispositivo mapeado en memoria.

— Steve314

Los lenguajes de ensamblaje usan mnemónicos que están "centrados en la CPU". Es decir, todo se nombra desde la perspectiva de los registros de la CPU. Por lo tanto, "cargar" generalmente copia un valor en un registro, mientras que "almacenar" generalmente copia uno de un registro a la memoria. ¿Entonces qué llamar copiar un valor de un registro a otro? "Mover" es una opción obvia. Si la misma operación de microcódigo realiza ambas (como en el 68000), "mover" es una opción más genérica para cargar / almacenar. Se podría haber usado "Copiar", pero puede ser redundante ya que realmente no existe un "movimiento" verdadero, donde la fuente se deja vacía.

— DocSalvager

@DocSalvage: Si un registro de 32 bits es un grupo fijo de 32 flip flops o pestillos que siempre existirán, "mover" no necesariamente tiene sentido. Sin embargo, en arquitecturas con cambio de nombre de registro, un operando de "movimiento" que también invalidaría la fuente podría mejorar la eficiencia al liberar un registro virtual. Nunca he oído hablar de algo así, pero no conozco ninguna arquitectura diseñada con el cambio de nombre de registro en mente.

— supercat

@supercat: en el hardware de la computadora, todos los registros y todas las ubicaciones de memoria contienen un valor en todo momento. En realidad no existe tal cosa como "nulo" o "vacío". Utilizamos convenciones arbitrarias para indicar cuando el registro o el contenido de la memoria no son válidos. Muy a menudo, dejamos que "0" signifique "nulo", pero no siempre. El estado "nulo" de un bloque de memoria, por ejemplo, puede indicarse mediante direcciones iniciales y finales almacenadas en otra ubicación. Existen numerosas otras técnicas también. En última instancia, la mnemotecnia del lenguaje es arbitraria, aunque intentamos la opción más ampliamente comprendida.

— DocSalvager

Ciertamente tienes razón. La mayoría, si no todas las instancias de una instrucción mov son en realidad una copia.

Algunos ni siquiera tienen un movimiento, es una seudoinstrucción para

add dest=source+zero.

También comprenda que la sintaxis ascii es arbitraria, el código de máquina significa algo y está definido y reparado para ese procesador. La mayoría, si no todo el tiempo, el creador / vendedor del procesador crea una sintaxis en parte para definir el conjunto de instrucciones (código de máquina) y en parte para definir una sintaxis que funciona con una herramienta que también crearon o comisionaron para convertir ese lenguaje ensamblador en máquina código para su procesador. Ciertamente, por ejemplo, puede ingresar al ensamblador gnu (que tiene la tendencia de hacer lo suyo y no seguir la sintaxis de los vendedores del procesador de todos modos) y agregar una pseudoinstrucción de copia.

Casos de uso: en la actualidad, la mayoría de los códigos de lenguaje ensamblador se generan mediante compiladores, y la instrucción mov se usa con mayor frecuencia para mover realmente un valor de un registro a otro para que el registro de origen (ubicación de memoria, etc.) pueda reutilizarse. Por razones de la convención de llamadas para ese procesador o porque algunas instrucciones o conjuntos de instrucciones no son ortogonales, por lo que debe mover las cosas. Ciertamente, hay momentos en los que se desea una copia de un valor y el mov se puede usar para hacer esa copia.

Dudo seriamente que alguna vez sepamos qué individuo o equipo se le ocurrió el término primero y por qué eligieron mover sobre la copia. Debido a que nos hemos acostumbrado, tendemos a reutilizarlo con cada nuevo conjunto de instrucciones. Como ya se mencionó, algunos conjuntos de instrucciones utilizan la carga basada en registros y las instrucciones de almacenamiento donde un operando es un registro y el otro es una dirección, y se mueve solo para que el registro registre los casos. Y otros conjuntos de instrucciones usan mov para el registro o mem para cualquier operando. Aunque ciertamente puede agregar una copia a cualquiera / muchos de los ensambladores de código abierto, será más difícil lograr su uso. Si trabaja en un lugar donde tiene control sobre la sintaxis original (trabaja para un lugar que crea un nuevo procesador) donde puede dictar el registro para registrar el movimiento, se llama copia,

— viejo contador de tiempo
fuente

-4

Reemplazar una instrucción significa romper la compatibilidad con versiones anteriores. Un ensamblador con la nueva sintaxis no podrá ensamblar código escrito con la sintaxis anterior, a menos que ese código no use esa instrucción (y el único lugar donde verá un código de ensamblaje que no usa MOVes en ejemplos de sintaxis que muestran otras instrucciones ...)

Los compiladores generalmente generan código de ensamblaje y lo pasan automáticamente al ensamblador, por lo que también deberán modificarse para que se ajusten al nuevo ensamblador. Si un idioma permite el ensamblaje en línea, el antiguo código fuente que usa el ensamblador en línea con MOVinstrucciones ya no funcionará.

Entonces, estamos hablando de una rotura de código gigantesca, ¿y para qué? no hará que el lenguaje sea más legible, porque a diferencia de un lenguaje de alto nivel, no tiene la posibilidad de decir qué hace un código ensamblador sin conocer el ensamblado, y si conoce el ensamblaje, sabe lo que MOVhace.

El costo enorme con ganancia cero explica fácilmente por qué no se ha cambiado el nombre de la instrucción.

— Idan Arye
fuente

¿Cómo responde esto a la pregunta que se hace?

— mosquito

La única oración que termina con un signo de interrogación es 'Pero, ¿por qué todavía se usa ampliamente y no se reemplaza con "copiar" o "almacenar"?

— Idan Arye

Para empezar, no explica por qué la instrucción se ha denominado así, por innumerables ISA diseñados desde cero (es decir, sin restricciones de compatibilidad con versiones anteriores) durante muchas décadas. Además, si un proveedor quisiera cambiar la mnemotecnia a pesar de la compatibilidad con versiones anteriores, podría proporcionar un alias y promover su uso.

¿Qué significa "OP"? Y, no he visto una explicación real.

— Netch

Soy el póster original y declararé que la copia entre celdas de memoria en S / 360 no es "una operación ligeramente diferente", sino que solo es un caso especial de la misma copia. La pregunta sigue sin resolverse.

— Netch