flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > Linux > Which syntax should I learn: AT&T or Intel ? 32 or 64-bit ?

Author
Thread Post new topic Reply to topic
egy



Joined: 01 Aug 2017
Posts: 13

Which syntax should I learn: AT&T or Intel ? 32 or 64-bit ?

Greetings to all members of the board. I just found this amazing board and I have started learning fasm on linux. There is so much to absorb. I hope I can best benefit from all your experience.

I came across this quora question and it confused me. AFAIK, fasm uses the intel syntax. The first answer of the question discouraged learning the Intel syntax and favored AT&T. To quote:

Quote:

Most of the assembly programmers coming from Windows system were too stuck with the old syntax and I can understand that. But if you start using it, the ATT is the logical choice. But you won’t come around to learn both anyway.



Also, on the topic of 32 and 64 bit:

Quote:
Because it’s one of the few sources for correct kernel calling from Assembly. ALL other sources use crappy old 32bit calls, which means INT $80 calling convention. This calling convention is highly discouraged on 64 bit systems and they said, that this feature can get deactivated at any time.

So: HIGHLY DEPRECATED

In every documentation you’ll find the call with INT $80. You have to change all of them if you want that your programs continue to run on 64 bit in say, a few years from now. Can’t say if they deactivate that or not and if they do when that will happen. But I’m quite certain it will happen.



So, my questions are:
1- AT&T syntax or Intel ?
2- 32-bit instructions or 64-bit ? (my machine is 32-bit)
3- Also, will I be able to use a debugger on linux (like gdb) to debug my fasm programs ?

Thank you Smile
Post 01 Aug 2017, 19:54
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 899

No offense but that guy is plain wrong.

I'd go with Intel syntax unless you want to either mix it with GCC a lot, or want to parse the result easier. While GCC (well, GAS) supports intel syntax as well, it's a pain if the project uses AT&T in other inline asms + it's way easier to parse (with automated scripts/tools) AT&T asm output.

However, if you code only in asm a specific function or module then use FASM with Intel syntax. AT&T is just plain bad syntax. Intel syntax flows naturally for instructions since they are like C statements, e.g.

Code:
mov eaxebx        ; eax = ebx
add eaxecx        ; eax += ecx
shlx eaxedxecx  ; eax = edx<<ecx

and so on.

For question (2), then of course use 32-bit since it can't run 64-bit (note that 64-bit Linux can in most cases run 32-bit software just fine). What he said about syscall is mostly bullshit. Note that 64-bit code (not instructions, it's a different "mode") uses syscall while 32-bit code uses int 0x80 (or sysenter). 64-bit kernel can in most cases run 32-bit code, so there's no issue there.

  • syscall is the instruction you use for 64-bit code for system calls.
  • int 0x80 is for 32-bit code, but you can also use sysenter (with vdso, a bit more complicated); for starters just use int 0x80 for system calls
  • int 0x80 won't go away for 32-bit code, period; so you can code 32-bit code with it just fine; I wasn't even aware it worked in 64-bit code in the first place, so he's babbling for nothing (you don't use it in 64-bit)
The "examples" he mentioned of being int 0x80 means they are 32-bit examples. System calls are different between 32-bit and 64-bit ANYWAY so it doesn't matter the bs he was saying. syscall numbers are different. So those examples are clearly for 32-bit code. In most cases you can't just swap the instruction and think it will work.

For 32-bit when you become more advanced, learn to use the VDSO for faster system calls (which utilize sysenter), but forget that for now (?)


For (3), yes why not?

(also, FASM can do 16-bit code just fine, wtf is he smoking; I think he meant GCC there)

Here's useful syscalls numbers/reference straight from Linus' github (these go into eax when performing the syscall):

32-bit | 64-bit

You should bookmark them Wink
Post 01 Aug 2017, 20:06
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 15324
Location: Bigweld Industries

If you want to keep your sanity and save your shift key then use Intel syntax. If you want to make yourself crazy and wear out your shift key then use AT&T syntax.

As for 32/64: There is no need to choose one or the other. They are very similar actually. For most programs 32-bit is perfectly adequate, and is usually a bit faster also. But there are applications where 64-bit is needed and/or performs better. Something that makes heavy use of 64-bit integer arithmetic might show better performance, it depends. And something that has data sets larger than 4GB might be more convenient coded in 64-bit, it also depends. But mostly it can be just a simple matter of personal preference or familiarity that makes once choose to write a particular program in 32-bit or 64-bit.
Post 02 Aug 2017, 01:40
View user's profile Send private message Visit poster's website Reply with quote
egy



Joined: 01 Aug 2017
Posts: 13

I have really enjoyed the answers, and I am surprised I got instant answers! Very active community indeed! Thanks Furs and revolution.


Quote:
I'd go with Intel syntax unless you want to either mix it with GCC a lot



