Hello,

How can tell witch is better.
Is MASM32 better or FASM?

There are a MASM32 Source in FASM converter?

Thanks..
Posted on 2003-02-18 03:48:23 by Fred
Fred,

You have to translate the Masm32 code to Fasm.There is no such a translating program. :)
Masm32 or Fasm? I think the Flat Assembler is suitable for small projects.Another advantage
of Fasm:it produces smaller code and offers a lot of macro capabilities.On the other hand,
if you want to use libraries,The Macro Assembler is preferable.
The selection depends on the scale of your projects.

Regards,

Vortex
Posted on 2003-02-18 04:38:26 by Vortex
My intention here is not to start a flame war, is to answer a direct question and to try to be of some help, so here I go...

For my own concern, MASM is pretty cold dead.
Since FASM 1.40, there is nothing I miss from the MASM world and I didn't see any limitation on size for a project.
The only drawback is the quantity of stuff already coded in MASM syntax, but this is a banal matter of time.

I keep MASM installed only to study the very good code found on this board and especially the excelent work of KetilO.

I often do the translation from MASM to FASM (using a dissassembler and rubbing out the HLL constructs). I think that an auto-translator is a worthless effort, but I could give some hints (besides those found on FASM documentation):

Posted on 2003-02-18 11:22:03 by pelaillo
This would actually be a pretty cool project to take up, or even better, a program that works on translating many types of assembler code to another type, through the use of modules
Posted on 2003-02-18 11:42:30 by kairon

How can tell witch is better.
Is MASM32 better or FASM?

