Mr Emmanuel Roche France
Member
Hello from France!
I am Mr. Emmanuel Roche,
Chemin de Boisrond
17430 Tonnay-Charente
FRANCE
I have participated to the comp.os.cpmNewsgroup for 10 years.
But I have been unable to find one "SAL-80" package from the "ProTools" company of "Steve Newberry". (Details below.)
If anybody out there knows about it...
Yours Sincerely,
Mr. Emmanuel Roche, France
- "Software Review: SAL/80"
Jim Kronman
DDJ, Vol.9, No.2, February 1984, p.77
Company: Protools, 24225 Summerhill Avenue, Los Altos, CA 94022
System : CP/M 2.2
Price : $59.95
SAL/80 is a software package that adds standard "structured"
control operators to the Intel 8080/85 assembly language and can
also, at the user's option, produce some code optimized with
Zilog Z-80 instructions. SAL/80 is designed to be used with the
Digital Research, Inc. MAC and RMAC macroassemblers. In addition
to the control structures, built-in library functions are
provided. Newberry Microsystems refers to SAL/80 as a
"language", but it is actually a language enhancement, used in
the same way as RATFOR is used with FORTRAN.
Structured programming is a lot like religion: either you
believe or you don't. I will not try to sell you on the concept
in this review, but if you believe in minimal use of GOTO, you
will appreciate SAL/80.
This review applies to version 2.1 of SAL/80 running under CP/M
2.2. The author of SAL/80 is Steve Newbery, and it is marketed
by Steve's company: Protools. The current price for SAL/80
(including a 200-plus page manual) is $59.95. The price includes
a free update to version 3.0. SAL/86 is, or will be, available
for Intel 16-bit processors (8086 and 8088).
What It Is
----------
SAL/80 provides these familiar control structures:
DO-ENDDO
FOR-UNTIL-STEP-ENDFOR
IF-ENDIF-ELSE-ENDELSE
LOOP-UNTIL-ENDLOOP
REPEAT-ENDREPEAT
WHILE-ENDWHILE
SELECT-CASE..CASE-ENDSELECT
EXIT and GOTO are also provided.
The control structures are supported by a wide range of boolean
expressions of the form X,rel,Y where X and Y (with a few
limitations) can be any register, register pair, memory
reference, or constant. The "rel" in these expressions can be
either the usual comparisons (such as greater than, equal to,
etc.) or one of several CPU status flag conditions (e.g., Carry
set, minus, etc.) that requires no argument (X and Y are null,
and the PSW is implied). For convenience, IFCALL and IFGOTO are
provided to allow a conditional call and goto consistent with
the other operations.
The SAL/80 built-in functions include register save and restore
functions. Most of the built-ins are designed to facilitate
program-to-user interface via the console.
Several SAL/80 library files are also provided on the
distribution disk. They include block move, string search, and
comparison procedures, and multiply and divide.
SAL/80 is designed to work in an Intel 8080/85 environment, but
optionally will generate Zilog Z-80 code for relative jumps, and
the "DJNZ" instruction in loops.
Using SAL/80
------------
SAL/80 version 2.1 is implemented as a set of macros that must
be invoked as "MACLIB SAL/80" at the beginning of your assembly
language program. You include the SAL/80 instructions as part of
your assembly language program code. When it is time to assemble
the code, SAL80.LIB and any of the provided LIB files you have
referenced must be on the same disk as your source code. You run
MAC or RMAC, and the program is assembled.
SAL/80 Documentation
--------------------
The SAL/80 manual has four chapters and three appendices. The
chapters are indexed. The compiler source code has its own
index, this source listing plus its index taking 72 pages.
Chapter One, "Overview of Essential", explains the syntax,
content, and use of SAL/80 in 45 pages. A generalized example of
each construct or function is given in schematic form. For
example:
LOOP?
[<loop body>]
UNTIL? <bool expr>
[<more loop body>]
ENDLOOP?
This example points out one feature I have so far not mentioned:
all SAL/80 instructions are terminated with "?".
Chapter Two, "Tutorial: Maintainable Programs", is a 31-page
essay on software design using a real-life (if somewhat
contrived) example. All of the steps from design concept to
finished product are covered.
Chapter Three, "Tutorial Worked Example: MEMTEST", is the
complete source code listing of the example used in the previous
chapter. It includes its own index (for the program) and
occupies 50 pages. MEMTEST is a memory test program.
Chapter Four is called "General Observations" and talks about
using MAC and RMAC and the application of some of the features
of SAL/80.
Appendix A of the manual is the complete SAL/80 source code. The
distribution disk file SAL/80.LIB, however, does not look like
the source code. It has been, in Newberry's words, "Krunched" in
order to save disk and TPA space. Appendix B lists the source
code for the error trapping portion of SAL/80.LIB. Appendix C is
a summary of SAL/80 commands.
Performance
-----------
SAL/80 does what it claims to do. It runs, has a few bugs, but
is well supported by the author. I can only fault it for being
SLOW. On the other hand, RATFOR is no burner with FORTRAN,
either. Steve Newberry has recognized the speed problem with his
MAC.LIB approach, and is currently preparing a preprocessor
version of SAL/80 written in the C language. Purchasers of
version 2.1 will receive version 3.0 free when it is available.
The code produced by SAL/80 is reasonably close to being as
compact as the code you would produce if you coded in "pure"
assembler. For example, a small menu-drive program I wrote with
SAL/80 to send set-up commands to a printer was 1.4K bytes, and
a similar program for another printer from "pure" assembly code
was just under 1.0K bytes. Although some minor inefficiencies
have been created in exchange for generality, SAL/80 generates
more compact code than any high-level language compiler I have
used. I have not noticed any case where execution speed has
suffered. My experience with SAL/80 has been with business
applications; if you are coding a real-time control application,
however, you might encounter critical areas where fine tuning is
required. The same would be true if you were coding in "pure"
assembler.
Most of the constructs work as you would intuitively expect them
to from experience with higher-level structured language such as
Pascal or C. I found the SELECT construct, however, more limited
than its CASE counterpart in Pascal. SELECT-CASE..CASE-ENDSELECT
is actually more like FORTRAN's computed GOTO statement. The
first choice (CASE) MUST be 0, then 1, and so on. This is stated
in the documentation, but I had a hard time understanding what
it meant, probably because I wanted it to work like Pascal!
Another enhancement that would have been nice is if the X,rel,Y
operations (RELational operators) would accept the syntax "A" to
represent 41 hex and so on (like CHR(A) in Pascal, or the
literals in standard Intel assembler code).
I have not succeeded in getting the example program, MEMTEST, to
run on my computer. I must admit that I have not given much
priority to this, and therefore have not spent much time trying.
I have had substantial difficulty, however, getting any of my
own applications written with SAL/80 running.
The only other operational criticism I can make is that the
error messages are not always sufficiently clear to allow
debugging without resorting to examination of a PRN file with
the macro expansion included. This might not seem like a big
deal until the first time you look at such a file from SAL/80.
Some of those innocent-looking constructs and built-in can
generate gobs of code!
I have found no problems in the built-in and library functions
supplied with SAL/80, but in some respects they are a
reinvention of the wheel. My personal preference is for a set of
routines like Richard Conn's SYSLIB functions, which are in the
public domain. I find some of the SAL/80 procedure names (such
as "compare$strings:") to be longer than necessary. I type a
lot, but that does not mean I like to do it.
Evaluation of the Documentation
-------------------------------
When I originally ordered SAL/80, I was motivated to do so by
the documentation more than by the program itself. I thought it
would be an economical way to learn more about MAC and RMAC, and
to pick up a few new programming tricks. My aims were
accomplished, but I feel the documentation
would be improved in some areas.
The manual is better than many. It IS thoroughly indexed. In
fact, I wish more software publishers would be as thorough as
Steve Newberry has been in indexing his manual.
The greatest improvement in the manual would be to provide a
real, concrete, illustrative example with the definition of each
command. This would go a long way toward making SAL/80
immediately useful. I found that I had to try each construct a
few ways until I got clear in my mind what each function could
and could not do. Some real examples accompanying each function
description would have saved me hours of time.
Another welcome addition would be a simple, columnar quick-
reference list of all reserved words, and a compact quick-
reference guide for the commands. I would like to see the
commands, built-ins, and so on defined one to a page in the
manual for ease of reference.
Support
-------
I have nothing but praise for Newberry's support of his product.
I am somewhat reluctant to print constructive criticism about
SAL/80 because he has been so responsive to past inputs (from me
and others). I am reasonably sure that most of my criticisms
will have been answered by changes in the documentation by the
time you read this review. His initial release of version 2.1
had some bugs in it, but it was released at a discount. In
addition, anyone who reports a real bug receives a free update
to version 3.1 for the effort (version 3.0 is already included
when you buy 2.1). Corrections fixing the identified bugs have
been mailed to users in a timely manner.
Conclusions
-----------
If you must do assembly language programming, and want to
generate more readable and maintainable code, then you should
investigate Protools' SAL/80. It has the potential to give you
some of the advantages of the higher-level languages, while
retaining the control and efficiency of machine-level
programming.
- "Letters to the Editor: Fussing over SAL/80"
DDJ, Vol.9, No.4, April 1984, p.9
Dear Doctor:
This is to express my heartfelt appreciation for the very
thorough and objective review of our SAL/80 package in the
February issue by Jim Kronman. I am embarrassed to take ANY
exceptions to what he has written, BUT...
One thing I do feel obliged to remark on Jim's example of code-
density compares two printer drivers, one in naked assembler and
one in SAL/80. The SAL/80 driver is 400 bytes larger than the
naked assembler, which might seem to imply that SAL/80 has a
run-time package of 400 bytes. This is NOT the case. SAL/80 has
NO run-time package (and NO royalties for commercial
distribution of code generated using SAL/80).
But then, it might seem to imply that the code emitted by SAL/80
is 40% larger than that obtained by coding in naked assembler,
which is even WORSE! I haven't seen the two drivers in question,
but I am quite certain that there are differences between the
two which would account for all except a maximum of about 100
bytes plus perhaps 5% of the remaining difference.
There are several UTILITIES in the package which, all taken
together, might contribute perhaps to 100 bytes of excess code,
because of their generality. And the test/branch code can
typically be squeezed by about 5% in the average case. The 5%
results from the fact that jumps to jumps do occur when a
forward branch is emitted in the last group of a loop-body
(hence, three bytes may be squeezable), and that the HL register
is saved in certain memory-reference comparisons (which gives
two possibly squeezable bytes if HL was inactive at the time).
The reason I am making such a fuss about this is that SAL/80 is
the only structured assembly package I know of that actually
does OPTIMIZE the test/branch code! There is a huge decision-
tree in the compiler which does all the tricks dear to the
hearts of assembly-language programmers to avoid writing two
conditional jumps to implement LE ("<=") and GT (">")
comparisons. On a branch-by-branch basis, SAL/80 emits the
tightest code possible if the double-registers are to be
preserved over the comparison.
Cordially,
Steve Newberry
Protools
24225 Summerhill Avenue
Los Altos, CA 94022
- "SAL/80 from Protools"
Mike Barber
"Microsystems", Vol.5, No.3, March 1984, p.116
On the one hand, structured languages often produce code that
isn't too efficient in terms of space and time. On the other
hand, assembly languages can be a haven for unstructured,
unreadable, but efficient code. If you wanted to provide methods
for writing structured assembly code and spent enough time with
the macro capabilities of your favorite assembler, you might
produce something like SAL/80. Of course, with SAL/80, you can
just start writing the code for your program.
The macro library
-----------------
SAL/80 version 2.1 is a macro library containing a variety of
useful macros, including macros for selection (if-else, case),
repetition (while, repeat, loop, do, for-until), flow-of-control
(call, conditional calls), and various helpful utilities. It is
intended for use with the MAC or RMAC assemblers from Digital
Research, and requires a 64K 8080/Z-80 system running CP/M 2.2.
The SAL/80 macro libraries contain a good collection of assembly
language macros. The manual does not provide the easiest
introduction to their use but, with the original source listing
provided in the manual and some experimentation, they are
usable.
The utility macros in the SAL/80 libraries are, in part, adapted
from those in the MAC library on Volume 24 of the CP/M User's
Group, and from other sources. They provide several varieties of
console interaction, including console status, character or
buffer input/output, binary converted to ASCII hex for output,
and ASCII hex input converted to binary. Binary/hex and
binary/decimal conversions are also included.
Utility macros for register/stack and register/memory
manipulations, double-register subtracts and compares, and 16x8-
bit multiply and divide routines act as extensions to the
assembly language. Block moves, string search within a block,
lower-to-upper case conversion, and string comparison macros
complete the set of utilities.
Although the utility macros are a kind of bonus in SAL/80, since
the package focuses on structured assembly language programming,
I would have liked a more complete set of utility macros,
including interfacing to all the CP/M functions and a fuller set
of string manipulations. The set of utility macros that is
provided does not seem to have been as carefully designed and
thought out as the set of structured language macros. For
example, the lack of file-I/O macros forces you to write new
code every time, or to write your own macros, or to use macros
from yet another source.
Documentation
-------------
The SAL/80 manual is (mostly) a hacker's explanation of an
approach to programming and an example of that approach. The
example uses the SAL/80 macros and assembly language. However,
the description focuses on the approach, not the macros. I
enjoyed this description as a working example of an approach to
programming by one hacker -- something that is often described
abstractly, but rarely with the depth of concrete detail given
here.
The manual includes a section describing the macros. This
section is modeled on a syntactic description of a programming
language that makes it difficult to see the macros for the
syntax. I would like to see this section moved to an appendix
(for those who like formal syntax descriptions). It could be
replaced with a simple list or index of the macros, followed by
single-page descriptions of the macros, like those often used in
language reference manuals. Each page could describe a macro
structure and its parameters. This type of description is
present, but is difficult to see in the current section.
Why use SAL/80?
---------------
Programmer's tools like SAL/80 are measured by a simple
question, "Why should I use it?"
SAL/80 can help assembly language programmers by providing code
structures that encourage the use of structured programming
techniques. Assembly languages can certainly be made friendlier
by judicious use of macro libraries (some PDP-11 code seems to
consist almost entirely of macros, using the well-developed
libraries available for those systems).
If you have the MAC assembler (or RMAC), or if you have to write
extremely fast or compact code, SAL/80 may be just the extra
advantage you need. Or, if you want to learn about macros, the
large collection in SAL/80 could be a useful introduction.
Macros are a powerful, exciting feature in any language, and
SAL/80 shows how helpful they can be.
Before you buy, decide what tools you need for the job you want
to do. If you decide that MAC or RMAC is what you need, then try
SAL/80. It can help to keep your code under control, and your
programming understandable. However, if you're trying to pick a
structured language for programming, I would recommend a C
compiler.
A lenghty "single system license agreement & support contract"
of relatively normal format for microcomputers is included. The
license does not indicate whether or not a royalty is required
if you sell code produced using SAL/80. If you intend to use
SAL/80for serious production of salable software, you will need
to negotiate a contract aimed at that production work.
Protools, a division of Newberry Microsystems, is registered
with the U.S. Patent Office.
SAL/80 is a trademark of Newberry Microsystems and is available
from: Protools, 24225 Summerhill Ave., Los Altos, CA 94022;
(415) 948-8007.
Price: $59 for 8" SD disk, 235-page manual, and one free update.
- "Letters to the Editor"
"Microsystems", Vol.5, No.5, May 1984, p.118
Dear Mr.,
I'd like a chance to respond to Mike Barker's review of our
SAL/80 package (March 1984). First, I should say that we HAVE
changed the license contract to state EXPLICITLY that no
royalties are required on programs written with the SAL/80
compiler package. We had assumed that such a statement would be
redundant, SINCE THERE IS NO RUNTIME PACKAGE TO CHARGE ROYALTIES
ON! But the fact that the question has arisen shows that
assumption to have been in error.
I really do not want to write one of those endless line-by-line
rebuttals of all those points upon which I take issue with the
reviewer. On the other hand, since more than 800 readers of
MICROSYSTEMS have requested information about SAL/80 either by
letter, phone or bingo card, here is some more information about
the package.
"SAL/80 is a package of macros that claims to be a compiler
implementing a new language of the same name." A more accurate
description would be that it converts the DRI macro assemblers
into STRUCTURED macro assemblers. It is sometimes convenient to
refer to this combination as a compiler.
What distinguishes SAL/80 from other structured assemblers is
the size and scope of the package. Where other structured
assemblers are content to provide an IF-ELSE and one or two LOOP
constructs, SAL/80 also provides a SELECT/CASE, five flavors of
LOOP, a fairly complete set of console I/O primitives, and
OPTIMIZES the test/branch code emitted by the control-
statements. This optimization means a saving of two (Z-80) or
three (8080) bytes in about a third of the branches generated.
The manual is large (235 pages), and considerable effort has
been expended to make the contents accessible as a reference. In
addition to the 3-page table of contents, there is a 5 1/2-page
subject index. The compiler source (which is given in Appendix
A) has its own table of contents and index.
Chapter 1 (45 pages) covers the syntax and semantics of the
various constructs of the "language", with flow-charts and hints
on how to use each directive. There are cross-references to
other sections of the manual and to the DRI MAC/RMAC manual.
Chapter 2 (31 pages) is a tutorial on SAL/80 in the design and
coding of well-structured modular programs. A "worked" example
is given in the form of an elaborate memory-test program, with
"snapshots" of portions of the code at various stages of
completion.
Chapter 3 (50 pages) consists of the complete listing of the
"worked" example in its final form. There are about 1,150 lines
of SAL/80 code set off by enough white space and comments to
expand it to about 2,000 lines in all. The code is very
readable, and anyone undertaking to learn SAL/80 would be well-
advised to spend some time with this chapter.
Chapter 4 is seven pages of tips on how not to get mugged by the
various snares and pitfalls of the SAL/80 package and/or the DRI
macro assemblers.
Appendix A is the compiler source (70 pages), and, quite aside
from the actual utility value of the program it represents, is
an interesting example of what can be done with the macro
facilities of MAC and RMAC.
Appendix B covers the error messages (generated by SAL/80) by
showing what will actually appear on the screen, and explaining
its significance.
Appendix C is a summary of the SAL/80 commands, with the formal
syntax and cross-references to both the pertinent text in
Chapter 1 as well as to the implementing source code in Appendix
A.
Programs in SAL/80 are written by starting with a template that
outlines the "generic" shape of the program, and may be altered
to suit the taste of the individual. This consists largely of
commented-out pre-declarations and MACLIB statements. Almost all
data structuring and manipulation is done as one is accustomed
to do in ordinary assembly-level programming, but all of the
CONTROL structuring (test/branch code) is accomplished by using
the SAL/80 control statements.
These control statements work almost precisely as do the
corresponding statements in Pascal or C, with IF-ENDIF, IF-ELSE-
ENDELSE and SELECT-CASE-ENDSELECT providing most of the forward
branching, and the several loop statements generating the
backward branches. The loop structures include the NON-INDEXED
loops WHILE-ENDWHILE (test/exit at the top), REPEAT-ENDREPEAT
(test/exit at the bottom) and LOOP-UNTIL-ENDLOOP (test/exit in
the middle), as well as the INDEXED loops FOR-UNTIL-STEP-ENDFOR
(test/exit anywhere) and DO-ENDDO (test/exit at the bottom).
The "utility" macros are primarily concerned with console I/O,
although there are some string operations (search and compare)
and some 8- by 16-bit multiply and divide routines. The console
I/O primitives reduce by an order of magnitude the number of
keystrokes required, as compared with that of "naked" assembler.
A program of 100 lines (exclusive of comments or white space)
will compile in about one minute on a 6 MHz machine using 8"
disks. Although this is rather slow, programmers experienced in
the use of the package have found that the overall reduction in
development time is great enough to make this acceptable.
We, at PROTOOLS, expect that the next version (3.0) will be a
separate, native code preprocessor compatible with other
assemblers, will support Zilog as well as Intel mnemonics, and
should run two to four times faster. In the meantime, the price
of $59 (which includes a free update to version 3.0 when
available, later this year) is intended to compensate for the
slowness of compilation. A SAL/86 for the IBM PC will be offered
for $99 at the same time.
As to ease of use, the point can be argued either way: If you
program in assembler only on rare occasions, say, one 80-line
device driver a year, then it's probably not worth the effort to
learn to use the package. If you program in assembler on a
continuing basis or write large programs, then any structured
assembler you use will repay the effort many times over. For a
review of SAL/80 written by a user, see the February 1984 issue
of Dr Dobb's Journal.
Steve Newberry
PROTOOLS
24225 Summerhill Avenue
Los Altos, CA 94022
EOF
I am Mr. Emmanuel Roche,
Chemin de Boisrond
17430 Tonnay-Charente
FRANCE
I have participated to the comp.os.cpmNewsgroup for 10 years.
But I have been unable to find one "SAL-80" package from the "ProTools" company of "Steve Newberry". (Details below.)
If anybody out there knows about it...
Yours Sincerely,
Mr. Emmanuel Roche, France
- "Software Review: SAL/80"
Jim Kronman
DDJ, Vol.9, No.2, February 1984, p.77
Company: Protools, 24225 Summerhill Avenue, Los Altos, CA 94022
System : CP/M 2.2
Price : $59.95
SAL/80 is a software package that adds standard "structured"
control operators to the Intel 8080/85 assembly language and can
also, at the user's option, produce some code optimized with
Zilog Z-80 instructions. SAL/80 is designed to be used with the
Digital Research, Inc. MAC and RMAC macroassemblers. In addition
to the control structures, built-in library functions are
provided. Newberry Microsystems refers to SAL/80 as a
"language", but it is actually a language enhancement, used in
the same way as RATFOR is used with FORTRAN.
Structured programming is a lot like religion: either you
believe or you don't. I will not try to sell you on the concept
in this review, but if you believe in minimal use of GOTO, you
will appreciate SAL/80.
This review applies to version 2.1 of SAL/80 running under CP/M
2.2. The author of SAL/80 is Steve Newbery, and it is marketed
by Steve's company: Protools. The current price for SAL/80
(including a 200-plus page manual) is $59.95. The price includes
a free update to version 3.0. SAL/86 is, or will be, available
for Intel 16-bit processors (8086 and 8088).
What It Is
----------
SAL/80 provides these familiar control structures:
DO-ENDDO
FOR-UNTIL-STEP-ENDFOR
IF-ENDIF-ELSE-ENDELSE
LOOP-UNTIL-ENDLOOP
REPEAT-ENDREPEAT
WHILE-ENDWHILE
SELECT-CASE..CASE-ENDSELECT
EXIT and GOTO are also provided.
The control structures are supported by a wide range of boolean
expressions of the form X,rel,Y where X and Y (with a few
limitations) can be any register, register pair, memory
reference, or constant. The "rel" in these expressions can be
either the usual comparisons (such as greater than, equal to,
etc.) or one of several CPU status flag conditions (e.g., Carry
set, minus, etc.) that requires no argument (X and Y are null,
and the PSW is implied). For convenience, IFCALL and IFGOTO are
provided to allow a conditional call and goto consistent with
the other operations.
The SAL/80 built-in functions include register save and restore
functions. Most of the built-ins are designed to facilitate
program-to-user interface via the console.
Several SAL/80 library files are also provided on the
distribution disk. They include block move, string search, and
comparison procedures, and multiply and divide.
SAL/80 is designed to work in an Intel 8080/85 environment, but
optionally will generate Zilog Z-80 code for relative jumps, and
the "DJNZ" instruction in loops.
Using SAL/80
------------
SAL/80 version 2.1 is implemented as a set of macros that must
be invoked as "MACLIB SAL/80" at the beginning of your assembly
language program. You include the SAL/80 instructions as part of
your assembly language program code. When it is time to assemble
the code, SAL80.LIB and any of the provided LIB files you have
referenced must be on the same disk as your source code. You run
MAC or RMAC, and the program is assembled.
SAL/80 Documentation
--------------------
The SAL/80 manual has four chapters and three appendices. The
chapters are indexed. The compiler source code has its own
index, this source listing plus its index taking 72 pages.
Chapter One, "Overview of Essential", explains the syntax,
content, and use of SAL/80 in 45 pages. A generalized example of
each construct or function is given in schematic form. For
example:
LOOP?
[<loop body>]
UNTIL? <bool expr>
[<more loop body>]
ENDLOOP?
This example points out one feature I have so far not mentioned:
all SAL/80 instructions are terminated with "?".
Chapter Two, "Tutorial: Maintainable Programs", is a 31-page
essay on software design using a real-life (if somewhat
contrived) example. All of the steps from design concept to
finished product are covered.
Chapter Three, "Tutorial Worked Example: MEMTEST", is the
complete source code listing of the example used in the previous
chapter. It includes its own index (for the program) and
occupies 50 pages. MEMTEST is a memory test program.
Chapter Four is called "General Observations" and talks about
using MAC and RMAC and the application of some of the features
of SAL/80.
Appendix A of the manual is the complete SAL/80 source code. The
distribution disk file SAL/80.LIB, however, does not look like
the source code. It has been, in Newberry's words, "Krunched" in
order to save disk and TPA space. Appendix B lists the source
code for the error trapping portion of SAL/80.LIB. Appendix C is
a summary of SAL/80 commands.
Performance
-----------
SAL/80 does what it claims to do. It runs, has a few bugs, but
is well supported by the author. I can only fault it for being
SLOW. On the other hand, RATFOR is no burner with FORTRAN,
either. Steve Newberry has recognized the speed problem with his
MAC.LIB approach, and is currently preparing a preprocessor
version of SAL/80 written in the C language. Purchasers of
version 2.1 will receive version 3.0 free when it is available.
The code produced by SAL/80 is reasonably close to being as
compact as the code you would produce if you coded in "pure"
assembler. For example, a small menu-drive program I wrote with
SAL/80 to send set-up commands to a printer was 1.4K bytes, and
a similar program for another printer from "pure" assembly code
was just under 1.0K bytes. Although some minor inefficiencies
have been created in exchange for generality, SAL/80 generates
more compact code than any high-level language compiler I have
used. I have not noticed any case where execution speed has
suffered. My experience with SAL/80 has been with business
applications; if you are coding a real-time control application,
however, you might encounter critical areas where fine tuning is
required. The same would be true if you were coding in "pure"
assembler.
Most of the constructs work as you would intuitively expect them
to from experience with higher-level structured language such as
Pascal or C. I found the SELECT construct, however, more limited
than its CASE counterpart in Pascal. SELECT-CASE..CASE-ENDSELECT
is actually more like FORTRAN's computed GOTO statement. The
first choice (CASE) MUST be 0, then 1, and so on. This is stated
in the documentation, but I had a hard time understanding what
it meant, probably because I wanted it to work like Pascal!
Another enhancement that would have been nice is if the X,rel,Y
operations (RELational operators) would accept the syntax "A" to
represent 41 hex and so on (like CHR(A) in Pascal, or the
literals in standard Intel assembler code).
I have not succeeded in getting the example program, MEMTEST, to
run on my computer. I must admit that I have not given much
priority to this, and therefore have not spent much time trying.
I have had substantial difficulty, however, getting any of my
own applications written with SAL/80 running.
The only other operational criticism I can make is that the
error messages are not always sufficiently clear to allow
debugging without resorting to examination of a PRN file with
the macro expansion included. This might not seem like a big
deal until the first time you look at such a file from SAL/80.
Some of those innocent-looking constructs and built-in can
generate gobs of code!
I have found no problems in the built-in and library functions
supplied with SAL/80, but in some respects they are a
reinvention of the wheel. My personal preference is for a set of
routines like Richard Conn's SYSLIB functions, which are in the
public domain. I find some of the SAL/80 procedure names (such
as "compare$strings:") to be longer than necessary. I type a
lot, but that does not mean I like to do it.
Evaluation of the Documentation
-------------------------------
When I originally ordered SAL/80, I was motivated to do so by
the documentation more than by the program itself. I thought it
would be an economical way to learn more about MAC and RMAC, and
to pick up a few new programming tricks. My aims were
accomplished, but I feel the documentation
would be improved in some areas.
The manual is better than many. It IS thoroughly indexed. In
fact, I wish more software publishers would be as thorough as
Steve Newberry has been in indexing his manual.
The greatest improvement in the manual would be to provide a
real, concrete, illustrative example with the definition of each
command. This would go a long way toward making SAL/80
immediately useful. I found that I had to try each construct a
few ways until I got clear in my mind what each function could
and could not do. Some real examples accompanying each function
description would have saved me hours of time.
Another welcome addition would be a simple, columnar quick-
reference list of all reserved words, and a compact quick-
reference guide for the commands. I would like to see the
commands, built-ins, and so on defined one to a page in the
manual for ease of reference.
Support
-------
I have nothing but praise for Newberry's support of his product.
I am somewhat reluctant to print constructive criticism about
SAL/80 because he has been so responsive to past inputs (from me
and others). I am reasonably sure that most of my criticisms
will have been answered by changes in the documentation by the
time you read this review. His initial release of version 2.1
had some bugs in it, but it was released at a discount. In
addition, anyone who reports a real bug receives a free update
to version 3.1 for the effort (version 3.0 is already included
when you buy 2.1). Corrections fixing the identified bugs have
been mailed to users in a timely manner.
Conclusions
-----------
If you must do assembly language programming, and want to
generate more readable and maintainable code, then you should
investigate Protools' SAL/80. It has the potential to give you
some of the advantages of the higher-level languages, while
retaining the control and efficiency of machine-level
programming.
- "Letters to the Editor: Fussing over SAL/80"
DDJ, Vol.9, No.4, April 1984, p.9
Dear Doctor:
This is to express my heartfelt appreciation for the very
thorough and objective review of our SAL/80 package in the
February issue by Jim Kronman. I am embarrassed to take ANY
exceptions to what he has written, BUT...
One thing I do feel obliged to remark on Jim's example of code-
density compares two printer drivers, one in naked assembler and
one in SAL/80. The SAL/80 driver is 400 bytes larger than the
naked assembler, which might seem to imply that SAL/80 has a
run-time package of 400 bytes. This is NOT the case. SAL/80 has
NO run-time package (and NO royalties for commercial
distribution of code generated using SAL/80).
But then, it might seem to imply that the code emitted by SAL/80
is 40% larger than that obtained by coding in naked assembler,
which is even WORSE! I haven't seen the two drivers in question,
but I am quite certain that there are differences between the
two which would account for all except a maximum of about 100
bytes plus perhaps 5% of the remaining difference.
There are several UTILITIES in the package which, all taken
together, might contribute perhaps to 100 bytes of excess code,
because of their generality. And the test/branch code can
typically be squeezed by about 5% in the average case. The 5%
results from the fact that jumps to jumps do occur when a
forward branch is emitted in the last group of a loop-body
(hence, three bytes may be squeezable), and that the HL register
is saved in certain memory-reference comparisons (which gives
two possibly squeezable bytes if HL was inactive at the time).
The reason I am making such a fuss about this is that SAL/80 is
the only structured assembly package I know of that actually
does OPTIMIZE the test/branch code! There is a huge decision-
tree in the compiler which does all the tricks dear to the
hearts of assembly-language programmers to avoid writing two
conditional jumps to implement LE ("<=") and GT (">")
comparisons. On a branch-by-branch basis, SAL/80 emits the
tightest code possible if the double-registers are to be
preserved over the comparison.
Cordially,
Steve Newberry
Protools
24225 Summerhill Avenue
Los Altos, CA 94022
- "SAL/80 from Protools"
Mike Barber
"Microsystems", Vol.5, No.3, March 1984, p.116
On the one hand, structured languages often produce code that
isn't too efficient in terms of space and time. On the other
hand, assembly languages can be a haven for unstructured,
unreadable, but efficient code. If you wanted to provide methods
for writing structured assembly code and spent enough time with
the macro capabilities of your favorite assembler, you might
produce something like SAL/80. Of course, with SAL/80, you can
just start writing the code for your program.
The macro library
-----------------
SAL/80 version 2.1 is a macro library containing a variety of
useful macros, including macros for selection (if-else, case),
repetition (while, repeat, loop, do, for-until), flow-of-control
(call, conditional calls), and various helpful utilities. It is
intended for use with the MAC or RMAC assemblers from Digital
Research, and requires a 64K 8080/Z-80 system running CP/M 2.2.
The SAL/80 macro libraries contain a good collection of assembly
language macros. The manual does not provide the easiest
introduction to their use but, with the original source listing
provided in the manual and some experimentation, they are
usable.
The utility macros in the SAL/80 libraries are, in part, adapted
from those in the MAC library on Volume 24 of the CP/M User's
Group, and from other sources. They provide several varieties of
console interaction, including console status, character or
buffer input/output, binary converted to ASCII hex for output,
and ASCII hex input converted to binary. Binary/hex and
binary/decimal conversions are also included.
Utility macros for register/stack and register/memory
manipulations, double-register subtracts and compares, and 16x8-
bit multiply and divide routines act as extensions to the
assembly language. Block moves, string search within a block,
lower-to-upper case conversion, and string comparison macros
complete the set of utilities.
Although the utility macros are a kind of bonus in SAL/80, since
the package focuses on structured assembly language programming,
I would have liked a more complete set of utility macros,
including interfacing to all the CP/M functions and a fuller set
of string manipulations. The set of utility macros that is
provided does not seem to have been as carefully designed and
thought out as the set of structured language macros. For
example, the lack of file-I/O macros forces you to write new
code every time, or to write your own macros, or to use macros
from yet another source.
Documentation
-------------
The SAL/80 manual is (mostly) a hacker's explanation of an
approach to programming and an example of that approach. The
example uses the SAL/80 macros and assembly language. However,
the description focuses on the approach, not the macros. I
enjoyed this description as a working example of an approach to
programming by one hacker -- something that is often described
abstractly, but rarely with the depth of concrete detail given
here.
The manual includes a section describing the macros. This
section is modeled on a syntactic description of a programming
language that makes it difficult to see the macros for the
syntax. I would like to see this section moved to an appendix
(for those who like formal syntax descriptions). It could be
replaced with a simple list or index of the macros, followed by
single-page descriptions of the macros, like those often used in
language reference manuals. Each page could describe a macro
structure and its parameters. This type of description is
present, but is difficult to see in the current section.
Why use SAL/80?
---------------
Programmer's tools like SAL/80 are measured by a simple
question, "Why should I use it?"
SAL/80 can help assembly language programmers by providing code
structures that encourage the use of structured programming
techniques. Assembly languages can certainly be made friendlier
by judicious use of macro libraries (some PDP-11 code seems to
consist almost entirely of macros, using the well-developed
libraries available for those systems).
If you have the MAC assembler (or RMAC), or if you have to write
extremely fast or compact code, SAL/80 may be just the extra
advantage you need. Or, if you want to learn about macros, the
large collection in SAL/80 could be a useful introduction.
Macros are a powerful, exciting feature in any language, and
SAL/80 shows how helpful they can be.
Before you buy, decide what tools you need for the job you want
to do. If you decide that MAC or RMAC is what you need, then try
SAL/80. It can help to keep your code under control, and your
programming understandable. However, if you're trying to pick a
structured language for programming, I would recommend a C
compiler.
A lenghty "single system license agreement & support contract"
of relatively normal format for microcomputers is included. The
license does not indicate whether or not a royalty is required
if you sell code produced using SAL/80. If you intend to use
SAL/80for serious production of salable software, you will need
to negotiate a contract aimed at that production work.
Protools, a division of Newberry Microsystems, is registered
with the U.S. Patent Office.
SAL/80 is a trademark of Newberry Microsystems and is available
from: Protools, 24225 Summerhill Ave., Los Altos, CA 94022;
(415) 948-8007.
Price: $59 for 8" SD disk, 235-page manual, and one free update.
- "Letters to the Editor"
"Microsystems", Vol.5, No.5, May 1984, p.118
Dear Mr.,
I'd like a chance to respond to Mike Barker's review of our
SAL/80 package (March 1984). First, I should say that we HAVE
changed the license contract to state EXPLICITLY that no
royalties are required on programs written with the SAL/80
compiler package. We had assumed that such a statement would be
redundant, SINCE THERE IS NO RUNTIME PACKAGE TO CHARGE ROYALTIES
ON! But the fact that the question has arisen shows that
assumption to have been in error.
I really do not want to write one of those endless line-by-line
rebuttals of all those points upon which I take issue with the
reviewer. On the other hand, since more than 800 readers of
MICROSYSTEMS have requested information about SAL/80 either by
letter, phone or bingo card, here is some more information about
the package.
"SAL/80 is a package of macros that claims to be a compiler
implementing a new language of the same name." A more accurate
description would be that it converts the DRI macro assemblers
into STRUCTURED macro assemblers. It is sometimes convenient to
refer to this combination as a compiler.
What distinguishes SAL/80 from other structured assemblers is
the size and scope of the package. Where other structured
assemblers are content to provide an IF-ELSE and one or two LOOP
constructs, SAL/80 also provides a SELECT/CASE, five flavors of
LOOP, a fairly complete set of console I/O primitives, and
OPTIMIZES the test/branch code emitted by the control-
statements. This optimization means a saving of two (Z-80) or
three (8080) bytes in about a third of the branches generated.
The manual is large (235 pages), and considerable effort has
been expended to make the contents accessible as a reference. In
addition to the 3-page table of contents, there is a 5 1/2-page
subject index. The compiler source (which is given in Appendix
A) has its own table of contents and index.
Chapter 1 (45 pages) covers the syntax and semantics of the
various constructs of the "language", with flow-charts and hints
on how to use each directive. There are cross-references to
other sections of the manual and to the DRI MAC/RMAC manual.
Chapter 2 (31 pages) is a tutorial on SAL/80 in the design and
coding of well-structured modular programs. A "worked" example
is given in the form of an elaborate memory-test program, with
"snapshots" of portions of the code at various stages of
completion.
Chapter 3 (50 pages) consists of the complete listing of the
"worked" example in its final form. There are about 1,150 lines
of SAL/80 code set off by enough white space and comments to
expand it to about 2,000 lines in all. The code is very
readable, and anyone undertaking to learn SAL/80 would be well-
advised to spend some time with this chapter.
Chapter 4 is seven pages of tips on how not to get mugged by the
various snares and pitfalls of the SAL/80 package and/or the DRI
macro assemblers.
Appendix A is the compiler source (70 pages), and, quite aside
from the actual utility value of the program it represents, is
an interesting example of what can be done with the macro
facilities of MAC and RMAC.
Appendix B covers the error messages (generated by SAL/80) by
showing what will actually appear on the screen, and explaining
its significance.
Appendix C is a summary of the SAL/80 commands, with the formal
syntax and cross-references to both the pertinent text in
Chapter 1 as well as to the implementing source code in Appendix
A.
Programs in SAL/80 are written by starting with a template that
outlines the "generic" shape of the program, and may be altered
to suit the taste of the individual. This consists largely of
commented-out pre-declarations and MACLIB statements. Almost all
data structuring and manipulation is done as one is accustomed
to do in ordinary assembly-level programming, but all of the
CONTROL structuring (test/branch code) is accomplished by using
the SAL/80 control statements.
These control statements work almost precisely as do the
corresponding statements in Pascal or C, with IF-ENDIF, IF-ELSE-
ENDELSE and SELECT-CASE-ENDSELECT providing most of the forward
branching, and the several loop statements generating the
backward branches. The loop structures include the NON-INDEXED
loops WHILE-ENDWHILE (test/exit at the top), REPEAT-ENDREPEAT
(test/exit at the bottom) and LOOP-UNTIL-ENDLOOP (test/exit in
the middle), as well as the INDEXED loops FOR-UNTIL-STEP-ENDFOR
(test/exit anywhere) and DO-ENDDO (test/exit at the bottom).
The "utility" macros are primarily concerned with console I/O,
although there are some string operations (search and compare)
and some 8- by 16-bit multiply and divide routines. The console
I/O primitives reduce by an order of magnitude the number of
keystrokes required, as compared with that of "naked" assembler.
A program of 100 lines (exclusive of comments or white space)
will compile in about one minute on a 6 MHz machine using 8"
disks. Although this is rather slow, programmers experienced in
the use of the package have found that the overall reduction in
development time is great enough to make this acceptable.
We, at PROTOOLS, expect that the next version (3.0) will be a
separate, native code preprocessor compatible with other
assemblers, will support Zilog as well as Intel mnemonics, and
should run two to four times faster. In the meantime, the price
of $59 (which includes a free update to version 3.0 when
available, later this year) is intended to compensate for the
slowness of compilation. A SAL/86 for the IBM PC will be offered
for $99 at the same time.
As to ease of use, the point can be argued either way: If you
program in assembler only on rare occasions, say, one 80-line
device driver a year, then it's probably not worth the effort to
learn to use the package. If you program in assembler on a
continuing basis or write large programs, then any structured
assembler you use will repay the effort many times over. For a
review of SAL/80 written by a user, see the February 1984 issue
of Dr Dobb's Journal.
Steve Newberry
PROTOOLS
24225 Summerhill Avenue
Los Altos, CA 94022
EOF
Although I don't know much about CPM, one of these days when I dig out my Kaypro which is sitting in the basement, I might need Mr. Emanuel's help.