Sorry for the silly question, but if I wanted to use C libraries alongside my code, will that be a hurdle ?


Quote:
What he said about syscall is mostly bullshit



Glad I asked here before making any careless moves Smile
My thanks for the syscalls for 32-bits. I am following a windows-syntax tutorial for fasm and I often see `call [ExitProcess]` after importing kernel32 library. Now at least I have some directions.


Quote:
For 32-bit when you become more advanced, learn to use the VDSO for faster system calls (which utilize sysenter)


Will do.


Quote:
If you want to keep your sanity and save your shift key then use Intel syntax


IKR ? I saw an example of AT&T's last night and... you have to prefix % A LOT! This, is enough to drift away from AT&T syntax. Thanks for the simple plain answer.
Post 02 Aug 2017, 13:32
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 899


egy wrote:
Sorry for the silly question, but if I wanted to use C libraries alongside my code, will that be a hurdle ?

Not at all. When I was speaking of GCC I was referring to its so-called "inline asm", which is asm statements you embed in C code directly (it's pretty powerful since you can specify input/output operands and let GCC pick registers etc, at least as optimal as HLL code if written properly).

Obviously if you write a function fully in asm (or module or even app) then you don't need that so you can just use FASM for that Wink

(for later, to get the vdso address you either call getauxval from libc.so or need to scan the auxiliary vector yourself, reading the pseudo-file /proc/self/auxv with simple read operations and scanning it for AT_SYSINFO [yeah it sounds complicated but it's a simple loop through a 2-element struct; I've done that already so probably I can give you the code example when you want it when you get more accustomed to system calls, but I optimized it for size since it's "initialization"])
Post 02 Aug 2017, 14:02
View user's profile Send private message Reply with quote
egy



Joined: 01 Aug 2017
Posts: 13


Quote:
When I was speaking of GCC I was referring to its so-called "inline asm", which is asm statements you embed in C code directly


To complete my understanding, the .inline asm statements/instructions are written in AT&T's rather than Intel's, am I right ?

EDIT 1: just to re-iterate: I can then put statements/instructions of inclusion for C libraries statements in my assembly code easily ?

EDIT 2: Why not pin the links to system calls you provided to the Linux FAQ ? There are three thread links under "specific sections" in the FAQ (on of them about syscalls macros) but none of them was actually useful to me. Links to linuxassembly.org are broken.
Post 02 Aug 2017, 18:12
View user's profile Send private message Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 899

Well I'm not a mod but revolution could merge it to main post, good idea (I wasn't even aware of the FAQ, sorry).

Re: inline asm. Yes you can call anything from asm, don't worry about it. What inline asm means is statements directly inside C source code, for example:

Code:
/* some C code */
asm("asm_template ...":"+r"(a):"r"(b));
/* more C code */

this gets compiled by GCC (not any assembler) as C source file, nothing to do with FASM. Those are usually written in AT&T because most people use that in GCC. You can use an intel syntax thing, but then you have to remember to turn it off at the end of the asm else you screw up the other inline asms I think. Anyway, that's what I meant with "AT&T used for inline asm".

If you write a function/module in a separate .asm file then it's not "inline asm" anymore, it's simply "asm". And yes asm can call *anything* since you interface with the hardware already. (you can call a library from asm written in *any* language no matter its calling convention Wink)
Post 02 Aug 2017, 21:33
View user's profile Send private message Reply with quote
Azagaros



Joined: 18 Jan 2013
Posts: 14

At&t source, destination is all you need.
intel destination, source.

Addressing may be slightly different but the opp instructions are the same.
Post 03 Aug 2017, 01:16
View user's profile Send private message ICQ Number Reply with quote
egy



Joined: 01 Aug 2017
Posts: 13

Thanks Azagaros for the reply. There is also the painful % before every register and $ before... I don't know. But Intel's is much nicer and simpler.


Quote:
You can use an intel syntax thing, but then you have to remember to turn it off at the end of the asm else you screw up the other inline asms I think. Anyway,


I made a quick search on SE and found that the flag:

Code:
 gcc -masm=intel 

makes GCC understand Intel, which is a plus.


Quote:
And yes asm can call *anything* since you interface with the hardware already.


All has been settled then. Time to work Smile
As for the links at the FAQ, I can't access linuxassembly.org, maybe there is a mirror somewhere ?

Cheers to all for helping out.
Post 03 Aug 2017, 13:31
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 6685
Location: Kraków, Poland


egy wrote:
As for the links at the FAQ, I can't access linuxassembly.org, maybe there is a mirror somewhere ?

It's at http://asm.sourceforge.net
Post 03 Aug 2017, 14:37
View user's profile Send private message Visit poster's website Reply with quote
egy



Joined: 01 Aug 2017
Posts: 13

I appreciate it Tomasz.
Post 03 Aug 2017, 15:12
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >

Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2017, Tomasz Grysztar.