What assemblers do you guys recommend for windows i know of MASM32 and nasm but not sure which one to use.

Keep in mind that i am not interested in HLA like in aoa so I'm not sure if masm32 is they way to go for me or not.
Posted on 2007-12-15 14:25:30 by shadyike
There's a lot of assemblers available, and just about any of them will do the trick.

It sounds you're a bit "new to the game", so what you want is probably a full-blown package. This community fosters the NASMX project, there's also MASM32 but I can't recommend that for a variety of reasons (including personal vendettas), there's RosAsm but I can't recommend that either (checking alt.lang.asm is reason enough, really).
Posted on 2007-12-15 15:22:14 by f0dder
Well MASM can be as High Level or as Low Level as you want it it to be (same goes for NASM w/ the NASM32 project)... to an extent. It all depends on if you want to make use of the macros involved or not. Personally I tend to use NASM, GoASM, MASM, or PoASM depending on the project. All novices want someone to suggest an assembler but truthfully it's not that simple. There isn't that much of a difference between them other than a few small distinct differences and they all have their good sides and bad sides. So it really comes down to personal preference and what you find most useful.

A quick rundown (all personal views):

FASM and NASM are pretty much the same as far as basic syntax, the major difference is in the preprocessor/macro engine. FASM macros are easier to use, and you can make very powerful macros with little effort, but NASM macros are arguably more powerful once you get the hang of them (which takes a while).

GoASM has minimal macro support but it's slowly getting better. It does have the advantage of being one of the first (if not the first) to support 64-bit systems, so it has the most stable 64-bit support of all the assemblers. As well, it has a ton of useful features (like USEDATA) that can only be found in GoASM which make writing optimized code a cinch.

PoASM and MASM are very similiar, practically identical syntax and both were written as backends to high level languages. One major difference is that PoASM supports ARM processors which makes it ideal if you wish to later write code for PocketPC or SmartPhone devices. Downside of both MASM and PoASM is that neither of them are heavily supported beyond being a backend assembler. You'll also find that *some* of the more advanced code written for MASM won't work right in PoASM without minor modifications.

Notibly these are my views, and some might say I'm biased. I don't think so but those are the assemblers I use, besides TASM which isn't worth mentioning (I've not used it in over 7 years).

Regards,
Bryant Keller
Posted on 2007-12-15 15:37:47 by Synfire
Also, note that there's a difference between MASM32 (the package by Steve Hutchinsson) and MASM (the assembler by Microsoft, NOT by steve).
Posted on 2007-12-15 16:19:34 by f0dder
FASM and NASM are pretty much the same as far as basic syntax, the major difference is in the preprocessor/macro engine. FASM macros are easier to use, and you can make very powerful macros with little effort, but NASM macros are arguably more powerful once you get the hang of them (which takes a while).

Sorry to ask offtopic here (moderators: feel free to split), but what do you base this on? I admit I know only little about NASM macrosyntax. Can you give some example of macro / feature that you think can't be replicated in FASM?

Also, if we extend term "macrosyntax" to cover extra features (besides assembling instructions), then FASM has multipass assembling, that allows some things NASM lacks (more forward referencing, "used" operator, "load" directive etc.). NASM seriously lacks either something like FASM's "used", or like MASM's "EXTERNDEF", I bet you remember this topic.

At other hand, FASM's preprocessor lacks string manipulation and preprocess time expression evaluation (does NASM have this?).
Posted on 2007-12-15 16:29:59 by vid
Thanks guy's for answering my questions looks like I'm going to try
masm32 because there are lot's(well a fair amount)  of tuts geared toward it.

So my understanding of High Level Assembly is that it's only possible because of the assemblers they take the code like in aoa and translate that into assembly terms.

I would like to stay far away from that for now till i get a good grasp on regular assembly.

Posted on 2007-12-15 16:57:26 by shadyike
If you want to learn bare-bones assembly, you probably want to steer clear of MASM32 (not necessarily the MASM assembler, though!)... the macros shipped with recent versions are pretty high-level (to the point where you might as well use a C compiler, to get better code and cleaner code, anyway).
Posted on 2007-12-15 17:17:06 by f0dder
I've switched to FASM after using NASM/MASM for several years. It is the most exposed assembler currently availible - very little is done in a hidden manner without explicit statements indicated that that is the intended result. Furthermore, the power gained from this exposure doesn't greatly increase the learning curve.

Sometimes coders would like a specific opcode when multiple are possible, but no assembler allows this kind of fine grain control. Better to encode the bytes for this situation - this is a very rare requirement. Personally, I'd like to execute code at assemble-time, but no assembler allows this either. I've been looking for faults with FASM and nothing yet is apparent.
Posted on 2007-12-15 18:02:44 by bitRAKE

I've switched to FASM after using NASM/MASM for several years. It is the most exposed assembler currently availible - very little is done in a hidden manner without explicit statements indicated that that is the intended result. Furthermore, the power gained from this exposure doesn't greatly increase the learning curve.

