Hello.. Its me again, the noob. Today I was looking through alt.lang.asm and came across this discussion :
http://groups.google.is/group/alt.lang.asm/browse_frm/thread/d044ad5ea7b2a89b/a6858b773d28f127?lnk=st&q=wm_size+assembly&rnum=2#a6858b773d28f127

Now, a guy called "betov" wrote this>
 
MASM32.
Not considering perfect stupidites, like HLA, that does
not deserve more comment from me, MASM32 is the worst
of the actually available Assembler. In fact, it is not
an Assembler, but a Compiler for Assembly Language. To
know what it outputs, you need a... Disassembler :))
Plus, its syntax is radicaly stupid and faultive.
Nowadays all the actual Assemblers conform, more or less,
with the basics of NASM.


As a new assembly programmer that is starting out with my brand spanking new masm32 package, am I starting on a bad path? Is masm really that much crap? or is he full of it?

if so, what is the best alternative?
Posted on 2006-06-22 04:41:44 by talmir
talmir,
Betov said MASM32 that is a IDE for masm there is a difference
MASM32 is a IDE that use's masm assembler.

The assembler is the best really, but sence Betov used the word MASM32
I would assume he is talking about the IDE.

Which now is just a matter of taste, so I guess he has his right to say
such about the IDE, but that alone does not make it true.

MASM32 really is a package, the IDE is really called Qeditor and it is a
simple editor that can build a project by invoking the masm compiler.

The IDE is good for beginners but it can only handle one file in
a project at a time. A begginer would be better off making projects
that are single file projects or including other files using the include
directive.

But you would still have to open another Qeditor to edit the other files
in the project.

So it is upto the programmer if MASM32 is good or not. I would not let what Betov has to say change your mind.

Just use it. learn, and once in awhile try other IDE's made for assembly,
and you may find something better that fits your taste just as Betov may have,
But his openion is just his.

Zcoder....
Posted on 2006-06-22 05:19:33 by Zcoder
talmir: don't pay attention to Betov, he's quite mad :) - heck, don't pay much attention to anything in ALA, hutch-- has unfortunately turned it into his private garbage heap.

MASM is a fine enough assembler. It has some bugs (but those mostly show when you use advanced macro features), but overall it works well and is fast. Whether you like the syntax or not is a personal matter.
Posted on 2006-06-22 06:26:24 by f0dder
Betov is just cranky because people aren't flocking to use his RoSAsm assembler..

Betov says a lot of stuff, MOST of it should be taken with a grain of salt.
Posted on 2006-06-22 06:34:10 by Homer
Yeah, I forgot to tell talmir about Betov.
But I guess I was just trying to keep the post clean
of nocking other people for tha sake of nocking them.

But it is true, Betov has a dislike of Microsoft that shows
in his posts, as well as a dislike for anyone who does not
see his vision of the new assembly revolution he has created.

The true fact is assembly has no revolution or so called rebirth
as assembly can not be redefined to make it simpler, without
hurting the language.

The only thing you can do to help make the language easier to work
in is to make tools that help keep it more manageable, But this to
assumes the programmer knows the language already.

Anything else will force the user into a design mythology  that the
creator of such IDE has thought out.

This also goes for assemblers, like Betov's, infact Betov should pipe down
and just let his assembler do the talking, after all, it's all about taste
and not some new revolution.

Zcoder....


Posted on 2006-06-22 07:00:07 by Zcoder
MASM32 that is a IDE


Masm32 Is not an IDE, is a SDK!
Posted on 2006-06-22 15:57:12 by shaka_zulu
talmir,

yes, masm is crap... some peoples will try to find euphemisms for 'crap', but the truth is that the only good thing about masm is the include files, that are very complete

ancev
Posted on 2006-06-23 08:09:35 by ancev
Vecna, what's so bad about MASM if we forget all the "politics" of it?

It has a few bugs (mostly macro related) and personally I prefer the nasm/fasm way of memory access... but other than that?
Posted on 2006-06-23 11:09:42 by f0dder
I think Vecna is confusing MASM (official MS ml.exe) with MASM32 (the unofficial package)?

Whatever your feelings about MASM32 are Vecna, please don't let them interfere with talmir's question about the assembler (ml.exe) itself.