Pesnoally I think MASM is better for beginners (or ppl learning asm after they've lerned some HLL, like me).
FASM is gives you even more controll over you code, the tradeof is some more coding to do (sometimes desired sometimes not). And if you're about to write an OS the FASM is the choice, since the MASM licence prohibits you to write an OS with it (there is a post in this forum... here it is: http://www.asmcommunity.net/board/index.php?topic=7494&highlight=MASM+illegal).
FASM is also easy to set up for raw binaries (plain machine code, no PE headers or such, good when writing an OS for instance)

I use MASM when I want to use resources and want to make life easy (I don't have to fill in the .idata, with or without the help of the fasmutil (can be found on the board, try the search function :))). I use FASM when I work on my OS-learnign project (to learn how an OS and the computer may work, to get some perspective to simple windows progamming; it's not anyhing like Windows, it don't give me BSODs, yet...) and when I learn how to progam in Linux. (I use FASM more and more, mabye I should translate a few MASM project to FASM before they grow too large :rolleyes: )
Posted on 2003-02-18 14:20:30 by scientica
For me, Fasm is a lot better since it's still in progress. Right now though, there are still a couple of things I miss, for instance, I have libraries from microsoft compiled with visualC that I can link with masm but not with Fasm yet. For all the other uses, Fasm is better. Even if it's a big project, I can manage to get "longer" compilation times as for me it's very fast. Even better, I'm sure I don't have bugs related to my modules not speaking one to another...

For me the other advantages are easy support for unicode, easy importation of files, complete control of the code, not having to bother with Microsoft's license, dos & linux support, other os support and it will continue to improve. The small size is a big plus since it's not required to move megs of libraries when I clean up my hard drive and I can even fit it inside a floppy or ftp site to work on my projects somewhere else.

The only bad side is that it's still young meaning there isn't as many tools to help as masm. The gap is closing every day and it's already very usable.
Posted on 2003-02-18 16:29:40 by Silas
Silas,

You wrote:

>for instance, I have libraries from microsoft compiled with visualC that I can link with masm but not with Fasm yet.

You can link those libraries with Fasm. :)

You can link the masm32.lib with Fasm, you must be able to do the same thing with VC libs.

Have a look here:

http://www.asmcommunity.net/board/index.php?topic=10663

Regards,

Vortex
Posted on 2003-02-19 02:01:57 by Vortex
FASM is indeed very good, but we can not say it totally makes MASM useless and outdated...

First thing, is that MASM (ml.exe) is thought as a part of a programming package (I am not speaking of MASM32 in itself) and MASM is only a compiler that outputs an object file, basically...
FASM outputs plain binary files (PE or other) even if now, it is possible to use it as an obj.
For relatively big projects, it is nearly-indispensable to use other tools like linkers, to link it against other libraries... for example. So, why not use to MASM directly that has been tought for these uses ?

MASM also support debugging informations, something that FASM is (up to now) totally unaware of. I know this feature is planned, but programmers that are used to symbolic debugging are not going to change it for plain dissasemblers or debuggers. It just a problem of project maturity, here though. Not everything can be made at the same time.

MASM has generally fine constructs and a fine syntax, when it comes to structures ie...
FASM syntax is sometimes better (ie, rb) but sometimes worse or at least unclear... perhaps mainly because it aims to be a "multi-platform" assembler that has to deal with different case with nearly the same keywords. The problem is then much more difficult.

FASM lacks some features MASM has for years: ie, a real sizeof operator that works accross variables and structures (defining labels to do that is a time waste and not very professional imho), etc.

Sure, FASM "patches" itself with macros, but some of them are not included in the official packages, and it still is important features, and you always have to include a file to have this assembler feature or this one: very annoying imho. An assembler must be in my opinion a program with most useful features directly included: not an interpreter. Of course, there is advantages to this: macros customizations, etc... but is it useful everyday and for most people ? and a feature can anyway always be overrided by a macro (even in MASM).

Another thing, about resources files, FASM does not know them "naturally", but implement them in a similar, but still different, textual langage. You can't just copy paste your RC file generated in a resource editor.
If you don't want to lose much time, you finally compile it and link it with ie, the microsoft linker, against the FASM generated object file. You then lose all the nice features FASM has when it comes to binary output (I have achieved to have a 1.5 KB dialog box with it, and I repeat not window, dialog) because it is the linker that cares about the final binary output after that.

Sure, MASM is not always an 1:1 assembler, but when you write code and explicitely tell to exclude prolog and epilog code and don't use too much HLL statements, you can assume that most of the code you write will be exactly the same...

In short: FASM is a very interesting project, that is able to do things that no other tools are able to do, but his major problem is to not be easily useable for big projects, because a bit too much low level, sometimes totally unecessarily. I think it is a major advantage for it too still be in heavy developpement, but it is also its major disadvantage.
I think FASM should try to simplify itself, to simplify the live of the programmer everywhere it is possible without decreasing the quality of the output files.

I don't expect to make the FASM project changes: I just explain why I don't find it all the time the best assembler. In terms of performance, it is, for sure, the best... in terms of usability in the real world and daily routine, it still has some progress to do.
Posted on 2003-02-19 06:06:26 by JCP

MASM also support debugging informations, something that FASM is (up to now) totally unaware of. I know this feature is planned, but programmers that are used to symbolic debugging are not going to change it for plain dissasemblers or debuggers. It just a problem of project maturity, here though. Not everything can be made at the same time.

Debugging info is superslouos, and since not body but you should be "debugging" your app then there's no problem, just fire upp Olly and find the error and gaze uppon the source files in case you wonder what you named that jump or proc...
Posted on 2003-02-19 23:54:07 by scientica
scientica
Debugging info is superslouos, and since not body but you should be "debugging" your app then there's no problem, just fire upp Olly and find the error and gaze uppon the source files in case you wonder what you named that jump or proc...


If I'm debugging an app which I wrote why would I want to sit staring at numbers when I have the choice of working from the source code? The source code is a valuable resource it's foolish to not utilise it when debugging.

That's the difference between Fasm and masm. Theres' soo much more that fasm could do to ease the burden on the programmer...just look at all the post's on implementing masm features in fasm macros! Clearly some fasm user's are more sane than other's :tongue:

So Fred here's my advice...If you want to program in assembly so you can say you do, then fasm'll probably get the highest eyebrow raises( what with all the word you have to put in. Otherwise when it comes to programming for windows then masm is in reality your best choice. An inspite of what scientica says should you ever really have the need for a debugger then believe me you'll appreciate source level debugging.
Get masm and get a debugger capable of source level debugging
but keep an eye on fasm.
Posted on 2003-02-20 22:32:02 by MArtial_Code
I love FASM because the two weeks I spent learning asm, I did so with debug.exe. I then used masm as it came with MS-DOS 4.0. However I didn't like all of the addition steps required to just create a *.com file.

Somehow, I can't remember, I discovered Win32Asm and FASM.
Posted on 2003-02-20 23:36:46 by eet_1024

If I'm debugging an app which I wrote why would I want to sit staring at numbers when I have the choice of working from the source code? The source code is a valuable resource it's foolish to not utilise it when debugging.

It's a bit hard to find run time bugs in source code.
Some debuggnig is easier in Olly than in source, at run time for instance. (And it also some lazyness in it, since Olly quickly shows me where I made the "typo" :))
But you're right, when programming in FASM a debugger is a bit superflouos, but still debuggers are usefull.
Posted on 2003-02-20 23:41:37 by scientica



If I'm debugging an app which I wrote why would I want to sit staring at numbers when I have the choice of working from the source code? The source code is a valuable resource it's foolish to not utilise it when debugging.


This is the idea MArtial_Code. My fasm sources look quite the same in OllyDbg. If I am going to use HLL thingies, I prefer to do it in C/C++ being more productive.
I suggest to start using FASM, because it is easy to figure out how the system works, understanding Win32 programming in asm from the basis and not doing a painful conversion of code between HLLs and assembly, where the result is a half-way between the two worlds.

It is not easy to cut out the lot of crap added on years of developement of languages. Compromises given by very particular needs and to provide compatibility to older crap, so the crap in top of the crap and this hapens also in MASM.

I start learning win32asm in MASM and I want to save the time of everyone interested in learning this stuff today. Assembly is not lowlevel-C.
Posted on 2003-02-21 03:06:22 by pelaillo
You guys are missing the point. There are already what I'd call HLL constructs in fasm which I/m sure you already use: ...labels,structs,unions,data specfiers etc. These all automate some basic tasks. when you use them you're telling the assembler to hanle the specifics and it does by substituting offsets and reserving memory. The same applies with if/else/while/repeat statements.
for eg ample:
I could code a block like:
if: 

cmp eax,NUM
jle error ;(signed)
push eax
push ecx
call Func1
jmp endif
else:
push NUM
push ecx
call Func2
endif:


or I could write
.if sdword ptr eax<=NUM

invoke Func1,ecx,eax
.else
invoke Func2,ecx,NUM
.endif

The two forms assemble to the same binary and masm allows both forms but I know which one I prefer.

Pelaillo mentions productivity well in the world of assemblers masm is miles ahead of Fasm when it comes to being productive.
by Pelaillo Assembly is not lowlevel-C.
your correct but that doesn't mean it has to be a pain.
It's time to open your eyes!!!
Posted on 2003-02-21 05:59:43 by MArtial_Code
Maybe,C is sometimes high-level assembly. :)
Posted on 2003-02-21 06:25:36 by Vortex
Originally posted by MArtial_Code
your correct but that doesn't mean it has to be a pain.
It's time to open your eyes!!!