Sometimes coders would like a specific opcode when multiple are possible, but no assembler allows this kind of fine grain control. Better to encode the bytes for this situation - this is a very rare requirement. Personally, I'd like to execute code at assemble-time, but no assembler allows this either. I've been looking for faults with FASM and nothing yet is apparent.



Seems to be some great info on using this on there site I'll try this it is probably what I'm looking for.

Posted on 2007-12-15 21:38:05 by shadyike
Sorry to ask offtopic here (moderators: feel free to split), but what do you base this on?


A quick rundown (all personal views):


I admit I know only little about NASM macrosyntax. Can you give some example of macro / feature that you think can't be replicated in FASM?


This is something that's been argued several times in the past. In the past I've had to make compile-time checksum/encryption methods etc to show people NASM could match FASM but I've yet to see anyone do an expression parser, or something of similar complexity. In the past I was able to write a macro to tokenize and parse a macro named EXPR which worked like this:

EXPR "c=(a+b)^2*2+?",

Where c was ECX, a was EAX, b was EBX, and ? would be replaced by the value located at myVar. I gave up on the project because there was a limitation in the macro engine's string parsing which wouldn't let me recombine string values the way I wanted once seperated so I couldn't use "ecx=(eax+ebx)^2*2+myVar" like I wanted (search the board I believe the source is probably still on here).

Also, if we extend term "macrosyntax" to cover extra features (besides assembling instructions), then FASM has multipass assembling, that allows some things NASM lacks (more forward referencing, "used" operator, "load" directive etc.). NASM seriously lacks either something like FASM's "used", or like MASM's "EXTERNDEF", I bet you remember this topic.


Yes, I definately remember that topic. But then again I consider those directives, a completely different topic.

At other hand, FASM's preprocessor lacks string manipulation and preprocess time expression evaluation (does NASM have this?).


I've already talked about that, no need to go into again. (Yes, to an extent.)
Posted on 2007-12-16 00:25:42 by Synfire
I suggest you start with masm, since as you say, theres a lotta material out there to get rolling with.
Once you are rolling though, I do suggest you try a few others.
When you've tried a few, you can make a choice based on your experience and what feels right for you.

I think the choice very much depends apon your goals.
For example, I love using masm and especially coding across languages (eg superfast ocx's are very easy to sell to VB coders like you used to be, and not hard to code especially under masm/oa32), but I would not choose masm for writing a device driver, or for writing anything thats huge and lives in a single module (masm has some issues with larger projects, we have found ways around them but I think its fair to say masm is not DIRECTLY suited to large scales).
Posted on 2007-12-16 02:27:45 by Homer
vid:

Sorry to ask offtopic here (moderators: feel free to split), but what do you base this on? I admit I know only little about NASM macrosyntax. Can you give some example of macro / feature that you think can't be replicated in FASM?

At other hand, FASM's preprocessor lacks string manipulation and preprocess time expression evaluation (does NASM have this?).



     I have sometimes found that it is hard to make MACRO's do what I want, because they are often short of the functionality needed.  Especially string manipulation operations like concatenation, trimming spaces, substringing, etc.  Most MACRO languages can manipulate parameters to a degree, but not as good as is possible with a  scripting language.  So the answer is to use a scripting language for tough coding.  Most scripting languages run circles around what can be done with assembler MACRO's.  They have a much richer feature list for manipulating expressions and strings.

     Let's take an example.  In the ZIP file below, is included a C  data file (SysMets.h)which is an array of strings.  What the assembler needs from that file is a BYTE string of all the double descriptions in quotes, two tables of addresses showing where each string starts, two tables of string lengths, and a table of parameters for each string description.  SysMets.h is in a format that only the C & C++ languages would love.  Starting with a good text editor, we can make it into SysMe4_Master.inc.  Now comes the scripting language.  I used REXX, but I think that any good scripting language like Ruby or Perl would be just as effective.  So by running the REXX script SYSMET4.REXX, an output file of SYSMET4.INC, which is MASM compatible is obtained.  Now it can be INCLUDE'd in the MASM runstream.  Notice that there is no space fill bloat to the largest string size so as to make it easier to code the array.  So you can see that a scripting language can take parameters from a file, keyboard, or any input peripheral, and then output any assembler compatible code like a MACRO does, but it can do it much better.   I made the script for MASM compatible output, but it could have been done for any assembler.  To conclude, a scripting language can make a assembler that has no MACRO capabilities into a competive processor.  I included the executable so you can see how it being used.  The program came from Charles Petzolds, Programming Windows, 5th edition, which I converted into MASM.  Ratch

Attachments:
Posted on 2007-12-16 19:45:19 by Ratch
I've been working on a flexible regular expression engine for a little while now. I'd like to add regex power to search/replace function in editors, or could be plugged directly into FASM. Who knows when it will be done, though.
Posted on 2007-12-18 04:55:08 by bitRAKE