Limitaciones de la sintaxis del ensamblaje Intel en comparación con AT&T [cerrado]


88

Para mí, la sintaxis de Intel es mucho más fácil de leer. Si recorro el bosque de ensamblajes concentrándome solo en la sintaxis Intel, ¿me perderé algo? ¿Hay alguna razón por la que me gustaría cambiarme a AT&T (además de poder leer el ensamblaje de AT&T de otros)? Mi primera pista es que gdb usa AT&T por defecto.

Si esto es importante, mi atención se centra solo en cualquier ensamblado y sintaxis que pueda tener con Linux / BSD y el lenguaje C.


11
Me encantan las preguntas no constructivas que obtienen más de 50 votos a favor.
hasta

Respuestas:


80

Realmente no hay ventaja para uno sobre el otro. Sin embargo, estoy de acuerdo en que la sintaxis de Intel es mucho más fácil de leer. Tenga en cuenta que, AFAIK, todas las herramientas GNU tienen la opción de usar también la sintaxis Intel.

Parece que puede hacer que GDB use la sintaxis Intel con esto:

establecer intel de sabor de desmontaje

GCC puede utilizar la sintaxis de Intel -masm=intel.


18
también, echo set dis intel >> ~ / .gdbinit
oevna

9
¿Por qué es menos legible la sintaxis de AT&T? Encuentro que tener sufijos de tamaño en los operandos es más consistente que tener "dword". ¿Hay algo más que me falta?
Hawken

54
lea -0x30(%rcx,%rax,8),%eaxes ATT intrincado para lea eax,[rcx+rax*8-0x30]. El uso de + y * realmente ayuda en el estilo Intel.
jørgensen

9
Veo su "convolución" como igual pero no idéntica: si ATT es opaco, entonces Intel es ambiguo. Aunque la aritmética infija es más familiar para los estudiantes de álgebra, no es obvio por la sintaxis que hay exactamente 4 argumentos para la operación, o que solo uno de ellos puede ser multiplicado, y en ningún caso está claro que el multiplicador debe ser un poder de 2.
error

10
@Hawken Encuentro los sufijos de AT&T mucho mejores que los "ptr" de Intel porque siempre lo especificas y realmente reduce la cantidad de errores (al menos para mí). Sobre el resto (por ejemplo, los símbolos $ y%) ... sí ... no son agradables, y ese es el punto, pero tienen una ventaja: es explícito y una vez más reduce los errores. Yo diría que uno es cómodo para leer (Intel) y el segundo para escribir (AT&T).
MasterMastic

43

La sintaxis principal del ensamblador GNU (GAS) es AT&T. La sintaxis de Intel es una adición relativamente nueva. El ensamblaje x86 en el kernel de Linux está en sintaxis de AT&T. En el mundo de Linux, es la sintaxis común. En el mundo de MS, la sintaxis de Intel es más común.

Personalmente, odio la sintaxis de AT&T . Hay muchos ensambladores gratuitos (NASM, YASM) junto con GAS que también son compatibles con la sintaxis Intel, por lo que no habrá ningún problema con la sintaxis Intel en Linux.

Más allá de eso, es solo una diferencia sintáctica. El resultado de ambos será el mismo código de máquina x86.


25
De acuerdo y acordado. Debería ser un crimen usar la sintaxis de AT&T, es contraintuitivo y feo, ¿por qué querría prefijar cada número y registrarse con $ y%, y especificar el direccionamiento relativo en notación SIB inversa? He estado usando la sintaxis de Intel durante dos años y todavía no puedo ver por qué AT&T existe.
L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳

11
Si va a expresarlo en negrita, al menos proporcione alguna evidencia de por qué la inteligencia es mucho mejor.
Hawken

8
@Hawken Haters van a odiar
Gunther Piez

8
@Hawken ¿Estás sugiriendo que debido a que usó letras en negrita, de alguna manera está expresando su opinión como un hecho de una manera que no lo habría hecho si simplemente hubiera dejado en negrita? La pregunta estaba prácticamente invitando a este tipo de "debate" de opinión de todos modos, ¡presumiblemente por qué ahora está cerrado!
Elliott

1
¿Qué hay de la sintaxis Intel para ARM?
hasta

33

Realmente no hay ventaja para uno sobre el otro. Sin embargo, no estoy de acuerdo con que la sintaxis de Intel sea mucho más fácil de leer, porque personalmente odio la sintaxis de Intel . Tenga en cuenta que, AFAIK, todas las herramientas GNU tienen la opción de usar también la sintaxis Intel.