MASM is a completely fine assembler. Though I use NASM myself, I would recommend MASM for just about anyone (especially those coming from a HLL background). Just pick what flavor (assembly syntax) suits you best, and go with it :)
Posted on 2006-06-23 18:24:33 by SpooK
Back in the days of MASM 5.x, the program was not ml.exe, it was masm.exe

Paul
Posted on 2006-06-24 02:33:32 by PBrennick
Maybe i am mad, cranky, or whatever, but something suprises me, here, that is that none of the participants seems to be able to tell a beginner _WHY_ i am saying that choosing MASM, as an Assembler is a bad idea. So here is it, from the horse:


1) MASM is not a true Assembler. Why:

- It includes internal macros that break the holly 1:1 correspondance. That is, what an Asmer writes in his source, is what he MUST get in his produced File. If this absolute rule is broken, this is no more an Assembler, but, in this case, a "Compiler for Assembly Language", and if a beginner means to learn Assembly, he must use an Assembler.

- It includes hidden replacements (Example RET, that may as well be a RET than a Procedure EXIT -... same comment as above... -).

- It includes hidden features, like the automatic stack Alignments, and so on -... same comment as above... -


2) MASM has several limitations that you all should know about (Strings length, falling on its knees on to huge Tables, and so on...).


3) Maybe the most important point for a real beginner: The Syntax of MASM is seriously faultive, because of the artificially introduced confusion, in between "Content" and "Address".

This last point has been solved the clean way by all of the actual Assembler, which conform (with some minor variants) to the new Standard introduced by NASM, which was popularized under the form of the now well known sentence: "Everything is an Address".

That is, any Symbol (not considering Equates and Macros) are _Addresses_ and in no case the content of the given Address. In other (generic) words:

> LabelName: DB 123

> Mov eax Label Name  ; Stores in eax the Address, in Memory of this Symbol.

> Mov eax ; Stores the Value 123 stored at this Memory Address into eax.


All of the actual Assemblers (NASM, RosAsm, FASM, GoAsm) conform, generaly speacking, to this choice of simplicity and of non-confusing convention. This point is extreemely important, particulary for a beginner, because the kind of bugs introduced by a faultive syntax, on this critical point, may be very painfull to track down.


So, instead of pointing a beginner on how "Betov" is a clown, you'd better try to really understand the problem and _effectively_ push the beginners into the proper direction, after having provided the wishable informations.


Betov.

< http://rosasm.org >

Posted on 2006-06-24 05:11:59 by Betov
From what I have seen on alt.lang.asm, then you betov, indeed are a clown not to be taken seriously.. I have seen you call other people assholes and "boy´s" often enough to know this.

However..

I will accept your point of the masm macro syntax.. I may try to use another compiler for a while.. However I dont see what difference a cmp and jmp calls to the .IF macros of masm.
Posted on 2006-06-24 05:27:34 by talmir
tell a beginner _WHY_ i am saying that choosing MASM, as an Assembler is a bad idea.


In spite of Masm's bad design as you describe, how it happens that a lot of users are using this tool?  :)  Dont't tell me that all of us we are hypnotized :) And if you are thinking that users are still insisting on this "bad choice" , why you are wasting your time here?  :)
Posted on 2006-06-24 05:32:29 by Vortex
Seeing as some people would rather turn this thread into a Flame War, I have now moved it to "The Crusades".

Seeing how it is now in this forum, you are required to provide hard data and facts, not personal opinion and conjecture.

Any posts without hard data backing it up, should be ignored.
Posted on 2006-06-24 06:13:36 by SpooK
Hi Talmir,

All assemblers have at least a few high level contructs available, it is up to you whether you use them or not. Personally I use GoAsm which is a very low level assembler and probably has the least, however, they are there none the less. There are none as far as I know that do not have some sort of pseudo-macro for the RET instruction, all assemblers will modify it by adding an argument if necessary to balance the procedural stack, for example in a WndProc you may type RET but the assembler actually uses RET 16. MASM is arguably the most high level with .IF/.ENDIF etc... but you are not forced to use them, you can code at the 1:1 ratio if you prefer.

Under Betov's argument that if you require a disassembler to view the output it is not an assembler, no modern assembler would pass the test. For example LOCAL buffers allow for label names but unlike global ones do not resolve to an address, they resolve to an offset from the stack pointer . There are a few things about MASM that I find annoying, the use of LEA in the INVOKE pseudo-macro is probably the biggest imo but it is an assembler as it allows you to write code in x86 assembly language and compile it into a machine readable format which is then converted to a PE file suitable for execution on a Microsoft OS via a link utility.

