Both MASM and TASM use this syntax (although TASM also offers an 'ideal' mode, which is a slight variation).
Problem with assemblers like NASM is... I have never seen a proper definition of its syntax. Same with GAS. Yes, it uses AT&T syntax, but I've always found myself guessing what the syntax would be for some instructions. I have never seen a good reference for the entire instructionset, unlike Intel syntax, where the Intel manuals themselves ARE the reference.

Agreed. I've recently had an unhappy experience with gas with the fsub bug (details at www.mindfruit.co.uk/2012/03/trouble-with-fsub.html) which has led me to want to abandon the assembler in favour of something else. Nasm seemed the best-supported, but I had some issues with its 64-bit RIP-relative addressing; YASM seemed to have better support in this area but my results were mixed (almost certainly the problem was BCAC, but the documentation is somewhat thin in this area).

It turns out (ha, famous last words) that the unexpected behaviour I referred to in the Gnu assembler are not present when you use the .intel_syntax directive, so I'm going to try that for size and see how it works out. I'm looking forward to coding something in "proper" Intel syntax, and having documentation which is directly applicable to it. Of course, that is, until I hit the next bug...
Posted on 2012-03-13 06:33:07 by michaelg
Thanks for the reply, Frank.

But geez, now I'm so confused, many compilers when each person I ask says the different and opposes the others'. I wanted to firstly use MASM because it seemed the simplest and classic way, also because my book has been suggesting to use that to have a good working field where I can the registers and my work generally.

The thing is, if I do use MASM, I'll have to read tutorials about it, of how to work with it, considering that I might waste my time and it won't be such a good source, but that's how it goes, gotta risk it. From what Scali talks of, I understand that I should still carry on with the 16-bit codes and just know I will be easily able to switch to other bits versions.

And the book I was saying I'm reading about, is a book I can't say its name because its from my country, not in english, but you can be sure it teaches properly about the 16-bit ASM coding, explaining about the micro-processor, the registers, flags, memory layouts, and just everything else is needed for theory, and ofcourse coding...

Got any suggestions then to start off or any comments about what I said?

p1Mp.
Posted on 2012-03-13 10:54:35 by p1Mp

But geez, now I'm so confused, many compilers when each person I ask says the different and opposes the others'.


An assembler is not a compiler (hint: you don't compile assembly language).
Posted on 2012-03-13 11:57:42 by Scali


But geez, now I'm so confused, many compilers when each person I ask says the different and opposes the others'.


An assembler is not a compiler (hint: you don't compile assembly language).


Woops my bad, I've used the wrong word, used to it from C / C++.
Posted on 2012-03-14 04:26:30 by p1Mp
Yes its confusing, its one of the reasons that pure C was created, so everyone talks the same. When you get some ASM source, you need to know already what assembler it was meant for, and no, there are not really good tools to convert ASM, even though this is a trivial job, because ASM coders don't like to admit they are so fragmented from each other.
Posted on 2012-03-14 04:42:24 by Homer
Not to mention that tools such as disassemblers and debuggers might not speak the same dialect as your assembler.
All disassemblers and debuggers I've used were either Intel/MASM/TASM syntax or AT&T. Haven't seen one that does NASM or other dialects.
Posted on 2012-03-14 05:54:58 by Scali
Have ya seen Agner Fog's "objconv"? Among other tricks, it'll disassemble to Masm, Nasm, Yasm, and "Gasm". :)

http://www.agner.org/optimize/#objconv

(oh, and for 64-bit Windows, p1ranha's NASMX package is a start)

Best,
Frank

Posted on 2012-03-14 06:22:51 by fbkotler

Have ya seen Agner Fog's "objconv"? Among other tricks, it'll disassemble to Masm, Nasm, Yasm, and "Gasm". :)


So... to convert source code from assembler A to B, you need to assemble it with A, then disassemble it to B... great :P

I have two simple rules:
1) When in a Microsoft environment (DOS/Windows), I use Intel Syntax. Visual Studio comes with MASM, inline-assembly, a debugger and a disassembler that all speak the same syntax. As do many other tools on the platform (IDA, Win32Dasm, TASM, Borland C++ etc). MASM/Intel Syntax is the 'native' syntax for the platform.

