Developers Enjoy the "ALP"s (Assembly Language Processor)

by Scott Gruber and Steve Turner

Device driver and application developers now have an IBM tool to assemble code. IBM has introduced the Assembly Language Processor (ALP), a new programming tool incorporated into the Developer's Toolkit for OS/2 Warp. ALP is an Intel macro assembler designed to fulfil all of your OS/2 assembly language requirements. A world-class operating system such as OS/2 Warp deserves a full complement of powerful programming tools, and a full-function assembler is a key addition to the developer's package. We hope that ALP is a welcome addition to your toolset.

The Need for ALP
Along with the fact that OS/2, as a world-class operating system, is complemented by a full array of general-purpose programming tools, other factors driving the development of ALP are the requirements of device driver programmers and the content of the IBM products designed to foster such important development work, including the following: It is our intention to give ALP the function it needs to build all of the device drivers that ship on the DDK as soon as possible. Towards this end, it is expected that support in ALP favors the implementing of those features that are required to build the device driver source code shipped on the DDK, rather than some of the more obscure or seldom-used MASM features.
 * The Developer Connection Device Driver Kit for OS/2 (known as the DDK) is 'chock full' of source code for OS/2 device drivers, many of which contain 80x86 assembler code written for use with various versions of the Microsoft Assembler (MASM). Although the DDK ships with a version of MASM 5.1 that can be used to build many of the drivers, this assembler is old (circa 1989), has no accompanying documentation, and is unsupported. While some developers find this situation tolerable, others (including the developers of ALP) do not.
 * Several of the device drivers included on the DDK require the use of Microsoft MASM 6.0, which is not included on the DDK and is no longer available. Attempts to use later versions of MASM may or may not prove to be a fruitful experience, because Microsoft no longer produces an OS/2-supported version of MASM. Clearly, for IBM and its customers this situation could be improved, and that is exactly what we are setting out to do by delivering ALP.

We expected that users of ALP would be just as inclined to use it on existing source code as they would for new development. Therefore, it was clear from the outset that the primary goal for ALP was that it should be as compatible with MASM as possible, at least from a source language point of view (ALP is not command-line compatible with MASM, a topic discussed later in this article). However, as those who are intimately familiar with MASM's behaviors may well know, many peculiarities and ambiguities exist in the language (primarily in versions 5.1 and earlier) that make it difficult to build a fully compatible assembler. As tempting as it was throughout the various stages of development to simply declare certain MASM 5.1 source constructs 'illegal' (this approach is taken in many cases by MASM 6.0), we chose instead to respect the vast body of existing pre-MASM 6.0 source code, striving wherever possible to accept it and to generate code identical to that of MASM. It would serve no useful purpose in the real world for ALP to accept only a clean and elegant language syntax; many new (and far more elegant) programming languages have come and gone for the simple reason that they were incompatible with existing bodies of source code.

This is not to say that ALP will accept all MASM 5.1 source code without complaint; you may find that ALP issues warning messages for code where MASM 5.1 is silent. In general, you will find ALP to be much more verbose than MASM 5.1 and, in some cases, even more informational than MASM 6.0. Because ALP is walking the road toward MASM 6.0 compatibility, many constructs that cause ALP to issue a warning message are considered error conditions under MASM 6.0 emulation. And while some warnings simply reflect the fact that ALP has stricter type checking (as with MASM 6.0), be aware that warnings may also be ALP's way of tolerating error conditions in the name of backward compatibility with MASM 5.1, and would cause actual errors should you attempt to assemble with MASM 6.0, or with ALP under MASM 6.0 emulation.

The User Interface for ALP
As noted before, ALP is not command-line compatible with MASM, and this decision was made very early in the design stage. Times have changed since the original MASM command line syntax was designed in 1981, and ALP's functional requirements would stretch way beyond what was possible with this type of interface. Even MASM itself (beginning with version 6.0) has moved away from the old 'positional parameter' command line, and (like ALP) uses a more free-form syntax, patterned after a common style popularized on UNIX systems, known as the 'compile and link' convention. While ALP does not support the ability to directly incorporate a 'link step' into its processing, the capability may be added later, and we feel that it's important to understand the convention because the failure to follow certain rules could cause problems later on.

A compiler or assembler (or more generically, a 'translator') using the compile and link syntax accepts multiple file names on the command line and treats them all as input parameters, while option (or 'switch') parameters beginning with a special character describe how the translator should alter its default behavior. As its name implies, the compile and link translator does more than just compile source files - in fact, many such translators are simply 'driver' programs that invoke other tools under the covers to perform more specific tasks. The driver program determines what to do with a file based upon its 'type,' and the filetype is determined according to a set of naming conventions. While the naming conventions tend to vary from system to system, the typical set of input filetypes are as follows: Unless the translator provides an option for tagging a specific file as having a certain type (and many do not), the filetype is determined by examining the file extension or suffix. If the file suffix is not recognized, the standard behavior for the translator is to treat the file as source code written in the native translator language (after all, that is the primary purpose of the translator).
 * Source files written in the native language of the translator
 * For high-level language compilers, source files for the assembler language of the target machine (the compiler processes the file by invoking the assembler 'under the covers')
 * Source files that have been 'pre-processed' by a macro processor
 * Partially compiled intermediate files created by the 'front end' of the translator, for consumption by the translator 'back end'
 * Object files created by any language translator, for consumption by the linker during the link step
 * Object file libraries, for consumption by the linker during the link step
 * Module definition files, for consumption by the linker during the link step