MArtial_Code, in fact FASM opened my eyes.
Since 1998 I used to program in MASM following your style, following Iczelion's style. I've had hard time to figure out the mind-trocities in MASM syntax and the reasons I culdn't figure out a lot of things.

My work has nothing to do with programming, so I find myself with very few time to dedicate to my favorite hobby: programming in assembly. FASM and its macros avoid the lacks on understanding the code, so this is the real reason I suggest a newcommer to start from there.

Only the time will say the final word so...keep coding!

Thanks,
Posted on 2003-02-21 07:27:52 by pelaillo

FASM is indeed very good, but we can not say it totally makes MASM useless and outdated...

First thing, is that MASM (ml.exe) is thought as a part of a programming package (I am not speaking of MASM32 in itself) and MASM is only a compiler that outputs an object file, basically...
FASM outputs plain binary files (PE or other) even if now, it is possible to use it as an obj.
For relatively big projects, it is nearly-indispensable to use other tools like linkers, to link it against other libraries... for example. So, why not use to MASM directly that has been tought for these uses ?


Ouch! That surprises the heck out of me.
I've been using FASM to create .OBJ files as output from the HLA assembler
for about a month or so now. Trust me, FASM produces fine OBJ files.
They link with MASM-assembled code just fine (and MASM code seems to link
with FASM-produced object files fine too, though I will admit I haven't done
as much of that as I have the other direction).


