GAS bad error message (was: Braindead AT&T Syntax)

[evoex]

Damn it... I just spend half an hour trying to fix an assembler error "operand size mismatch" on the following line:

Code: Select all

testq 0x18(%rsp), $3

Tried to play around with operand sizes, tried to find out if perhaps this instruction didn't work for 64 bit operands... Nope. Just forgot for a moment that the order of the instruction is reversed, and apparently the best error message for this was "operand size mismatch".
Because reversing the order is logical right? Having the destination on the right? Even if there isn't a destination.

I'm not sure why I decided to use AT&T syntax for my OS. It must've been some extreme form of masochism.

What are your thoughts on AT&T syntax? To be fair, I grew up with Intel syntax, so perhaps it's just a matter of getting used to it. But I just find Intel easier to read, write, and just not braindead.

Just had to rant about this somewhat .

[onlyonemac]

I hate AT&T syntax. Intel syntax is logical - having the destination on the left is consistent with higher-level languages like C, and more consistent with mathematical notation as well. Whoever thought of the idea of putting the destination on the right must have been mad.

[Roman]

I'm convenient with both styles. But I agree that the Intel syntax is better.

[Artlav]

Might be an example of human-orientedness.
We say take it from ax to bx, not put into bx the content of ax.
So there comes the destination on the right.

Similar thing with endianness - it makes sense for a machine to have the bytes in sequence that it would need them, but humans are used to reading numbers backwards.
So, some processors were made with bytes reversed.

And we have encountered, got confused and got used to the machine representation so long ago that we don't really remember being confused.

Unless it permanently damaged our brain's ability to do simple offset math, because people speak from one to n, and arrays are indexed from 0 to n-1, and the newly developed mathematical subsystem of a child got fried from this revelation...

[iansjack]

I think of a move instruction as (for example):

"I want to move the contents of the register bx to the register ax"

hence:

mov %bx, %ax

Makes perfect sense to me, and sounds more natural than:

"I want to move into register ax the contents of register bx"

But it's just syntax, so no big deal either way; takes about 5 minutes to learn it. Neither of them is "wrong".

[alexfru]

mov %bx, %ax

Makes perfect sense to me

When you look at it through the prism of mathematics and higher level programming languages like Basic, C/C++ (and derivatives), Pascal and others

ax = bx
let ax = bx
ax = bx;
ax := bx;
etc

all make perfect sense as well. And it fits just fine into other linguistic possibilities like "I gave him the book" or "Le di el libro".

[iansjack]

I think a more accurate comparison (in C) would be a function call rather than an assignment expression using an infix operator. But I have to admit that in the C Standard Library we have:

strcpy(dest, source)

which I have always felt was rather illogical.

As for the English example you give, I think a closer comparison would be "I put the book into the library" (or, in your preferred notation, "I put into the library the book"). I guess you could express the move instruction as "Move register ax bx", but it's not a natural way of speaking.

[Combuster]

Nice comparison with English, when it is inconsistent to say the least. They can't even rely on just a verb without messing with the preposition as well:

Code: Select all

b += a; // add a to b
b -= a; // subtract a from b
a *= b; // multiply a with b
a /= b; // divide a by b

Left-destination assignments are not hard to find either: "Let X equal Y" or "assume X is Y" or #"define X to be Y"

[onlyonemac]

I think a more accurate comparison (in C) would be a function call rather than an assignment expression using an infix operator. But I have to admit that in the C Standard Library we have:

strcpy(dest, source)

which I have always felt was rather illogical.

Again I have always thought that that is logical, following on from the built-in assignment operators.

Code: Select all

a = b;
a += b;

Thus

Code: Select all

function_move(a, b);
function_add(a, b);

Thus

Code: Select all

mov ax, bx
add ax, bx

[Rusky]

One nice thing about putting the destination on the left, in higher level languages, is that it is often a new name being defined, and the source is often a much more complicated expression. Neither of these apply in assembly, where it's honestly completely arbitrary and doesn't matter.

The real problem with AT&T syntax is not operand ordering, which you can figure out in five minutes, but address calculation syntax and literals vs dereferencing. Intel syntax handles that side of things much more clearly.

[kzinti]

The real problem with AT&T syntax is not operand ordering, which you can figure out in five minutes, but address calculation syntax and literals vs dereferencing. Intel syntax handles that side of things much more clearly.

I fully agree. In fact, the Intel operand ordering is the oddity. Most (all) other architectures use assemblers that follow the AT&T operand order.


From http://simon.baymoo.org/universe/tools/ ... symset.txt:

Other differences aside, you will notice that the AT&T format makes assignments
from left to right, and that modifying instructions modify their right-most
arguments. The primary reason for this difference is due to the VAX assembly
format for which the AT&T style was originally invented. (The Motorola 68000
and its descendents were heavily influenced by the VAX. Likewise, their
assembly language format moves in this direction as well!)

[Roman]

I think, that the Intel syntax is better because:

• In mathematics and high level programming languages you write: "x = y", thus "insn dst, src" is more straightforward for a programmer.
• No need for postfixes like 'q', 'l', 'w' and 'b' in most cases.
• No prefixes like % and $.
• Indexed load syntax is clearer.

[kzinti]

Some proponents of AT&T syntax will point out that having suffixes on mnemonics is a good thing. They are providing you with static type checking, ensuring your operands are of the right size and that the instructions generated are exactly the ones you wanted. Same with the $ and % prefixes. The syntax can help you catch errors.

If only I could get Intel ordering and addressing with the AT&T prefixes/suffixes, I'd be very happy indeed.

[onlyonemac]

The real problem with AT&T syntax is not operand ordering, which you can figure out in five minutes, but address calculation syntax and literals vs dereferencing. Intel syntax handles that side of things much more clearly.

I am not so familiar with that side of things; I have avoided AT&T syntax since I went mad trying to understand it - when I write code, I want the code to be as intuitive as possible so that I can use my brain power on more important issues than trying to interpret the code, therefore I use Intel syntax.

[Octocontrabass]

Some proponents of AT&T syntax will point out that having suffixes on mnemonics is a good thing. They are providing you with static type checking, ensuring your operands are of the right size and that the instructions generated are exactly the ones you wanted.

Registers already have inherent size attributes, which makes the suffixes redundant most of the time. AT&T syntax doesn't stop a programmer from mistakenly moving a variable into a register of the wrong size; the programmer will simply choose the suffix that matches the register size.

Intel syntax uses keywords on the operands instead of suffixes on the instruction, and to me this makes more sense: the size of a variable is a property of that variable. For those (usually rare) cases where the two operands have different sizes, it's immediately obvious which operand is which size, as well.

Same with the $ and % prefixes. The syntax can help you catch errors.

For the $ prefix, you have to specify which specific flavor of Intel syntax you're comparing against. The difference between immediate and memory operands isn't obvious in MASM syntax, but NASM syntax always requires square brackets around memory operands.

For the % prefix, using symbols that have the same names as CPU registers is asking for trouble anyway. For Intel syntax, it's a namespace collision, and you might choose a similar name. In either syntax, your symbol and the register are only one small typo away from each other.