What follows, in a sequence of posts having this same title suffixed
with the successive roman numerals i, ii, . . . , is an attempt to
restate the case for macro-intensive use of the HLASM.
Much of It is perforce language-specific. The macro language of the
HLASM is a powerful (string-processing and arithmetic) statement-level
procedural language embedded in the assembler. The macro languages of
other assemblers are usually different from and much inferior to that
of the HLASM, so much so that much of what follows here would be
inapplicable to them.
First, some generalities. The classical criticisms of assembly
languages are 1) that they are long-winded and detail-ridden and 2)
that assembly-language routines are not portable from one machine
architecture/platform to another. Macros can very largely eliminate
prolixity and déjà vu; they can only mitigate portability problems.
The arguments for the use of assembly-time macros are very like the
arguments for the use of execution-time subroutines. They encapsulate
a repeatedly required function; and, once written, tested, and
documented in situ, they can be used over and over again without much
fear that they will bite, that they will themselves be the source of
errors.
Another important argument for their use is that they can make
techniques available that many of their users do not or cannot
otherwise employ.
An example will help here. Many macro definitions have keyword
parameters of the form
| . . .
| whatever=yes, -- |no
+
| . . .
or, of course,
| . . .
| whatever=no, -- |yes
+
| . . .
I have seen much code that examines the value of &whatever to
determine whether it has, say, the value 'yes' and then, if it does
not, assumes that it instead has the value 'no'. A better approach
is to write a macro definition, call it YESNOCHK, that
can recognize any CIDT (case-independent disambiguating truncation) of
yes or no, viz., any of no|nO| No| NO| n| N|
yes|yeS|yEs|yES|Yes|YeS|YEs|YES, setting two binary/boolean created
set symbols, one to indicate recognition|non-recognition of an input
and the other to specifiy the boolean value of a recognized input.
In fact one can go further. This is a special case of a more general
problem. Consider that of recognizing one of the elements of the set
dither
wait
tergiversate
start
falter
delay
stop
procrastinate
waver
given a putative, not necessarily proper CIDT. We first put them into
ascending lexicographic sequence, padded on the right with nuls,
x'00', to make their lengths equal, and then note the leftmost
character position in which each differs from its predecessor and/or
successor.
The result is
delay, de, 2
dither, di, 2
falter, f, 1
procrastinate, p, 1
start, sta, 3
stop, sto, 3
tergiversate, t, 1
wait, wai, 3
waver, wav, 3
We can now 1) use lub-seeking binary search in an assembly-time table
and then 2) iff this search is successful, determine whether the
search argument is a CIDT, whether, that is, it matches the leftmost
substring of its lub of its length and this length is greast enough,
that, for example, all of
o sta, star, start, are recognized as instances of start,
o sto, stop are recognized as instances of stop, and
o s and st are not recognized as instances of either.
This machinery can be, and in my macro CIDTTCON is, entirely
automated. It generates macro definitions containing already
initialized tables. YESNOCHK is not written; it is generated.
Now this example is trivial, but it does illustrate that power and
convenience are available to those who will but [learn to and] write
macro definitions. It also illustrates one of the chief merits of
macros. They can be used to treat an entire class of problems, not
just one instance/special case of that class.
Worth noting explicitly is that the traditional definition of a macro
as a mechanism for generating many lines of code from only a few of
them is, while not entirely wrong, inadequate. Many of the most
useful macros in my libraries do not generate even a single line of
code. Others use them to generate code. Created global set symbols
and arrays of them have made it possible to get data out of macros as
readily as one puts data into them.
An important characteristic of many of these service macros is that
other programmers need to know only what, functionally, they do. They
are also welcome to learn how these macros do what they do, but many,
regrettably, do not do so. Deadlines make intellectual curiosity
expensive.
More in subsequent instalments.
John Gilmore, Ashland, MA 01721 - USA