MASM also support debugging informations, something that FASM is (up to now) totally unaware of. I know this feature is planned, but programmers that are used to symbolic debugging are not going to change it for plain dissasemblers or debuggers. It just a problem of project maturity, here though. Not everything can be made at the same time.

MASM has generally fine constructs and a fine syntax, when it comes to structures ie...
FASM syntax is sometimes better (ie, rb) but sometimes worse or at least unclear... perhaps mainly because it aims to be a "multi-platform" assembler that has to deal with different case with nearly the same keywords. The problem is then much more difficult.

FASM lacks some features MASM has for years: ie, a real sizeof operator that works accross variables and structures (defining labels to do that is a time waste and not very professional imho), etc.

Sure, FASM "patches" itself with macros, but some of them are not included in the official packages, and it still is important features, and you always have to include a file to have this assembler feature or this one: very annoying imho. An assembler must be in my opinion a program with most useful features directly included: not an interpreter. Of course, there is advantages to this: macros customizations, etc... but is it useful everyday and for most people ? and a feature can anyway always be overrided by a macro (even in MASM).


Actually, MASM has a *tremendous* number of features not present in FASM.
That's the big difference between having a team working on a product for nearly
25 years and having a single programmer working on the product for 5.
Unless you're really advanced, though, you won't miss most of those features.


Another thing, about resources files, FASM does not know them "naturally", but implement them in a similar, but still different, textual langage. You can't just copy paste your RC file generated in a resource editor.


MASM doesn't know about them, either.
Just like FASM, you have to run them through a resource compiler.


If you don't want to lose much time, you finally compile it and link it with ie, the microsoft linker, against the FASM generated object file. You then lose all the nice features FASM has when it comes to binary output (I have achieved to have a 1.5 KB dialog box with it, and I repeat not window, dialog) because it is the linker that cares about the final binary output after that.

Nothing at all wrong with running FASM output through a linker.
As for the size explosion, a lot of that has to do with FASM not supporting alignments
too well in object files (it seems to default each output module to 16-byte boundaries,
AFAIKT). Of course, shooting for the 600-byte "Hello World" program is a waste of time
since any practical application is going to use 4K code, 4K data, 4K stack, and possibly
some additional room for Win32 API sections as well.


Sure, MASM is not always an 1:1 assembler, but when you write code and explicitely tell to exclude prolog and epilog code and don't use too much HLL statements, you can assume that most of the code you write will be exactly the same...


FASM isn't exactly 1:1 either. NASM is closer in that regard.
But who really cares? As you said, if you don't want to use the high-level features,
ignore them. They're nice, though, if you do want to use them (versus, say FASM, where
the option to use them is not available).


In short: FASM is a very interesting project, that is able to do things that no other tools are able to do, but his major problem is to not be easily useable for big projects, because a bit too much low level, sometimes totally unecessarily. I think it is a major advantage for it too still be in heavy developpement, but it is also its major disadvantage.
I think FASM should try to simplify itself, to simplify the live of the programmer everywhere it is possible without decreasing the quality of the output files.


No question that MASM is a much more sophisticated product and would be more suitable for large projects. Then again, you could make the same argument about C :-)
Certainly FASM's aversion to working well with library files is a big black mark against
it for large projects. Then again, if you simply use FASM to assemble the source file and
then use a linker to combine them, it does okay. You do lose some optimization when you
do this (a fact of life when combining pre-assembled files), but nothing tremendously major.
The biggest difference I see between MASM and FASM with respect to object code output is that FASM truly supports BSS segments.



