Why Learn MASM

[armiof1]

I learned MASM in university about 2 years ago and i am now tying to get a better understanding of where its use is applicable. I currently program in .net c++, c#, vb.net and java. I would like to be able to leverage my knowledge of MASM in my day job (hence my renewed interest in MASM and being a member of this site), is this just a fantasy.

[ecube]

I use ASM for commerical software because it's just fun and easy. While I don't use masm32 much anymore(switched to GoASM for various reasons) I will say 32bit/64bit ASM is applicable for any project on windows atleast. Lot of skiddie viri authors use it for malware, so it's recieved a bad reputation unfortunately, but its definitely much more powerful than C/C++ IMO.

[hutch--]

armiof1,

It amounts to whether you can find a use for the capacity, without directly writing applications in MASM you have the options of writing modules for C++ or writing DLLs that can be called from other languages that are DLL enabled. In C++ it will tend to be code types that is not done well in C++, roll your own SSE is a good option and anything else that you cannot target well enough in C++.

DLLs for other languages that can call them is also a good option in that you can write specialised code to perform dedicated tasks that may not be able to be done well in another language. Many of the earlier VB guys took this path so if you have a viable interface to use a DLL of this type it may allow you to add very fast native code to an application you are working on.

Just be careful of this much, some make the mistake of using very small pieces of ASM code where the call overhead exceeds the speed advantage of the code being called. The drift is to design large enough code components so this is not a factor.

[Rockoon]

Just be careful of this much, some make the mistake of using very small pieces of ASM code where the call overhead exceeds the speed advantage of the code being called. The drift is to design large enough code components so this is not a factor.

This cannot be stressed enough, and applies to all multi-language programming and not just the specific case of mixing ASM with an high level language.

Most language compilers (and interpreters!) are good enough these days that if your secondary-language library routine doesnt contain a processing loop in it, then its almost certainly less runtime-efficient to use it than it is to re-implement the routine in your primary language (regardless of how faster/better that secondary language is)

So today you normally only use a secondary language library when (A) the routine CANT be performed in the primary language, or (B) the routine does a LOT of work.

[armiof1]

Thank you all for your replies any further comments would be welcome. I've been programming now for about 10 years and it has always been my goal to properly use the tool set that i have, this goes a far way in my understanding.

[armiof1]

I'm using MASM with MS VS2010 with irvine libraries and project config. How does this stack up against products like GoASM and others.

[redskull]

if your secondary-language library routine doesnt contain a processing loop in it, then its almost certainly less runtime-efficient to use it than it is to re-implement the routine in your primary language (regardless of how faster/better that secondary language is)

I'm not sure i agree with this broad generalization... cache misses and page faults aside, the "call overhead'  is only a few cycles on either end.  As long as you aren't adding function calls where they don't need to be, why else do you claim this?

-r

[frktons]

I'm using MASM with MS VS2010 with irvine libraries and project config. How does this stack up against products like GoASM and others.

I'm quite a beginner myself in Assembly programming, so take my words with a little of salt,
like Romans said once upon a time.
As far as I know Irvine libraries are there for didactical purpose.
What you find in MASM32 / GoAsm packages is more for Real Assembly Programmers.
Use both with their respective object in your mind and you are on the right path.

Don't forget the most important thing: HAVE FUN with Assembly/whatever you use.  :P

[Rockoon]

I'm not sure i agree with this broad generalization... cache misses and page faults aside, the "call overhead'  is only a few cycles on either end.  As long as you aren't adding function calls where they don't need to be, why else do you claim this?

Exactly how much less efficient do you think one compiler is to another on small routines these days?

You are trivializing a couple cycles in call overhead, but hoping to gain a couple cycles in a small routine compiled with a different compiler.

Which is it? Are a couple cycles trivial, or not?

If they are trivial, then why mix languages at all?
If they are not trivial, then why not just save the call overhead? Thats a few cycles guaranteed, right?

[redskull]

If they are not trivial, then why not just save the call overhead?

Because, presumably, you would have the call overhead either way.  Substituting MyFunctionDoneInMASM() for MySameFunctionWrittenInC() would have the same stack frame/page faults/cache misses/etc, so regardless of the content of the function, writing in MASM would only help to make things speedier and smaller (if, of course, it's done correctly).

I agree that taking a section of "in line" C code, and pulling it out into a seperate ASM library function is a bad idea; you are adding in extra overhead which would offset the speed gains, like you said.

-r

[Rockoon]

Because, presumably, you would have the call overhead either way. 

Why are you making that presumption?

Even in cases where a call is not automatically inlined, a modern compiler actually looks at what the function does when making optimizations (in the simplest case, optimizes register usage across function boundaries, and in some compilers even across module boundaries) and still further, groups related functions together in the binary (so no, cache miss rates arent the same, but I didnt want to get into that..)

We are talking about small functions here, so inlining is done most of the time weather you want it to or not. The general rule for compiler inling is that if its small, it inlines it. Guaranteed savings vs starting out several cycles behind with a second language library.

[cork]

Because it is FUN!

[hutch--]

The type of thing I had in mind is somethig I have seen with inlined asm in VC, a short section of assembler code embedded into code produced by an optimising compiler that may use registers is entirely different ways. The 32 bit VC compilers will in fact get it right but at the cost of additional overhead. This in turn makes a mess of the compiler optimisation so you get a lose lose situation.

For very short sections of code the solution is to inline them as mentioned but you are at the mercy of the compiler to get this right so i would be inclined to check what the compiler output is. The drift here is pick what you want to write in assembler and know WHY you want to write it in assembler, select a large enough task so that that task is contained in the assembler code and you solve the problem of overhead ratio to code size and any code speed gain.

The use of compiler intrinsics are supposed to help here but I would also be inclined to benchmark them as I have heard a few bad things in terms of how badly compiler intrinsics perform.

[redskull]

Why are you making that presumption?

Becuase I was imagining they would have both been part of some sort of static/dynamic library, in which case the optimizer is a moot point.  I understand what you are saying now, thank you for clarifying.

-r

[xanatose]

Why not?

At least, a knowledge of assembly is a step toward a knowledge on how the computer works.