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

[kzinti]

Octocontrabass: thanks, all good points.

[iansjack]

For the $ prefix, you have to specify which specific flavor of Intel syntax you're comparing against.

That's a good enough reason for me to avoid Intel syntax.

[kzinti]

For the $ prefix, you have to specify which specific flavour of Intel syntax you're comparing against.

That's a good enough reason for me to avoid Intel syntax.

This is actually the first time I've ever heard of $ for memory operands (Intel syntax), and I've started programming in x86 assembly in the 8086 days.

[Octocontrabass]

That's a good enough reason for me to avoid Intel syntax.

I don't see your point. Care to elaborate?

This is actually the first time I've ever heard of $ for memory operands (Intel syntax), and I've started programming in x86 assembly in the 8086 days.

Hmm? Maybe my post was unclear; I was trying to draw a comparison between the $ prefix in AT&T syntax with square brackets in NASM syntax.

In AT&T syntax, a $ prefix is used to differentiate immediate operands from memory operands.
In NASM syntax, square brackets are used to differentiate memory operands from immediate operands.

Both are equally good at differentiating memory and immediate operands, so it's unfair to say that the $ prefix in AT&T syntax is an advantage over NASM syntax.

Some other Intel-syntax assemblers allow symbols to be translated into memory operands, which is ridiculous. Comparing against these, AT&T syntax is obviously superior.

[evoex]

For the $ prefix, you have to specify which specific flavour of Intel syntax you're comparing against.

That's a good enough reason for me to avoid Intel syntax.

This is actually the first time I've ever heard of $ for memory operands (Intel syntax), and I've started programming in x86 assembly in the 8086 days.

Code: Select all

mov some_label, %rax

Actually moves the data pointed to by some_label to %rax, while:

Code: Select all

mov $some_label, %rax

Moves the address of the label into %rax. Come on, AT&T, use your stupid parentheses if you want the contents at an address.
But nothing beats the syntax of those parenthesis:

Code: Select all

mov 12(%rsi, %rcx, 4), %rax

How's THAT for readability?
(And where did the $ before the 12 and 4 constant disappear to?)

[iansjack]

That's a good enough reason for me to avoid Intel syntax.

I don't see your point. Care to elaborate?

You answered it for me.

Some other Intel-syntax assemblers allow symbols to be translated into memory operands, which is ridiculous. Comparing against these, AT&T syntax is obviously superior.

This is really a pretty silly thread. Neither syntax is braindead (although programmers who can't get to grips with one or the other of them might rightly be considered so). There are no rights or wrongs here; it's a simple matter of notation. Use whichever suits you, but let's not start religious wars about which is best.

[evoex]

That's a good enough reason for me to avoid Intel syntax.

I don't see your point. Care to elaborate?

You answered it for me.

Some other Intel-syntax assemblers allow symbols to be translated into memory operands, which is ridiculous. Comparing against these, AT&T syntax is obviously superior.

This is really a pretty silly thread. Neither syntax is braindead (although programmers who can't get to grips with one or the other of them might rightly be considered so). There are no rights or wrongs here; it's a simple matter of notation. Use whichever suits you, but let's not start religious wars about which is best.

I never wanted to start a religious war, I just needed a rant. To be honest, my actual issue wasn't the syntax, but rather getting used to the new syntax, and the terrible error message about operand sizes, which was pretty much a lie.

[iansjack]

I'd say that it's your assembler that's braindead. Gnu assembler, on my Mac, gives the error "test.s:1:20: error: invalid operand for instruction" for that instruction. Precise and 100% correct.

[evoex]

I'd say that it's your assembler that's braindead. Gnu assembler, on my Mac, gives the error "test.s:1:20: error: invalid operand for instruction" for that instruction. Precise and 100% correct.

Agreed that my assembler is braindead... But it's also Gnu assembler, on my Mac...

Code: Select all

$ /usr/local/cross/bin/x86_64-elf-as --version
GNU assembler (GNU Binutils) 2.24
Copyright 2013 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-elf'.

And it outputs:

Code: Select all

lib/core/Start.s: Assembler messages:
lib/core/Start.s:6: Error: operand size mismatch for `test'

[iansjack]

Interesting: I get the same error message on FreeBSD as my Mac, but the same as yours on Fedora. Clearly the fault lies with the assembler (after all, error messages are not part of the syntax) so perhaps you should change the title of the thread. It would be interesting to know what error message it gives for the same error using Intel syntax, but I don't have time to test it right now.

[xenos]

Actually I get the same strange error:

Code: Select all

x86_64-pc-elf-as --version
GNU assembler (GNU Binutils) 2.25
Copyright (C) 2014 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-elf'.

AT&T:

Code: Select all

echo 'testq 0x18(%rsp), $3' | x86_64-pc-elf-as
{standard input}: Assembler messages:
{standard input}:1: Error: operand size mismatch for `test'

Intel:

Code: Select all

cat | x86_64-pc-elf-as
.intel_syntax noprefix
test 3, qword ptr [rsp+0x18]
{standard input}: Assembler messages:
{standard input}:2: Error: operand size mismatch for `test'

[onlyonemac]

Perhaps a bug report to the developers would be in order?

[evoex]

Interesting: I get the same error message on FreeBSD as my Mac, but the same as yours on Fedora. Clearly the fault lies with the assembler (after all, error messages are not part of the syntax) so perhaps you should change the title of the thread. It would be interesting to know what error message it gives for the same error using Intel syntax, but I don't have time to test it right now.

Yeah, it's an issue with the assembler, but I decided to rant about the AT&T syntax, because I'm so used to Intel syntax I automatically coded it with the operands swapped. Anyways, I changed the title.

And I've also filed a bug report...

Thanks for reproducing this, guys!