Problems with GNU as Intel syntax

[SimonZilch]

Ok. I've just decided to try learning GNU as using Intel syntax, but I'm running into problems. And I can't even seem to find much documentation related to my problems, and some of the documentation I can find, seems to be wrong.

I'm using this directive:

Code: Select all

.intel_syntax prefix

The first problem I ran into is with this line of code:

Code: Select all

	mov %esp, __stack_end

Now I would expect that esp would then point to the same address as __stack_end, but that's not what happens. It gets translated into a reference to the memory at __stack_end, so NASM disassembles it like this:

Code: Select all

	mov esp, [__stack_end]

Well, I replaced it with an lea instruction so I still get the behavior I want, but I want to know how to do it with a mov instruction. And why do they even do that? Treating a bare label as a memory reference in this context is inconsistent, as a bare label refers merely to the address in other contexts.

The second problem I ran into is a warning for this code:

Code: Select all

	mov [0xb8000], %eax

or even this code:

Code: Select all

	mov dword ptr [0xb8000], %eax

The warning is: "Warning: Treating `dword ptr [0xb8000]' as memory reference"
That doesn't make sense. Of course it's treating it as a memory reference. I very explicitly told it that it's a memory reference. Why would it give me a warning here where I explicitly said it's a memory reference and not give me a warning with my other code, where intuitively it should not have been a memory reference (and isn't in other assemblers)?
So how do I get rid of this warning? Is my syntax wrong? If so, how do I do it right?

(By the way, yes I know moving eax to address 0xb8000 (in the way I'm doing it) looks a little strange, but it's just temporary code to display two characters on the screen.)

[JohnnyTheDon]

I remember GAS always expecting a $ before anything that is to be treated as a value, not a memory reference. Might want to try that.

[SimonZilch]

I remember GAS always expecting a $ before anything that is to be treated as a value, not a memory reference. Might want to try that.

Yeah, I tried that before. Here are some of the things I've tried and the results:

Code: Select all

.intel_syntax prefix
. . .
	mov %esp, $__stack_end

Result: Treats `$__stack_end' as a different symbol than `__stack_end'.
linker says: undefined reference to `$__stack_end'

Code: Select all

.intel_syntax prefix
. . .
	mov %esp, $ __stack_end /* note the space after $ */

Result: Probably treats `$' as a symbol.
assembler says: Error: invalid operand for 'mov' ('__stack_end' unexpected)

Code: Select all

.intel_syntax noprefix
. . .
	mov esp, __stack_end

Result: Treats `__stack_end' as a memory reference, just like my original problem.

Edit: Thanks for the suggestion though.

[iammisc]

gas also uses the syntax: op src, dest

so for example the code in intel syntax:

mov eax, 5

would be this in AT&T syntax:

mov $0x5, %eax

would put 5 into eax.

so to fix your problem use
mov $__stack_end, %esp

you should really learn AT&T syntax before you use it.

and you don't need to use .intel_syntax prefix

[JohnnyTheDon]

The whole point was that the OP is trying to use gas to assemble code that uses intel syntax. Thats why '.intel_syntax prefix' is there.

[SimonZilch]

gas also uses the syntax: op src, dest

so for example the code in intel syntax:

mov eax, 5

would be this in AT&T syntax:

mov $0x5, %eax

would put 5 into eax.

so to fix your problem use
mov $__stack_end, %esp

you should really learn AT&T syntax before you use it.

and you don't need to use .intel_syntax prefix

I know AT&T is it's native syntax. That's precisely the reason I've (mostly) avoided using Gas all these years: because AT&T syntax is backwards from all the instruction set documentation (except when it's not, which makes it even more confusing). In other words, I'm not going to use AT&T syntax unless I absolutely have to; which I don't, because there are other assemblers. I just hoped that I could stick with a single tool set.

As it turns out the label issue is more annoying than I thought if I can't get it to work right, because it's also a problem with this statement:

Code: Select all

	push Str

Naturally, I want to push the address of the string, but instead it pushes the first four characters of the string as a dword. That would be quite annoying if I always have to replace label pushes with this:

Code: Select all

	lea %reg [Str]
	push %reg

Is there anyone out there that uses Intel syntax on Gas that could help me?

[SimonZilch]

Well, I figured gcc had to push label addresses sometimes, so I wrote a simple program that required it, and had gcc output intel syntax assembly instead of object code. It turns out gcc does it like this (with a mov instead of a push, but that's not important):

Code: Select all

	mov	DWORD PTR [%esp], OFFSET FLAT:Str

After a little web searching, I think the word "FLAT" and the colon are unnecessary, but I'm not 100% sure. It did work fine in my code without them.
Now if only I can figure out what the warning in my first post is about.

[JohnnyTheDon]

You might want to try yasm or nasm. They do intel syntax and IMHO are much better than gas.

[Solar]

He said he wants to learn GNU as with Intel syntax, we don't know why so we have to assume he's got his reasons. Suggesting a different tool doesn't solve his problems...

Just to be sure: What version of GNU as are you using?

[earlz]

I suppose to make reasonable code, you would have to make hackish db statements with hex codes.. gas is evil...

[nekros]

I don't suppose you'll explain why you aren't going with an assembler that has a syntax you recognize?

[CodeCat]

I'm guessing it's because he wants to keep things consistent, not wanting to use a different syntax for inline assembly than for pure assembly files.

[SimonZilch]

You might want to try yasm or nasm. They do intel syntax and IMHO are much better than gas.

I don't suppose you'll explain why you aren't going with an assembler that has a syntax you recognize?

I've been programming in nasm since before yasm existed, but I've also been using gcc all that time for my C code, which means my inline assembly syntax was quite different than my regular assembly syntax, and it's always bothered me. Plus there are a few things about gas syntax that I DO like better. I just couldn't ever get past the reversed operands of AT&T syntax. So I figured I would experiment using gas/gcc with intel syntax in both. If I don't like it, I'll go back to nasm/gcc (but maybe with intel syntax in gcc), or maybe switch to yasm/gcc (which as I understand is basically the same as nasm/gcc). As of right now, it's still up in the air.

Although, if you know of a good, free (as in water, because I don't drink beer) C compiler for Linux that supports Intel-syntax inline assembly, I might try that. With the exception of the Intel compiler, that is, because I couldn't convince it to install on my current Linux distro (although it could be that I just need to try to be a little more convincing).

He said he wants to learn GNU as with Intel syntax, we don't know why so we have to assume he's got his reasons. Suggesting a different tool doesn't solve his problems...

Just to be sure: What version of GNU as are you using?

as: "GNU assembler version 2.17.50.0.18-1 20070731"
gcc: "gcc (GCC) 4.1.2 20070925 (Red Hat 4.1.2-33)"

[iammisc]

The whole point was that the OP is trying to use gas to assemble code that uses intel syntax. Thats why '.intel_syntax prefix' is there.

Ah, ok. sorry.

Well then, he doesn't need to use percent signs OR dollar signs or any of that AT&T stuff. Just use regular intel syntax.

[earlz]

The whole point was that the OP is trying to use gas to assemble code that uses intel syntax. Thats why '.intel_syntax prefix' is there.

Ah, ok. sorry.

Well then, he doesn't need to use percent signs OR dollar signs or any of that AT&T stuff. Just use regular intel syntax.

I'm not sure if it matters, but when I did gas with intel syntax in my OS, I did

Code: Select all

.intel_syntax noprefix

I'm not sure of the difference though