In which way(s) can a macroprocessor for assembly language be implemented?

Concept. A macro processor is the text-processing stage of the language-processing system that handles the macro facility of an assembly language. Its work is fixed by two data structures and two jobs: it records each macro definition — the macro name, its formal parameters and its body — in a macro name table and a macro definition table, and it later replaces each macro call in the source with a copy of that body in which the actual arguments have been put in place of the formal parameters. What it hands on is ordinary assembly source, which the assembler then translates.

Concept — the organisations open to it. Nothing in that job description fixes how the processor itself is organised, so systems-programming texts (Beck, Dhamdhere) treat the macro processor’s design as a separate choice with three recognised forms: a separate program that reads the source twice, a separate program that reads it once, and a macro processor folded into pass 1 of a standard two-pass assembler. The two-reading and one-reading forms differ only in when a definition becomes available for expansion, which is why the one-reading form requires a definition to be written before the call that uses it.

Application. The stem asks in which way or ways a macroprocessor for assembly language can be implemented, so each statement offered is tested against that description:

• “Independent two-pass processor” — a macro processor written as a program of its own that reads the source twice: the first reading collects the definitions, the second performs the expansions. This is a standard macro processor design.

• “Independent one-pass processor” — a macro processor written as a program of its own that reads the source once, recording a definition when it meets it and expanding a call when it meets it. This is also a standard design; it simply constrains a definition to be written before the call that uses it.

• “Expand macrocalls and substitute arguments” — the transformation carried out in either of those organisations: the call line is replaced by the macro body and the formal parameters are replaced by the actual arguments. It states how the work is done rather than how many readings are taken.

Cross-check. Each of the three statements is a true description of macro processing for assembly language, so no single one of them answers a question that asks in which way or ways the processor can be implemented. The three are not of one kind: the two independent designs name organisations of the processor, while expansion with argument substitution names the operation those organisations carry out. The remaining recognised organisation — a macro processor incorporated into pass 1 of a two-pass assembler — is not listed in this item at all. The examination takes the broad reading of “way(s)”, under which each listed statement describes a way the processor is realised, and the published key for this paper records the response that covers all three.

Result. All three listed statements describe ways in which a macroprocessor for assembly language is realised — two of them as organisations of the processor and one as the operation it carries out — so the response this item calls for is “All of the above”.