• Forum
  • Lounge
  • x86 asm- masm/ fasm different syntax/lib

 
x86 asm- masm/ fasm different syntax/libraries? which should I use? win32 api surprisingly simple???

I decided to learn some x86 asm, and probably also will delve into ARM asm, so I have some assembler to work alongside my C/C++ code in future projects. I figured it was more a lesson in how the low level works more than anything id ever find useful... but some things are confusing me... and not even in the scary/daunting bad way Id imagined!

when I started out, I feared for my life and the stress it would put me under, assuming this was going to be the most complex thing yet. but so far... it hasnt been so bad.

whats even more confusing to me is the fact that all these x86 assembler programs (NASM, MASM, FASM, etc...) seem to have wildly different syntax -- sure the basic push/pop or whatever are the same, but its like there are entirely different implementations of things -- a hello world program in MASM is different than in FASM, simply because of the macros/libraries included.

I got kind of frustrated with MASM -- not because it was hard -- but because it was too similar to a higher level language with all the macros (stdout) included with it -- and I WANTED to be slightly masochistic and actually get close to the metal with this. intentionally.

so I switched over to FASM, and im not sure if I will stick here or not yet. It also seems pretty simple... although the fact that all the libraries are entirely different than MASM, and its not as well documented online (less tutorials) confuses the heck out of me. Im not sure if I should just move back to MASM and try to work around the macros by not using them, or stick with FASM

what surprised me yet even MORE when in fasm was a few simple examples using the WIN32 API.

its like graphical programs are actually EASIER to write using ASM. WTF??? shouldnt everything be harder just because its ASM? why cant I open up a window in C so easily? even with MFC in visual C++, just coding a window by hand takes quite a few lines of code (or at least one long line) where I can make a quick messagebox pop up in only ONE line of ASM. not sure if this is a macro or something simplified too. but damn. its almost like I could write pieces in inline ASM and then code the rest in C for some quick win32 apps.

like, code the buttons/windows in ASM and leave the functions to C... but for some reason Im doubting its going to be this simple forever. I probably just looked at really simple examples. but either way, fact is, its not nearly as complicated as I feared.

either way, I intend to keep learning ASM.

Can anyone here reccomend which version of intel ASM I should keep working with (I really dont feel like learning AT&T syntax, but if someone can provide me with a good reason why I should, Im up for that too -- whichever is best for the job!)

and also, how can I start implementing ASM inline in my C/C++ code if I ever want to? Im assuming I can google a tutorial when im not lazy, but I didnt find anything quick right off -- in fact, resources on ASM in general seem to be out there, but much more scarce than C/C++, Pascal, C#, or other languages. and when would I really WANT to mix it in with my C Code???

I mean, if its really always this easy to call win32 API functions from ASM. hell, I may just never actually code them in C++ again just out of laziness :P
Last edited on
shouldnt everything be harder just because its ASM? why cant I open up a window in C so easily?
Well, the Assembly you saw was in all certainty just calling the C API, so there's no reason why opening a window from C should be harder. If anything, many calls should be easier in C, because you don't need to declare constant strings in a data section. You just use string literals.

even with MFC in visual C++, just coding a window by hand takes quite a few lines of code (or at least one long line) where I can make a quick messagebox pop up in only ONE line of ASM.
Yes, opening a messagebox from C/++ also takes a single function call. However, the Windows API gets unwieldy as soon as you want to do anything even moderately interesting. That's why libraries such as MFC exist.
A hello world example is not a representative sample of how streamlined development with a given tool will be.

Can anyone here reccomend which version of intel ASM I should keep working with (I really dont feel like learning AT&T syntax, but if someone can provide me with a good reason why I should, Im up for that too -- whichever is best for the job!)
AT&T syntax is evil. Only GAS uses it, AFAIK.
Personally, whenever I need to write any Assembly, which isn't often, I go with NASM. MASM is for Windows programmers stuck in the early 90s.

and also, how can I start implementing ASM inline in my C/C++ code if I ever want to?
Keep in mind that, just like how Assembly syntax varies between assemblers, inline Assembly syntax varies between compilers, even within the same platform.

when would I really WANT to mix it in with my C Code
For example, it's useful if you don't want to execute a function prologue and epilogue, if the necessary code is just a few instructions long. It has to be handled carefully because I don't think compilers are very good at dealing with register allocation around inline Assembly blocks.
Last edited on
well, working with this does seem fun and educational. Ive gone back to MASM for the time being just because there is more documentation online for it.

I intend to try and write a few simple things -- like porting a copy of my sieve of eratosthenes C++ code (going to be a challenge -- I can be more memory efficient in ASM easily because of registers, but I may run out of bits in the registers to handle the math operations -- in fact, I know I will, so I have to see if I can either use stack space without a register, or actually allocate memory to do the operations in at the cost of speed and efficiency)

and also a simple memcpy routine -- just because ive seen people online recommend it to others learning.

I can definitely see this being more efficient if I had a routine I wanted to control bit by bit, although for the most part writing C Code IS easier.

it was in fact just a few C routines being called in from MASM or FASM -- which I still dont understand -- why do C routines even work without a compiler??? I didnt think they were already broken down into ASM - but I guess they must be.

Either way, it kind of tricked me into thinking it was even simpler than it is -- but to be honest, as hard as it may be, its not quite as dark and scary as I imagined it being. I thought it would be as hard to understand as binary or straight hex, and thats simply not true at all...

its like a rudimentary little programming language -- I guess thats what it really IS at heart after all
OP wrote:
which I still dont understand -- why do C routines even work without a compiler??? I didnt think they were already broken down into ASM - but I guess they must be.


That's what a shared library is, in this case Windows calls them DLL's which is a file type that I'm positive you've heard of before.
Computergeek01, I'm not sure I understand your explanation...
@ NoXzema: OP's question seemed to be, "Why do these C functions work without a compiler?". Without getting into too much detail about external linkage, my answer was that they are already compiled and made available to your program in the form of DLL files.
That's true but it's not specific to DLL or shared libraries. Object files, executables, etc. all have compiled code. It's just in a slightly different format. I guess the confusion is you seem to imply that it's specific to DLLs.
I'm trying to keep it simple. DLL files are the best examples, in Windows, to demonstrate what dynamic linkage is. Like I said, I wanted to leave out external linkage and that other stuff. When you get into that it's too easy to segue into IPC and at that point you've lost track of the question at hand which is "Why do C functions work in ASM without a C\C++ compiler?".
Topic archived. No new replies allowed.