The speed of assembling is not really important, after all, it's much faster than parsing SEPPLES. Give'em all a try and pick the one you liked more. I'd choose FASM for the excellent documentation and a nice notepad. If you're going to do some WinAPI, MASM would be better - it has more headers and a nice mini-IDE, although you'll have to download the whole Visual Studio 2012 to obtain latest ml.exe.
Nasm. C++ Inline Asm would be the best but the operands are always the wrong fukken way around!
Name:
Anonymous2012-08-25 9:52
MASM32 is the most advanced and mature one out there. You should use it unless you're writing your own OS (use FASM) or are stuck on Leenucks (use NASM).
>>11
There's an Intel syntax option for g++, except that you have to remember to set it back to AT&T at the end of the inline asm block because it really is a pass-through thing.
Little things like this are what prevent me from going to exclusively *nix development. The tools are there and powerful, but their implementation is often awkward. (See also: proliferation of incompatible UI libraries, huge chains of (versioned!) dependencies, no centrally managed configuration, etc.)
>>33 The register names are SP, AX, BX, CX, DX, BP, DI, and SI. Opcode names are mostly the same as those listed in the Intel manual with an L, W, or B appended to identify 32-bit, 16-bit, and 8-bit operations.
There actually is a good, sane, logical Intel assembler?
Name:
Anonymous2012-08-27 3:03
nasm or fasm would be best to learn on. gas isn't really meant to be used independently of gcc these days, and the syntax differences, while small, will prove confusing to a beginner. Avoid masm at all costs - its macro ``syntax'' is gross even for the experienced; a novice will probably spend more time damaging their programs to accommodate the macros than they will actually learning to write for x86.
>>34
Make it even more confusing than gas by renaming all the registers, then append extra crap to the mnemonics in an attempt to fix the confusion? That's worse than gas. I don't want to know what they did with movzx/movsx.
>>37
ax and eax aren't different registers. why call them by different names when it's actually the operation being performed on the register that's different? it makes much more sense to indicate the size on the opcode name than on the register name.