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!