MASMs strengths...

Architecture targetting : directives allow you to specify the minimum x86 architecture that you would like to run on and opcodes that are only available in later versions will throw an error.

Speed : MASM is not the fastest assembler but it is not the slowest either, many will complain about it's speed and try to make believe that in a multi-GHz environment it makes a difference but they are just blowing smoke.

Standard Intel syntax : MASM uses the standard Intel (opc dest,src) syntax.

Flexibility : Many features and syntactical arrangements are optional, for example you can use square braces to indicate the contents of a memory address or not and it will be implied.

Allowance for multiple sources : MASM allows you, through the include directive, to use multiple source files.

LIB support : MASM can use any code library the conforms to the Microsoft C standard LIB format, for example ZLIB for Zip compression.

COFF output : MASM outputs in COFF format, a format that is required by many debugging tools and allows you to use non-microsoft products to later link into executable format. This does not force you to use the in some cases substandard tools that work only with some assemblers and allows you to have a common set of tools across all of your language platforms.

Fully modularized : MASM, like all modern assemblers, is fully modularized allowing you to choose what IDE, linker etc... you wish to use with it.

As for the drawbacks of MASM there are also many of those, it is up to you to decide whether the advantages outweigh them. Personally, I found a few of the drawbacks were too much for me to live with and chose Jeremy Gordon's GoAsm/GoRC/GoLink package which closely follows MASM in syntax and features but fixes most of it's problems.

Donkey
Posted on 2006-06-24 06:15:49 by donkey
That being said, Betov does touch on one very important thing.

MASM does indeed descend from the "C style" mentality; Typedefs, direct variable access over label addressing, amongst other things.

I would take the rest of what Betov said with a grain of salt, as it tends to result from his elitist attitude. MASM is indeed an assembler in the sense that it can assemble opcodes to machine language. To make a long story short, Betov's self-established definition of what an "assembler is", is why MASM fails to meet that standard, in his view.

If you are coming from an HLL background, MASM would be a good step down into learning ASM. Get involved with NASM and FASM as well. I can't speak for RosASM as I won't touch it due to the elitist attitude of Betov, but download it and make your own opinion as you choose.

If it is one piece of good advice about... well... any situation really, the more people try to steer you away from something (without good reason), the more you should investigate why. Ignore the hype and learn in the manner you wish to learn :)
Posted on 2006-06-24 06:22:18 by SpooK
MASM is extremely powerful, easy+fast to code with, is the reason I'm not a C++ coder in the x86 domain.
The macros are not buggy, but tricky when complex. But once you've seen enough macro-listings (how and why locals are renamed/used), you understand them completely.
There are bugs in "proc", but only if not passing dwords or qwords as params. Which is a weak argument, I never noticed myself limited by it.

Save me the idiocy of typing exactly what the disassembler should show - I don't have that much time to waste unnecessarily. Learning what MASM outputs is easy, and later helps a lot. It also helped me start with asm.
Don't bug me with having half of my asm code consist of square brackets. You need the data itself (not its address) in 95% of the time.
Don't give me weak macro capabilities. I have too much code to automate. Writing the same thing hundreds of times again and again, it's no good for me. And then if I have to fix this code, rewriting it those hundreds of times is killing my motivation.
When I need purest optimization, I am not limited by MASM.

Btw, PoASM and SolASM are getting near MASM, and hopefully they'll outshine it :)
Posted on 2006-06-24 06:59:32 by Ultrano
Ultrano,

    MASM has one glaring weak spot.  It cannot generate floating point constants.  Can POASM and the other assemblers you named fulfill this function?  Shame on any assembler that cannot do floating point constants.  Ratch
Posted on 2006-06-28 23:13:42 by Ratch
I actually did not know that limitation. I guess it's a good thing I skimmed this thread, so I won't encounter that problem if I ever have need of a floating point constant...
Posted on 2006-06-28 23:19:06 by Bobbias
Bobbias,

... so I won't encounter that problem ....


    Knowing the problem exists won't solve it or make it go away.  You will encounter that problem if you need a floating point constant.  There are ways to get around it, but they involve extra work or less efficent code.  Ratch
Posted on 2006-06-28 23:25:25 by Ratch