2) When in a *nix environment (OS X, BSD, linux etc, or even when writing multi-platform code on Windows), I use AT&T syntax. These environments come with GCC or something closely related, with gas, inline-assembly, a debugger etc which all speak AT&T syntax. So AT&T syntax is the 'native' syntax for the platform.

When you look at my CPUInfo code: http://sourceforge.net/projects/cpuinfo/
It's actually a hybrid of the two. I wanted the code to work in Visual Studio on Windows, and with GCC on the other platforms. So there's some portable C, with inline-assembly routines in both Visual Studio and GCC-style.
This way developers don't need to install any 'odd' tools on their platform to get the code working. Most developers on Windows will use Visual Studio, and most developers on *nix will at least have GCC installed. So now they don't need to try and set up GCC on Windows (and make it integrate with the rest of their code which they may have written in Visual Studio), and on *nix, they won't need to install additional assemblers, or use experimental/unsupported features like GCC's intel syntax mode.
Posted on 2012-03-14 06:53:51 by Scali

I have two simple rules:
1) When in a Microsoft environment (DOS/Windows), I use Intel Syntax. Visual 2) When in a *nix environment (OS X, BSD, linux etc, or even when writing multi-platform code on Windows), I use AT&T syntax.


I too have 2 simple rules:
1) When working in MS env, I use Nasm syntax.
2) When working in *nix env, I use Nasm syntax.

:lol:  :lol:  :lol:
Posted on 2012-03-14 09:42:15 by p1ranha
I don't get it.... You say each tool has another syntax. What to use then?? Nasm? Masm? Whateverasm?
Posted on 2012-03-14 11:07:11 by p1Mp
Tool use depends on your program requirements.
Which CPU: x86, x64, PPC, 68000?
Which OS: Linux, Windows, DOS, Amiga?
Bitness:  16, 32, or 64 bit?
Language interface: C, BASIC, Pascal?

Beyond basic assembler syntax you'll encounter a slew of design choices and calling conventions you may not even be aware of.  High level language compilers hide a lot of bare metal complexity and Operating System dependencies...

Posted on 2012-03-14 11:41:53 by p1ranha
"Whateverasm" sounds good, but I don't think it's been written yet. :)

Seriously, it's mostly a matter of opinion. Strong opinions, in some cases. Besides personal preferences (I have "preferences", you have "biases" :) ), one real difference is "what OS will it run on?" Another is "what linkable object formats will it produce?" Masm and Tasm are "dos/doze only", as far as I know. Masm will produce OMF and msCOFF formats. I think Tasm is OMF only. Almost all the others are available to run on multiple OSen, and produce multiple linkable formats. If you like Masm syntax, but want something that'll run on Linux, Japheth's JWASM will do it. So you have plenty of choices (or "confusing decisions" if you look at it that way).

You won't go very far wrong, no matter which assembler you chose. Ultimately, they all do the same thing, and it isn't that difficult to switch from one to another, if you have to (want to). The only "wrong" decision, IMO, would be "I'm going to forget about asm 'cause I'm not the right kind of person", and I don't think you're going to do that. :)

Best,
Frank

Posted on 2012-03-14 14:52:46 by fbkotler

Ultimately, they all do the same thing, and it isn't that difficult to switch from one to another, if you have to (want to).


Yea, once you're reasonably familiar with asm it's mostly trivial to switch from one assembler to the next.
Until then, I suggest you stick with one set of tools, to avoid confusion (if your assembler uses a different syntax than your book/tutorial, it may be difficult to get code working... and if your debugger uses a different syntax from your assembler, it may be difficult to see why your code doesn't do what you expect it to).
Posted on 2012-03-14 15:23:38 by Scali
I've been following this thread for a little bit, and was wondering if one of p1mps problems finding
asm related material to read on the net could be his home country blocking some info that he is able
to access on the web?
Posted on 2012-03-14 21:43:07 by rags

I've been following this thread for a little bit, and was wondering if one of p1mps problems finding
asm related material to read on the net could be his home country blocking some info that he is able
to access on the web?


Perhaps.
Anyway, I decided to take Tasm followed by a friend's recommendation.
Thanks to all of you, for the time and help :)

p1Mp.
Posted on 2012-03-16 07:47:36 by p1Mp