The point to be made here with respect to ALP is that because it does not yet do any file name interpretation for the purposes of supporting a link step, an 'intermediate' link step, or a separate preprocessing phase, any file name regardless of its suffix will be treated as an assembler source file. Should ALP ever support the compile and link convention, you may run into trouble if you have chosen non-standard names for your source files. Because of its reliance on file naming conventions, the compile and link convention is not without its problems, but it works very well when you play by the rules.

Now let's talk about the philosophy behind the syntax of ALP's command line options. We expected from the outset that there would be a lot of them, and there are... over 100! And as ALP evolves, we expect the number to increase. With the potential to support such a large number of command line options, care was needed in the selection of the option syntax. We considered several factors: There is also the issue of case-sensitivity in option names. While this technique can sometimes be used to great advantage (such as attaching a particular meaning to an option, or to avoid running out of alphabetic characters while attempting to keep option names terse), none of these techniques seemed necessary in order for ALP to accomplish its goals. Case is therefore not significant in any of the ALP options. -Fodebug\test.obj -Fo debug\test.obj -Fo:debug\test.obj While the first example is a popular notation, it was rejected for ALP because of its ambiguity. Where does the option name end and its argument begin? We also wanted the flexibility to add options in the future (for example, -Fod), without breaking examples such as this one.
 * Naming - Obviously, option names required the use of more than a single alphabetic character, but resorting to the use of full-length words or even phrases (/NOVERBOSEOPTIONNAMES indeed!) seemed excessive. Verbosity has its place, but people seem to prefer tersely named options, even when there is no apparent benefit to using them (how many people spell out /NoIgnoreCase in their makefiles when they can use /NOI instead?). Terse naming seemed the best choice but, at the same time, defining a new option should involve more than just pulling the next most-likely alphabetic character out of a hat. We chose the time-tested 'acronym' approach, where each letter of an option name is the first letter of a word in a logical phrase. Phrases were designed to read like a cascading pull-down menu in a Presentation Manager (PM) window, where the last letter in an option stands for the final disambiguating word in a phrase.
 * Introductory character - While the contentious debate over whether to use a 'dash versus slash' before an option may never end, for ALP the choice was easy: don't use the slash character. Use of both the forward and backward slashes in file names is becoming more and more popular, and OS/2 allows the use of either in its underlying APIs. We also decided to avoid using forward slashes, thus disallowing the possibility of colliding with the AIX operating system, where use of the forward slash within file names is required. Slashes, therefore, cannot be used to introduce options, and we saw no reason to incorporate operating system-dependent code into ALP to handle both situations.
 * Delimiters - This issue deals with options that take arguments (such as file names), and how the option name should be separated from its arguments, if at all. For example, if you have an option called -Fo that is used to set the name of the object file using the argument debug\test.obj, which syntax below is appropriate?

We could have required that an option be separated from its arguments by a space, but that is in conflict with another interpretation of -Fo, in that options standing alone (that is, surrounded by white space) are typically taken as 'switches' and are representative of true or false Boolean values. In ALP, -Fo means 'do not create an object file' (+Fo is the opposite interpretation), and in the second example above, the debug\test.obj parameter would then be taken as a standalone input file name - not what we wanted either.

The answer lies in the syntax of the third example. Options that take arguments (called 'parameterized' options) must be immediately followed by a colon or an equals sign (=). This lets us have both a 'switched' and 'parameterized' interpretation for a single option name, removing any ambiguity, and gives us the freedom to add options in the future without breaking existing makefiles.

We hope this lengthy discussion answers the inevitable question, 'Why doesn't ALP have a MASM-compatible command line?' And we hope the short answer is apparent: 'It would have severely limited ALP's capabilities.'

Customer Satisfaction
ALP is constantly evolving to meet your developing needs and we believe the table (see Figure 1) will simplify the process of updating your makefiles. However, would a MASM-compatible 'driver' program that invokes ALP transparently be helpful? If you have an opinion on this matter or additional concerns, please contact us. To simplify your transition from MASM 5.1 to ALP, the table shows MASM 5.1 command line options and correlates them with the ALP options required to obtain similar behavior.

We hope this information helps familiarize you with the ALP assembler. And we hope ALP will meet all of your assembly language development needs. ''Figure 1. MASM 5.1 to ALP Command Line Options''