The Place to Start for Operating System Developers
http://forum.osdev.org./
That's a good enough reason for me to avoid Intel syntax.For the $ prefix, you have to specify which specific flavor of Intel syntax you're comparing against.
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.iansjack wrote:That's a good enough reason for me to avoid Intel syntax.For the $ prefix, you have to specify which specific flavour of Intel syntax you're comparing against.
I don't see your point. Care to elaborate?iansjack wrote:That's a good enough reason for me to avoid Intel syntax.
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.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.
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.iansjack wrote:That's a good enough reason for me to avoid Intel syntax.For the $ prefix, you have to specify which specific flavour of Intel syntax you're comparing against.
Code: Select all
mov some_label, %rax
Code: Select all
mov $some_label, %rax
Code: Select all
mov 12(%rsi, %rcx, 4), %rax
You answered it for me.Octocontrabass wrote:I don't see your point. Care to elaborate?iansjack wrote:That's a good enough reason for me to avoid Intel syntax.
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.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.
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 wrote:You answered it for me.Octocontrabass wrote:I don't see your point. Care to elaborate?iansjack wrote:That's a good enough reason for me to avoid Intel syntax.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.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.
Agreed that my assembler is braindead... But it's also Gnu assembler, on my Mac...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.
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'.
Code: Select all
lib/core/Start.s: Assembler messages:
lib/core/Start.s:6: Error: operand size mismatch for `test'
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'.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'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'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.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.