Message posted by Jay Sage to the INFO-IBM newsletter on the ARPA Network: I would like to make the PC-DOS/MS-DOS communities aware of a new assembler from SLR Systems in Butler, Pennsylvania. Although I follow to some degree developments in the 16-bit world, my own personal activity is in the 8-bit world, where I write extensively in assembly language. In the CP/M world the SLR assembly language tools are well known for both their quality and their speed. The speed difference is the most spectacular feature. The first time I used SLRMAC to assemble a ZCPR file, the assembly ended virtually simultaneously with the appearance of the signon message after the assembler loaded. I was sure then that I was dealing with another cheap assembler and would find a zero-length output file. To my surprise, the output file was there and ran perfectly. Since then I have just gotten used to the fact that Steve Russell can make his tools run at speeds others cannot even approach. And he does this while offering better convenience features in the programs as well. After this experience with SLR's products in the 8-bit domain, I was excited to hear that Steve was working on 16-bit versions of the tools. The first, an assembler called OPTASM, is now available. It takes a somewhat different approach from the CP/M products, which were unusual in doing their work with only one pass through the source file rather than the usual two. In fact OPTASM does the opposite. In order to optimize the more complex 16-bit object code, it makes a variable number of passes through the code so that it can, among other things, (1) resolve forward references without generating phase errors or resorting to insertion of NOP instructions and (2) optimize short and near jumps. The output code from OPTASM ranges from slightly shorter to dramatically shorter than the output from MASM. Despite making multiple passes (apparently up to 8!), efficient coding, I/O, and memory management by OPTASM allow it to run THREE TO FOUR TIMES FASTER than MASM. For test purposes I tried assembling two pieces of source code: MXTID.ASM from Ron Fowler's MEX-Plus telecommunications program and GR.ASM, some Lincoln-written assembly-code subroutines for efficient graphics output from a C program. Here are the results I obtained on my Compaq Deskpro 386. Times on a standard AT would, presumably, be twice as long for both assemblers. MASM OPTASM ---- ------ MXTID.ASM size 46,208 46,208 Assembly time with listing and crossreference output 14 s 3 s MXTID.OBJ size 5,969 3,981 GR.ASM size 69,283 69,283 Assembly time with listing and crossreference output 17 s 4 s GR.OBJ size 5,488 4,056 I will have to admit that I had a lingering doubt about these results (how could the code get that much shorter?), so I took the GR.OBJ module back to the author of the plotting program and had him link it into the C program. Worked perfectly! From glancing at the user manual, it appears that OPTASM offers the same kind of extremely useful convenience features that Steve put into the 8-bit tools. Here are just a few examples: 1. Symbols can be defined from the command line, as in OPTASM /Dtest=true MYPROG; This makes it easy to try different options without having to edit the source file each time. 2. OPTASM allows a large number of configuration options. The CONFIG utility makes it easy for the user to customize OPTASM to his own needs and tastes. 3. Options can be controlled (overriding the configured options) by directives in the source, from the command line, or from an environment variable OPTASM. Thus it is easy to make temporary changes to the default options. 4. The search path for INCLUDE files in the source can be specified from the command line. Many directories can be included in that path, limited only by the length of the command line. 5. OPTASM includes a built-in MAKE facility. This can be used for complete management of module dependencies or simply to perform assemblies of many files with a single loading of OPTASM. OPTASM even allocates buffers to keep source resident in memory to the maximum extent possible (for example, so that common include files or macro libraries do not have to be read in again from disk). I created a MAKE file to assemble the GR.ASM file above five times without listing or crossrefernce files. Total assembly time (all 5 assemblies) was only 5 seconds!!! With listing output the time was 15 seconds; the time was dominated by output to disk of the listing file. The cost of OPTASM is $195. For more information or to order a copy, call SLR Systems at 412-282-0864 or 800-833-3061 or write to them at SLR Systems 1622 N. Main Street Butler, PA 16001 I do not have any financial stake in SLR Systems. My wife's company, Sage Microsystems East, has been selling their 8-bit products and may now add the 16-bit ones, too. My comments above are motivated only by a desire to see excellence rewarded (so that it may continue). Note added later: I asked Steve Russell how it was possible for his OBJ files to be so much shorter than those produced by MASM. He replied that there are many references that MASM does not resolve, even though enough information is available to the assembler to perform the resolution. These items are left for the linker to resolve later. OPTASM does resolve these items, thereby eliminating a lot of unnecessary link items in the OBJ file. Thus OPTASM is doing even more work than MASM, and still it is so much faster!