Assemblers | Streaming SIMD | MASM 7 | Other Assemblers | The Future | About | Home

r_harvey

Assemblers

It used to be clear: run the latest version of MASM. Now the issue is confused not only by Inprise's (formerly Borland, then back to Borland again, then maybe Inprise, but it's hard to keep track) TASM, but by quickly evolving operating systems that are best supported with high-level programming languages. Starting with TASM 2.5, Borland split-off from the traditional MASM feature set, as did Microsoft in their version 6.00.

Selecting Your Assembler

If your requirements are light and you live in a 16-bit world, MASM 5.10B is probably enough. If you want all the new features and improved macros, but not the hardware overhead, try 6.00B. If you're the take-no-prisoners, gung-ho, full-time professional, settle for nothing but the latest, most advanced version. If you are using OS/2, you will probably want to add the latest version of TASM. Perhaps the greatest advantage of TASM is that you can often get it free, or at little cost, bundled with an Inprise compiler.

Here's a review of MASM versions.

MASM 4.00: Workmanlike, But Hard Work

This was the last version of MASM to ship with a 3-ring binder, before it slipped into the perfect-bound world. While it fixed bugs of earlier releases, 4.0 had few features and was strictly manual labor--not much fun. It was soooo '80s.

MASM 5.00: Ready to Run

There's no excuse for using an Assembler earlier than MASM 5.0--you might as well use DEBUG. Version 5.00 was much faster than 4.00, and miles ahead in bug fixes. The most significant improvement was simplified segment declarations like .MODEL and .CODE. But 5.00 didn't hang around long; it was quickly replaced...

MASM 5.10: Glimpse of Things to Come

Perhaps the greatest (though most overlooked) feature added to version 5.10 was the @@ local label; we no longer had to come up with a unique label for each conditional test. Note that Microsoft's @@ labels are not the same as TASM's. Microsoft included a text editor simply named M, which a few programmers loved, but many never figured it out at all. Version 5.10 also added OS/2 1.x support.

MASM 5.10B: The Standard

