Can I use the Intel syntax with GAS (GNU Assembler) if I assemble on non-Intel systems?
Essentially, I am starting out with assembly programming though I have many years of experience in higher-level languages and I would like to choose an assembler that is suitable for both x86 and ARM. Possibly other architectures as well but this is not a pressing need right now.
So far I have been happy with NASM but I also need ARM so GAS seems a nice candidate. Not having written anything much complex yet I am equally open to AT&T as well as to Intel syntax.
The only thing I am not sure if can I use GAS for cross-architecture programming as well if I pick the Intel syntax?
I realise that naturally instruction sets will be different but I would just like to settle on one tool to cover both the architectures - my thinking is that if with time I need a third one there will be less tooling to learn and maintain if I just do everything in GAS from day one.
Intuitively, I would say that there should not be any obstacles to using Intel syntax instead of AT&T to assemble programs on ARM or other non-Intel architectures, because GAS likely builds AST and then emits architecture-specific code regardless of the frontend's syntax, but unfortunately I do not have access to an ARM system to try it out and, that notwithstanding, I would very much like to confirm it with more knowledgeable people. Thank you.
EDIT: I came up with an analogy that may perhaps make it clearer what I have in mind. Supposing that someone learns to use vim effectively on Linux to work with Python, all that knowledge will transfer easily to Mac for development with Objective-C.
Needless to say, Python and Objective-C are two distinctly different languages but still, the knowledge of tooling (vim, in this example) will be useful.
If one day the person needs to develop Java on Windows, the same will still hold and the programmer will be able to use vim or a derivative on the third system.
Ultimately, the actual differences between the languages, Python vs. Obj-C vs. Java will naturally dwarf any tooling-related issues but when someone is just starting out, the idea of using the same tool for several different needs is quite appealing.
This is the kind of reusability that I am thinking of.