UNIT3 CH-1 Macros
UNIT3 CH-1 Macros
MACRO PROCESSOR
A Macro represents a commonly used group of statements in the source programming
language.
body
MEND
o Body: the statements that will be generated as the expansion of the macro.
P a g e 1 | 23
[1] Basic Macro Processor Functions:
Figure shows the MACRO expansion. The left block shows the MACRO definition
and the right block shows the expanded macro replacing the MACRO call with its block of
executable instruction.
M1 is a macro with two parameters D1 and D2. The MACRO stores the contents of
register A in D1 and the contents of register B in D2. Later M1 is invoked with the parameters
DATA1 and DATA2, Second time with DATA4 and DATA3. Every call of MACRO is
expended with the executable statements.
The statement M1 DATA1, DATA2 is a macro invocation statements that gives the name of
the macro instruction being invoked and the arguments (M1 and M2) to be used in expanding.
A macro invocation is referred as a Macro Call or Invocation.
P a g e 2 | 23
Macro Expansion:
The program with macros is supplied to the macro processor. Each macro invocation
statement will be expanded into the statement s that form the body of the macro, with the
arguments from the macro invocation substituted for the parameters in the macro prototype.
During the expansion, the macro definition statements are deleted since they are no longer
needed.
The arguments and the parameters are associated with one another according to their
positions. The first argument in the macro matches with the first parameter in the macro
prototype and so on.
After macro processing the expanded file can become the input for the Assembler. The
Macro Invocation statement is considered as comments and the statement generated from
expansion is treated exactly as though they had been written directly by the programmer.
he difference between Macros and Subroutines is that the statement s from the body of
the Macro is expanded the number of times the macro invocation is encountered, whereas the
statement of the subroutine appears only once no matter how many times the subroutine is
called. Macro instructions will be written so that the body of the macro contains no labels.
P a g e 3 | 23
The following program shows the concept of Macro Invocation and Macro
Expansion.
P a g e 4 | 23
1.2 Macro Processor Algorithm and Data Structure:
P a g e 5 | 23
MACROS for SIC machine
Fig 4.3(a)
Fig 4.3(b)
P a g e 6 | 23
A program that is to be run on SIC system could invoke MACROS whereas a
program to be run on SIC/XE can invoke MACROX.
However, defining MACROS or MACROX does not define RDBUFF and WRBUFF.
These definitions are processed only when an invocation of MACROS or MACROX
is expanded.
A one-pass macro processor that alternate between macro definition and macro
expansion in a recursive way is able to handle recursive macro definition.
Restriction
o The definition of a macro must appear in the source program before any
statements that invoke that macro.
o This restriction does not create any real inconvenience.
The design considered is for one-pass assembler. The data structures required are:
P a g e 7 | 23
ARGTAB (Argument Table)
o Stores the arguments according to their positions in the argument list.
o As the macro is expanded the arguments from the Argument table are
substituted for the corresponding parameters in the macro body.
o The figure below shows the different data structures described and their
relationship.
The above figure shows the portion of the contents of the table during the processing of the
program in page no. 3. In fig 4.4(a) definition of RDBUFF is stored in DEFTAB, with an entry
in NAMTAB having the pointers to the beginning and the end of the definition. The arguments
referred by the instructions are denoted by the their positional notations. For example,
TD =X’?1’
The above instruction is to test the availability of the device whose number is given by the
parameter &INDEV. In the instruction this is replaced by its positional value? 1.
P a g e 8 | 23
Figure 4.4(b) shows the ARTAB as it would appear during expansion of the RDBUFF
statement as given below:
For the invocation of the macro RDBUFF, the first parameter is F1 (input device code), second
is BUFFER (indicating the address where the characters read are stored), and the third is
LENGTH (which indicates total length of the record to be read). When the ?n notation is
encountered in a line fro DEFTAB, a simple indexing operation supplies the proper argument
from ARGTAB.
The algorithm of the Macro processor is given below. This has the procedure DEFINE to make
the entry of macro name in the NAMTAB, Macro Prototype in DEFTAB. EXPAND is called
to set up the argument values in ARGTAB and expand a Macro Invocation statement.
Procedure GETLINE is called to get the next line to be processed either from the DEFTAB or
from the file itself.
When a macro definition is encountered it is entered in the DEFTAB. The normal approach is
to continue entering till MEND is encountered. If there is a program having a Macro defined
within another Macro.
While defining in the DEFTAB the very first MEND is taken as the end of the Macro definition.
This does not complete the definition as there is another outer Macro which completes the
definition of Macro as a whole. Therefore the DEFINE procedure keeps a counter variable
LEVEL.
Every time a Macro directive is encountered this counter is incremented by 1. The moment
the innermost Macro ends indicated by the directive MEND it starts decreasing the value of
the counter variable by one. The last MEND should make the counter value set to zero. So
when LEVEL becomes zero, the MEND corresponds to the original MACRO directive.
Most macro processors allow thr definitions of the commonly used instructions to
appear in a standard system library, rather than in the source program. This makes the use of
macros convenient; definitions are retrieved from the library as they are needed during macro
processing.
P a g e 9 | 23
Fig 6.5: Macro library
Algorithms
P a g e 10 | 23
P a g e 11 | 23
Comparison of Macro Processor Design
One-pass algorithm
o Every macro must be defined before it is called
o One-pass processor can alternate between macro definition and macro
expansion
o Nested macro definitions are allowed but nested calls are not allowed.
Two-pass algorithm
o Pass1: Recognize macro definitions
o Pass2: Recognize macro calls
o Nested macro definitions are not allowed
The design of macro processor doesn’t depend on the architecture of the machine. We will be
studying some extended feature for this macro processor. These features are:
& is the starting character of the macro instruction; but the end of the parameter is not marked.
So in the case of &ID1, the macro processor could deduce the meaning that was intended.
If the macro definition contains contain &ID and &ID1 as parameters, the situation
would be unavoidably ambiguous.
Most of the macro processors deal with this problem by providing a special
concatenation operator. In the SIC macro language, this operator is the character .
Thus the statement LDA X&ID1 can be written as
LDA X&ID
P a g e 13 | 23
The above figure shows a macro definition that uses the concatenation operator as
previously described. The statement SUM A and SUM BETA shows the invocation statements
and the corresponding macro expansion.
it is not possible to use labels for the instructions in the macro definition, since
every expansion of macro would include the label repeatedly which is not
allowed by the assembler.
This in turn forces us to use relative addressing in the jump instructions. Instead
we can use the technique of generating unique labels for every macro invocation
and expansion.
During macro expansion each $ will be replaced with $XX, where xx is a two-
character alphanumeric counter of the number of macro instructions expansion.
For example,
P a g e 14 | 23
This allows 1296 macro expansions in a single program.
The following program shows the macro definition with labels to the instruction.
The following figure shows the macro invocation and expansion first time.
P a g e 15 | 23
If the macro is invoked second time the labels may be expanded as $ABLOOP
$ABEXIT.
There are applications of macro processors that are not related to assemblers or assembler
programming.
MACRO &COND
……..
IF (&COND NE ‘’)
part I
ELSE
part II
ENDIF
………
ENDM
Part I is expanded if condition part is true, otherwise part II is expanded. Compare operators:
NE, EQ, LE, GT.
Macro-Time Variables:
Macro-time variables (often called as SET Symbol) can be used to store working values
during the macro expansion. Any symbol that begins with symbol & and not a macro
instruction parameter is considered as macro-time variable. All such variables are initialized
to zero.
P a g e 16 | 23
Figure 4.5(a) gives the definition of the macro RDBUFF with the parameters &INDEV,
&BUFADR, &RECLTH, &EOR, &MAXLTH. According to the above program if &EOR has
any value, then &EORCK is set to 1 by using the directive SET, otherwise it retains its default
value 0.
Fig 6.9(b): Use of Macro-Time Variable with EOF being NOT NULL
P a g e 17 | 23
Fig 6.9(c) Use of Macro-Time conditional statement with EOF being NULL
Fig 6.9(d) Use of Time-variable with EOF NOT NULL and MAXLENGTH being NULL
P a g e 18 | 23
The above programs show the expansion of Macro invocation statements with different values
for the time variables. In figure 4.9(b) the &EOF value is NULL. When the macro invocation
is done, IF statement is executed, if it is true EORCK is set to 1, otherwise normal execution
of the other part of the program is continued.
The macro processor must maintain a symbol table that contains the value of all macro-
time variables used. Entries in this table are modified when SET statements are processed. The
table is used to look up the current value of the macro-time variable whenever it is required.
The macro processor continues to process lines from the DEFTAB until it encounters
the ELSE or ENDIF statement.
If an ELSE is found, macro processor skips lines in DEFTAB until the next ENDIF.
Once it reaches ENDIF, it resumes expanding the macro in the usual way.
The macro processor skips ahead in DEFTAB until it encounters next ELSE or
ENDIF statement.
The macro processor then resumes normal macro expansion.
The macro-time IF-ELSE-ENDIF structure provides a mechanism for either generating(once)
or skipping selected statements in the macro body. There is another construct WHILE
statement which specifies that the following line until the next ENDW statement, are to be
generated repeatedly as long as a particular condition is true. The testing of this condition, and
the looping are done during the macro is under expansion. The example shown below shows
the usage of Macro-Time Looping statement.
P a g e 19 | 23
WHILE-ENDW structure
P a g e 20 | 23
2.1.4 Keyword Macro Parameters
All the macro instruction definitions used positional parameters. Parameters
and arguments are matched according to their positions in the macro prototype
and the macro invocation statement.
Positional parameters are suitable for the macro invocation. But if the macro
invocation has large number of parameters, and if only few of the values need
to be used in a typical invocation, a different type of parameter specification is
required
Ex: XXX MACRO &P1, &P2, …., &P20, ….
Null arguments
P a g e 21 | 23
Keyword parameters
Each argument value is written with a keyword that names the corresponding
parameter.
Arguments may appear in any order.
Null arguments no longer need to be used.
Ex: XXX P1=A1, P2=A2, P20=A20.
It is easier to read and much less error-prone than the positional method.
P a g e 22 | 23
Fig 6.10 Example showing the usage of Keyword Parameter
P a g e 23 | 23