The best traditional MASM was 5.10B, which has been around since 1989. While reliable, fast and small, it didn't have high-level structures (.IF / .ENDIF), and a few 386 instructions were encoded a bit oddly. It was the last version that would run in less than 640K and fit on a low-density floppy disk. Version 5.10B was available on the first pre-release Microsoft Developer's Network CD-ROM (dig around, it's buried in there somewhere).

Microsoft’s early 32-bit development tools often included a descendent of the 5.10 series, usually called MASM386.EXE. The latest was labeled "5.NT.02" and responds as @Version=510. It's really primitive when compared to MASM 6.x.

MASM 6.00: The Next Generation

Here was the fresh-start-MASM, released in early 1992. Magazine advertisements touted 6.00 as being "23% less frustrating" (a quote from this author), and it really was. There were numerous improvements, like wild card support for file names (assemble more than one file at a time). Macros and structures changed to become more C-like, which broke lots of code that had been written for earlier versions. Command line syntax changed to C-style, though a translator intercepted the differences. Whenever possible, 6.00 tried to optimize code for us--it even converted lea to mov OFFSET whenever it could (a byte smaller and a clock faster), and often added forgotten segment overrides.

The most prominent addition was the .IF / .ENDIF high-level structure, which often made complex conditional tests as easy to write as C code. It was practical to do multi-thousand line modules with virtually no labels, plus enhanced readability--and readable means maintainable. It was a giant step beyond @@ labels; it often did-away with labels altogether. It's only fair: C has inline Assembly language, so MASM sprouted inline C.

Version 6.00 ran best on a 286 or better processor with a couple megabytes of memory. The 6.00 family was the fastest MASM for inexpensive computers. The assembler was more than three times as large as MASM 5.10B. A complete installation took about 4MB of disk space. Replete with loose ends; you’d be wise to look for the 6.00B release.

MASM 6.00A: Mystery MASM

This version was not released (didn't even escape). It fixed some macro and structure alignment problems, and made @FileName always return an upper case string (it had been returning whatever it found on the command line unless you used wild cards).

MASM 6.00B: Props-Up The New Standard

MASM 6.00B fixed a few minor bugs missed in 6.00A. It was a fast, versatile program. It was the last version that would run on any Intel-compatible processor. I believe that it was also the last version that officially supported OS/2. Microsoft sent copies of 6.00B free of charge to all registered owners without saying a word about it. (Really! In fact, I bought Windows 1.0, and later they sent me a free upgrade to 1.03; I haven't seen them do that sort recently, though.) If you're running an older machine but want the benefits of new-fangled Assemblers, this is your MASM.

MASM 6.10: Raises The Price of Admission

Besides the requisite bug fixes, the greatest addition to 6.10 was the requirement of at least an 80386 with four megabytes of memory. The /Sc switch added instruction timing to source code listings. The manual was rewritten and improved, though a few references to OS/2 were left in (OS who?).

MASM 6.10A: Manages Memory

MASM 6.10A began shipping at the end of 1992. The A-release updated the memory manager for compatibility with Microsoft's Visual C++ 1.0, and corrected some memory management problems. Complaints from fuddy-duddies forced Microsoft to revert to the old-style lea encoding. Unfortunately, 6.10A's wild card support no longer worked reliably if you had more than about 180 files.

While memory requirements zoomed, MASM 6.10A was actually slower than 6.00B. If you had limitless memory, you could assemble limitlessly-large files--though even version 5.10B could handle 300K files. In keeping with Visual C++ 1.0, which could slurp-up over 50MB of disk space, everything about MASM 6.10A grew--even the linker was over 300K.

Gotcha: Version 6.10A shipped with the final update of the Programmer's WorkBench (PWB) editor, which was like M with a user interface. If PWB's keyboard repeat rate goes crazy, remove the Fastfunc lines from TOOLS.INI, or try the Microsoft C/C++ 7.00 version (early 1992). The Visual WorkBench (VWB), a Microsoft Windows editor in Visual C++ 1.0 (early 1993), replaced PWB. As of this writing (March 2002), VWB and its make files are indifferent, if not hostile, to MASM. Now, Microsoft's Visual Studio allows you to add any files to projects, even MASM, if you manually set compile switches, and you have to set those switches again for each additional file added to projects. If you use a lot of Assembly files in a C/C++ project, expect a lot of fussing with dialog boxes to get it all working together.

High-Level Directive Errors

Gotcha: If you use complex, multi-line high-level directives in very large files, you may experience "Line too long" errors that have nothing to do with the line they reference. Shorten lines, even comment lines, within the high-level structures until the errors go away. Running MASM from the DOS command line instead of Microsoft Windows fixes many mysterious problems. The real fix will appear seven years later.

MASM 6.11: Windows NT and Pentium

Introduced in November of 1993, this version fixed a few bugs (like the *.ASM problem) and raised the list price to $249. It was a full-blooded 32-bit Windows program that also ran under MS-DOS. Besides Windows NT, it supported the Pentium instruction set, but not MMX™ multimedia extensions. Utilities furnished with 6.11 were unchanged from 6.10's. Performance, a sales feature of 6.00, was a non-issue; the feeling was that if you had to ask, you couldn't afford it.

MASM 6.11C, 6.11D: Windows 95 Support

The 6.11C patch (er, upgrade) slipped-out in 1994. It added Windows 95 VxD support, but it was still 6.11 underneath. MASM's tendency to add extra records to object files was corrected, which tamed object files to TASM and WASM sizes. Borland's TASM was noticeably faster with large files.

In early 1995, version 6.11D, of course, fixed 6.11C's bugs. The 6.11 to 6.11D patch is described in Q138983, and may still be available at http://www.microsoft.com/kb/articles/q138/9/83.htm; it was at ftp://ftp.microsoft.com/Softlib/mslfiles/ML611D.EXE, until they shut it down.

MASM 6.12, 6.13: The Giant Awakens

Don't tell Microsoft, but the 6.12 patch, released in August 1997, was a real upgrade! With .686, .686P, and .MMX directives, we were up-to-date. Version 6.12 also improved structure alignment inconsistencies and, of course, a few smaller bugs.

There were still "Line too long" errors with large, complex conditional tests. There was still no help file describing late-model instructions and directives. The 6.12 patch had grown to 671K, but the Assembler was actually smaller than 6.11. Phar Lap's DOS extender, introduced in 6.11, was no longer required (which is likely why ML.EXE got smaller).

Released on December 5, 1997, version 6.13 fixed a few small bugs and added the .K3D directive (and related AMD 3D processor instructions). While the 6.12 upgrade was 671KB, the 6.13 patch was a whopping 815KB! And again, ML.EXE was smaller than the previous release. You used to be able to download the patch at ftp://ftp.microsoft.com/Softlib/mslfiles/ml613.exe.

Streaming SIMD (née KNI)

Wow, it happened again: another MASM upgrade at no cost at all! It sometimes pays to use a powerful language that the manufacturer doesn't recognize as a profit center.

Formerly known as Katmai New Instructions (KNI), Streaming SIMD (Single Instruction, Multiple Data) extends the venerable x86 instruction set much like MMX, only more so. Pentium III and later processors have it, and late-model C/C++ compilers support it; in February of 1999, Intel added Streaming SIMD to MASM 6.12 as macros. These macros also include MMX support.

Read the Intel license agreement, which will then take you to the download page for iaxmm.exe. And while you're at http://developer.intel.com, take a look around; this company cares about software developers.

Intel may offer just MMX macros free of charge. Look for a reference to IAMMX.INC at Intel.

MASM 6.14:   The Complete Assembler  

Here we go again, a real upgrade for the price of a download. Released April 14, 1999, MASM 6.14.8444 rounded-out the 6.x feature list:

• .686 and .686P directives. Intel Pentium Pro instructions, originally introduced in MASM 6.13.
• .XMM directive. Streaming SIMD instructions are now built-in, so we don't need Intel's include file (thanks, anyway--it's still nice to have because it shows how to use macros to modify instructions).
• New OWORD (Octel Word) keyword. This 16-byte data type is required for SIMD instructions, and should be useful for ad hoc structures. The OWORD directive replaces the MMWORD keyword used in Intel's macros.
• The line-too-long bug is dead. The reason the problem was so hard to correct, I believe, was that it had nothing to do with long lines, but with the IF directive (I wish I'd mentioned that in 1992 when I reported the bug). Basically, instead of just saying "IF Something", always say "IF Something NE 0", and the error messages will go away.

This link used to take you to the upgrade: ftp://ftp.microsoft.com/Softlib/mslfiles/ml614.exe.

During the transition to 6.14, try something like this:

IF @Version LT 614
 .586
 INCLUDE IAXMM.INC
  OWORD TYPEDEF QWORD
ELSE
 .686
 .XMM
 MMWORD TYPEDEF OWORD
ENDIF

All is still not quite perfect. If you use complex macro functions (with the EXITM keyword) within other macros, or complex IF tests, expect an assortment of strange error messages. You can often solve these problems by separating macros with blank lines, but line length restrictions still limit flexibility. Apparently, few use MASM 6.14 for very complex code, because sometimes it just doesn't want to work.

MASM 6.15:   New Documentation, new Instructions

In April of 2000, the Visual C++ 6.0 Processor Pack Beta was released, containing a lot of stuff we don't care about, but also some documentation, updated for the first time in about eight years, and ML.EXE release 6.15.8803 (but no linker).

The /omf switch was added because it now defaults to the COFF object file format instead of the OMF format. This change will break some make files.

There is a warning not to use the tools in commerical programs, so you may want to stick with 6.14, and get this version just for the documentation (or for your collection). http://msdn.microsoft.com/vstudio/downloads/ppack/default.asp

You may want to get 6.15 if you don't have a reasonably current version, and you would like to get it in a single, 1.1MB download. Besides, it's free.

There is absolutely no pretense left. MASM is not a retail product; it's a little less important to Microsoft than, say, their linker -- just another tool included on the Visual Studio CD-ROM.

MASMpalooza Postponed

February 15, 2002: Microsoft Visual Studio.net Professional presented an exciting new MASM model number. And, um, that's about it.

• The 7.00.9466 build number was shared by most programs in the package, so it unfortunately meant very little. The @Version directive still returned 615.
• VS_VERSION_INFO right-click properties.
• Buffer/stack overflow checking and spooky warning messages. Protecting against these sorts of things is all the rage--even on single-user command line utilities.
• The ML.ERR error message file is gone, replaced by Unicode text within the program file.
• You may need to license Visual Studio in order to legally use MASM, even if you own a license for MASM 6.x. That's $1200 for an Assembler and linker.

While .NET intermediate code is at the heart of Visual Studio, don't look for it in MASM 7.00.9466.

Microsoft® Visual Studio .NET 2003, released in the second quarter of 2003, included (taa-daa) MASM version 7.10.3077, again, the build number shared with the rest of that huge package. This time, @Version returned 710. Note that the standard runtime library still used CRUNTIME.H, which was full of 32-bit assumptions about code, so the product was still not ready for 64-bit processors. While most of MSVC2003 required the latest operating system, MASM still ran in Windows 98. There was a new /safeseh switch, which is documented as "Assert all exception handlers are declared."

Other Assemblers

Fow all we complain about quirks and proprietary conventions in MASM, keep in mind that there is no standard, and every time somebody attempts to correct MASM's failings, we see that their conventions and standards may be no better than MASM's--just different. Several Assemblers are available for part-time programmers.

• CHASM (the Cheap Assembler) is available as shareware.
• For students on a truly limited budget, try DOS' nearly-free DEBUG.EXE; it's dreadfully limited, but starting with DEBUG will give you a new respect for the power of a modern Assembler.
• GCC is a free, cross-platform compiler package that includes the AS Assembler. This Assembler is often thought of as a back-end for compilers, so advanced language syntax, and even documentation, are afterthoughts.
• NASM (the Netwide/National Assembler from England or Russia) looks like it works, but while furthering the goal of eliminating MASM's quirks, they have introduced even more of their own. May be at http://nasm.sourceforge.net/ or less likely at http://nasm.2y.net, and supported by that glimmer of hope that one day we'll return to Assembly language for big programs.
• OPTASM is fast but non-standard, and in need of an upgrade.
• Watcom's WASM, furnished free with their C/C++ compiler, is modern (it even has Pentium support), but it's noticeably slower than MASM and it does not support MASM 6.x's high-level conditional tests. WASM includes virtually no documentation, not even a list of directives.
• There is new hope. The NASM Assembler has been reborn as The YASM Modular Assembler Project. It runs on Linux and Windows, it supports 64-bit microprocessors (with the blessings of AMD), and it's free. Look for it at the tortall.net. As of this writing, it's not completely compatible with MASM, but that should be coming.

I personally believe it's crazy to put time into using an anemic Assembler. MASM and TASM aren't cheap (well, when they were retail products they weren't), but prorated over the hours of grief that would otherwise be inflicted on us by lesser tools, they're bargains. If you follow the links on this page, you can get YASM or MASM free of charge--there's no reason to use anything less.

The Future

A benefit of the C/C++ language is portability. Compilers translate the same C/C++ source code into Assembly language appropriate for every popular processor, hiding the ugly differences. MASM 6.x brought a degree of processor independence with high-level structures and improved macros. Expect to see Assembly language become even more C-like. The most important improvement will likely be true source code portability--the same high-level Assembler source code will be supported by several processors, using built-in equates and macros to smooth the translations.

Most of the world has moved to higher-level languages; with short schedules, million-line projects, and fast processors, there's little economic incentive to use MASM. There's little public interest in the product, so I wouldn't expect headlines if it were to die.

It's been over a decade since a major MASM upgrade; those who haven't moved to C++ are wishing for more. I can't think of any other commercial application that hasn't had a major upgrade since 1992. MASM is such a rich, robust product that you could add just about anything by writing macros, but it would be nice to make it more C-like, with /* ... */ multi-line comments, "0x" number prefixes, #define, a few more high-level structures, packaged functions, and object file comment records.

It's clear: if we want to use MASM, and we need multiple-platform support for the latest features (improved documentation, good 32-bit Windows include files, IDE integration...), we're on our own. But if we want to use Assembly language, and we can compromise, today's C++ compilers do inline Assembly. With those tools, we can slip-into Assembly whenever we want to, and have the advantage of C/C++ and giant runtime libraries to minimize development effort.

If, like me, you are developing library components, you're still concerned about code size and independence from runtime libraries. We'll still be using MASM, even if it's still 6.15, for another generation.

New Processors

Now in sight are Intel Itanium™ and AMD Opteron™ (the K8, code named Sledgehammer [8-way multiple-processor] or Clawhammer [single or dual-processor] known by its friends as Hammer and renamed to Opteron on 4/24/02, then the consumer version renamed to Athlon 64 on 11/19/02), 64-bit processors (which finally saw limited-distribution in May, 2003). Most will use C++ to write for the Itanium, because it's an instruction set only a compiler would love. Complexity, value, heat and size, make the Itanium a long-shot bet for desktop computers. (Note to Intel: The engineers for whom Hewlett-Packard used to be called "The engineering company," have retired.)

The Opteron/Hammer/Athlon 64 extends the x86 architecture with more and bigger registers, mostly accessed by adding new prefix bytes to existing instructions. Intel has a Hammer-compatible processor, code named "Yamhill" (it's a matter of time until it's called "Yammer"). In early 2003, Transmeta licensed AMD's x86-64 for use in their small, low-power processors. x86-64 is a processor architecture that MASM would love -- and we could use macros with our beloved 'ol 6.x to do them. We've seen incremental changes for the last twenty years; for better or worse, the Hammer/Yamhill platform is likely to slip right in, to continue the venerable/antique Intel x86 architecture for yet another generation.

Waking MASM

The horrid GCC Assembler supports the latest processor instructions, or at least we can add instructions as macros. A little preprocessor program could extend its syntax and add processor-independence, while supporting multiple platforms, and lessening our dependence on MASM. Randall Hyde is maintaining a High-Level Assembly pre-processor project.

Assembly language is hardly portable or reusable; there's no reason, now that the x86 looks like it will be around for another decade, running multiple operating systems, to depend on the proprietary nature of MASM. It's time to begin migrating new code to YASM. With YASM, we'll at least be able to reuse code for other operating systems, if not yet other microprocessors.

Much of this information evolved from my Assembly language book.

Top | Notice | Home | | © Copyright 2007 R. E. Harvey, All rights reserved.