Re: Intel assembly questions
Re: Intel assembly questions
- Subject: Re: Intel assembly questions
- From: Eric Albert <email@hidden>
- Date: Wed, 18 Jan 2006 13:04:37 -0800
On Jan 18, 2006, at 12:53 PM, Jonas Maebe wrote:
On 18 Jan 2006, at 21:39, Eric Albert wrote:
Removing those causes the following error: No such 386
instruction: movzl
What is the replacement syntax for "byte Ptr"?
In AT&T style, the operand size is always added to the
instruction. In this case, the above should become
movzbl 4(%esi),êx
Couple of more questions...
Since I've got "Codewarrior Style" enabled, I assume I'm using
Intel style operand ordering, so the operands in your example
would be backwards right?
Yep.
This does not compute for me. Either you should have Intel syntax
and Intel operand ordering, or AT&T syntax and AT&T operand
ordering. The correct way to specify operand sizes in Intel mode is
"byte ptr" (or just "byte" sometimes also works).
I think Dave was asking if the operands in your example would have to
be reversed for Intel-style assembly, and they would.
GCC complains there is no movzbl instruction. Changing that to
movzb does not generate an error. Is that equivalent? I don't see
that in my instruction reference docs.
The suffix is typically optional and is used more often in AT&T-
style code.
"movzb" does not exist in either the Intel or the AT&T syntax
(although it seems some versions of GAS do accept movzb, google at
least finds some 820 hits for it). The correct name is "movzx" for
Intel. In AT&T, it's "movz" followed by the source and destination
sizes (e.g. movzbl for "byte to long").
Current versions of gas accept movzbl and movzb, as well as movzbw.
"movzx" was added for Intel syntax support, according to comments in
the gas code.
I'm not sure why it's used more frequently there, since it's
usually superfluous. The instruction itself can usually be
determined by the operands.
It's to have a consistent syntax, I assume, and to avoid
ambiguities. For example, who knows what the compiler/assembler
will make of "mov [eax], 5"? Does it store 8, 16 or 32 bits? It's
accepted by many assemblers/compilers which grok Intel-style
assembler though.
In the AT&T syntax for that case ('mov $5, (êx)'), gas says "no
opcode suffix given; can't determine immediate size". This is one of
the exceptions to my "usually superfluous" comment. :)
-Eric
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden