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

kzinti · **Joined:** Mon Feb 02, 2015 7:11 pm **Posts:** 399

Octocontrabass: thanks, all good points.

iansjack · **Posted:** Thu Aug 27, 2015 4:08 pm

Quote:

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 · **Joined:** Mon Feb 02, 2015 7:11 pm **Posts:** 399

iansjack wrote:

Quote:

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 · **Joined:** Mon Mar 25, 2013 7:01 pm **Posts:** 2328

iansjack wrote:

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

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

kiznit wrote:

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 · **Joined:** Tue Dec 13, 2011 4:11 pm **Posts:** 103

kiznit wrote:

iansjack wrote:

Quote:

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:

mov some_label, %rax

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

Code:

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:

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

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

iansjack · **Posted:** Fri Aug 28, 2015 4:03 am

Octocontrabass wrote:

iansjack wrote:

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.

Quote:

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 · **Joined:** Tue Dec 13, 2011 4:11 pm **Posts:** 103

iansjack wrote:

Octocontrabass wrote:

iansjack wrote:

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.

Quote:

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 · **Posted:** Fri Aug 28, 2015 9:25 am

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 · **Joined:** Tue Dec 13, 2011 4:11 pm **Posts:** 103

iansjack wrote:

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:

$ /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:

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

iansjack · **Posted:** Fri Aug 28, 2015 11:26 am

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 · **Posted:** Fri Aug 28, 2015 11:28 am

Actually I get the same strange error:

Code:

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:

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:

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 · **Joined:** Sat Mar 01, 2014 2:59 pm **Posts:** 1146

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

evoex · **Joined:** Tue Dec 13, 2011 4:11 pm **Posts:** 103

iansjack wrote:

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!

OSDev.org

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

Who is online