at&t noprefix                   intel
mov eax, -4(ebp,edx,4)          mov DWORD PTR[-4 +ebp +edx *4], eax
mov eax, -4(ebp)                mov DWORD PTR[-4 +ebp], eax
mov edx, (ecx)                  mov DWORD PTR[ecx], edx
lea (   ,eax,4), eax            lea eax, DWORD PTR[8 + eax*4]
lea (eax,eax,2), eax            lea eax, DWORD PTR[eax*2+eax]

... y se vuelve más complicado con instrucciones más complejas

'Nuff dijo.

PD: Esta respuesta existe principalmente por la razón de resaltar (en mi humilde opinión) debilidades en algunas otras respuestas, que en realidad no son respuestas, sino opiniones. Y, por supuesto, esta respuesta en realidad es solo mi humilde opinión.

PPS: No odio la sintaxis de Intel, simplemente no me importa.


19
Estoy terriblemente confundido. ¿Está insinuando que la sintaxis de at & t nunca necesita hacer explícito el tamaño de la palabra? ¿Por qué copiaron mi ejemplo y agregaron tamaños de palabras y la cosa inútil de PTR? Además, ¿por qué cambió mis diferencias a sumas con un operando izquierdo negativo? ¿Es porque así es como se codifica realmente la instrucción? El usuario rara vez tiene que preocuparse por eso. En cada ensamblador que he usado, puede omitir el DWORD PTR ya que el operando izquierdo es de 32 bits y el operando derecho tiene corchetes alrededor.
L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳

12
Además, IDA / ollydbg ni siquiera produce nada parecido a lo que usted escribió, así que estoy bastante seguro de que no hay problema para pasar del código de máquina a la sintaxis Intel "agradable". Entonces, su ejemplo parece bastante artificial y es algo que nunca vería excepto en la implementación más trivial de un ensamblador o desensamblador. Por otro lado, las instrucciones de at & t de las que me burlo son directamente de uno de los primeros párrafos de un tutorial que enseña la sintaxis de at & t.
L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳

8
He llegado a la conclusión de que usted es una máquina, por lo que prefiere una sintaxis que refleje directamente la codificación de bits de la instrucción. (que es lo que hace la sintaxis de at & t). También tengo la sospecha de que las personas se sienten más 1337 cuando usan la sintaxis de at & t ya que es más oscura, aunque eso no es realmente una ventaja ...
L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳

7
@Longpoke No, la sintaxis de AT&T no necesita hacer explícito el tamaño de la palabra si se desprende del contexto. Igual que con Intel: no es necesario SOMEWORD PTR[]si el tamaño del operando está claro en el contexto. Pero lo necesitas en caso de mover un inmediato a una ubicación de memoria (tanto el lde AT&T como el DWORD PTR de Intel). Y sí, mi ejemplo es bastante artificial, pero también el tuyo. En caso de que aún no vea por qué: omitió los tamaños de palabras innecesarios en Intel, pero los tiene en AT&T. Usted elige los operandos de manera que se alineen bien en Intel, pero no lo haga en AT&T.
Gunther Piez

7
Entonces, ¿estás diciendo que la -4(ebp,edx,4)cosa es mejor que [4*edx+ebp-4]? Encuentro este último más intuitivo.
Calmarius

24

Es el "mismo lenguaje", ya que se compila en el mismo código de máquina, tiene los mismos códigos de operación, etc. Por otro lado, si está usando GCC, probablemente querrá aprender la sintaxis de AT&T, solo porque es el valor predeterminado: sin cambiar las opciones del compilador, etc. para obtenerlo.

Yo también me corté los dientes con la sintaxis Intel x86 ASM (también en DOS) y lo encontré más intuitivo al principio al cambiar a C / UNIX. Pero una vez que aprenda AT&T, parecerá igual de fácil.

No lo pensaría tanto: es fácil aprender AT&T una vez que conoces a Intel, y viceversa. El lenguaje real es mucho más difícil de conseguir que la sintaxis. Así que, por supuesto, solo concéntrate en uno y luego aprende el otro cuando surja.


16
¿Qué? Debido a que GCC usa at & t de forma predeterminada, no hay razón para aprender la sintaxis de at & t. Especialmente cuando puede cambiarlo a la sintaxis Intel más intuitiva.
L̲̳o̲̳̳n̲̳̳g̲̳̳p̲̳o̲̳̳k̲̳̳e̲̳̳