I don't expect to make the FASM project changes: I just explain why I don't find it all the time the best assembler. In terms of performance, it is, for sure, the best... in terms of usability in the real world and daily routine, it still has some progress to do.

The good news is, MASM is still there for those who need more power than FASM offers.
Posted on 2003-02-21 20:41:41 by rhyde

Ouch! That surprises the heck out of me.
I've been using FASM to create .OBJ files as output from the HLA assembler
for about a month or so now. Trust me, FASM produces fine OBJ files.


Did I say that FASM was unable to produce obj files ? I even said that it was possible !


Actually, MASM has a *tremendous* number of features not present in FASM.
That's the big difference between having a team working on a product for nearly
25 years and having a single programmer working on the product for 5.
Unless you're really advanced, though, you won't miss most of those features.


I know that Tomasz is alone to maintain this project, and don't misunderstand me, I don't blame him. I rather encourage him because I think FASM will probably be one day the best assembler output-wise and feature-wise.
But I am sorry, a real sizeof is not something really advanced... only low-level zealots think that it is better to hard-code everything, which is a programming mistake.


MASM doesn't know about them, either.
Just like FASM, you have to run them through a resource compiler.


It is funny how you seem to want to make me say what I didn't. :grin:
My point was that FASM invented a sort of resource langage of its own that is supported by no tools, by no dialog editors, etc...
It would have been more pratical to use the format from MS, which is widely used, wouldn't it ?
Of course, you can always link them with a linker, but you then lose the main feature of FASM imho: very small output that can only be produced by a direct executable output, as far as I tried.
Then, why not use MASM directly, that has more feature that makes the programmers life easier ?


Nothing at all wrong with running FASM output through a linker.
As for the size explosion, a lot of that has to do with FASM not supporting alignments
too well in object files (it seems to default each output module to 16-byte boundaries,
AFAIKT). Of course, shooting for the 600-byte "Hello World" program is a waste of time
since any practical application is going to use 4K code, 4K data, 4K stack, and possibly
some additional room for Win32 API sections as well.


Personally, I only code in full assembly when I need very small and fast programs... and it is in this sense that FASM is very nice.
For apps of a serious size, I use plain win32 C that produces, with proper settings, as small executables that a FASM or MASM with a linker...


Then again, if you simply use FASM to assemble the source file and
then use a linker to combine them, it does okay. You do lose some optimization when you
do this (a fact of life when combining pre-assembled files), but nothing tremendously major.


I agree.
Nothing major to not use MASM that has more useful features for the programmer.
My point is not to say "MASM is better than FASM" or the opposite but to show what are, based on my experience with both assemblers, FASM's current flaws.
It is because of such flaws that people that use assembly for relatively big projects will continue to use MASM, because they see very few benefits to switch to FASM and lose some interesting MASM features.
The day it will change, MASM will be very near of its dead.
Posted on 2003-02-23 13:43:40 by JCP
Hi

I wrote thousands of lines in asm for Masm32, now I want to port some to Fasm.
(I plan to write for x86-64 in a few months, and will probably build my own compiler)
The problem is with the macros : I really loved them in Masm, I have dozens, and I would like to translate them.

I've read Fasm 1.47 doc and tried and did not manage to do the equivalent of this :

;masm32 macro
m1 MACRO ARG1,ARG2
LOCAL mytry,mytry2
mytry equ prefix
mytry2 equ suffix
mov edi,offset prefix&ARG1&suffix ;a global label
...
jne edi
ENDM

OK with the #ARG1, or #ARG1#ARG2 it works. With LOCAL variables it does *not* work, with globals the same.
Isn't there another way than doing a "macro m1 ARG1,ARG2,prefix,suffix" followed by a "mov edi,offset #prefix#ARG1#suffix" ? How do you mix efficiently variables and pure text into macros, please ?
It is quite time-consuming to write a Masm2Fasm converter ; the .inc below is partially untested and does part of the work, a great editor like Radasm does a little too, I even began to write a Qbasic program for the easiest translations :)
Posted on 2003-07-04 02:14:59 by valy