7
@longpoke Aprender la sintaxis de Intel solo porque todo el mundo la llama "más intuitiva" no es una razón mejor. En realidad, no es ninguna razón.
Hawken

1
Ambos tienen razón, por las mismas razones por las que tanto Verilog como VHDL se han quedado.
error

@Hawken: Cierto. La verdadera razón para aprender la sintaxis de Intel es que es lo que usan los manuales de Intel y AMD. No hay manuales de referencia de ISA que utilicen la sintaxis de AT&T tan detallada como los manuales de los proveedores, por ejemplo, felixcloutier.com/x86/cmppd (extraído de los PDF de Intel). También información de rendimiento como uops.info y agner.org/optimize . Creo que leí que algún proveedor de Unix hizo una referencia de AT&T ISA en algún momento, pero ciertamente ya está desactualizado y no cubre las instrucciones AVX. 100% de acuerdo con esta respuesta: mismo código de máquina, sintaxis diferente para expresarlo, no es problema.
Peter Cordes

20

Es una señal de profesionalismo que esté dispuesto a adaptarse a lo que esté en uso. No hay ninguna ventaja real para uno u otro. La sintaxis de Intel es común en el mundo de Microsoft, AT&T es el estándar en Linux / Unix. Como no hay ventaja para ninguno de los dos, las personas tienden a imprimir en lo que vieron primero. Dicho esto, un programador profesional se eleva por encima de cosas como esa. Use lo que sea que usen en el trabajo o en el dominio en el que está trabajando.


5
¿Qué tal ser un usuario "profesional" de las herramientas y saber cómo cambiarlas para ser más productivo? +1 para la sintaxis Intel.
Jonathon Reinhart

5
Bueno, aunque yo también prefiero la sintaxis de Intel, él tiene un punto: considere el mantenimiento del código de AT&T existente, por ejemplo. Definitivamente no hay nada de malo en saber cómo manejar ambos.
Elliott

7
Si bien también recomendaría aprender ambos, jugaré Devil's Advocate y sugeriré que simplemente pueda escribir vim en archivos * .s de conversión automática a la sintaxis de su elección.
error

2
dado que la sintaxis de Intel es más fácil de leer, la sintaxis de Intel tiene una ventaja. "lea eax, [eax * 4 + 8]" tiene una legibilidad objetiva mucho mejor que "leal 8 (,% eax, 4),% eax"
Lucio M. Tato

2
@bug Je, escribiste mal emacs; D
GDP2

12

La sintaxis de Intel cubre todo (suponiendo que el ensamblador / desensamblador esté actualizado con la última versión basura que Intel agregó a su conjunto de instrucciones). Estoy seguro de que en & t es lo mismo.

at & t intel
movl -4 (% ebp,% edx, 4),% eax mov eax, [ebp-4 + edx * 4]
movl -4 (% ebp),% eax mov eax, [ebp-4]
movl (% ecx),% edx mov edx, [ecx]
leal 8 (,% eax, 4),% eax lea eax, [eax * 4 + 8]
leal (% eax,% eax, 2),% eax lea eax, [eax * 2 + eax]

... y se vuelve más complicado con instrucciones más complejas

'Nuff dijo.


17
No, no lo suficiente dicho.
Gunther Piez

2
El cartel ya indicó que prefieren la sintaxis Intel; bien por ellos; entonces, ¿a quién estás tratando de convencer?
Hawken

2
@Hawken no es solo el cartel quien va a leer las respuestas.
Extremo Sendon

Me gusta cómo menciona el ejemplo con una longitud de palabra. Escriba un operando de memoria en un solo byte o corto.
Ajay Brahmakshatriya

2

Mi primer lenguaje ensamblador fue MIPS, que he notado que es muy similar a la sintaxis ATT. Así que prefiero la sintaxis ATT, pero en realidad no importa siempre que puedas leerla.


3
El ensamblaje de MIPS solo es similar a la sintaxis de AT&T en el formato de dirección de la instrucción de carga / almacenamiento. Pero MIPS tiene solo 1 modo de direccionamiento simple para carga / almacenamiento, mientras que Intel tiene mucho más, lo que lo hace más complejo. Considere lea -0x30(%rcx,%rax,8),%eaxy lea eax,[rcx+rax*8-0x30]jørgensen publicado arriba. Y a diferencia de AT&T, MIPS todavía usa el formato de destino primero como todos los demás. Además, el número MIPS no necesita tener el prefijo $, y los nombres de registro en MIPS son cortos, por lo que no es muy incómodo tener% hasta el final como AT&T
phuclv
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.