System/360 Macro-Assembler(ID:8478/)

Macroassembler for the S/360 

Macro assembler for the S/360

from Freeman:
" The following persons contributed especially to the language design: A. Lichtman, T. Ragland, H. W. Schmid, Jr., and S. Y. Zimmerman, Jr. Groups under J. R. Walters, Jr., and I. A. Tjomsland completed the 16K-64K implementations, which were initiated by the author and his colleagues. Many of the implementation techniques were suggested in G. H. Mealy's GAS monograph.

Related languages
GAS => System/360 Macro-Assembler   Influence

  • Freeman, DN "Macro language design for System/360", IBM Systems Journal 5(2) (1966), pp63-77 view details Abstract: The macro language design discussed in this paper provides a
    systematic means by which the SYSTEM/360 assembler-language
    programmer can develop macroinstructions, thereby expanding the set
    of machine-oriented instructions that serve as the basis of the assembler language.
    Also treated is the format of macro definitions, the design of a
    macro generator, and the principal considerations that governed the
    design of the system as a whole. Extract: Introduction
    Of several programming languages for ibxi system/360, the Assembler Language (al) is closest to the machine language in form and content. Because al enables the programmer to use all system/360 facilities as directly as if he were coding in machine language, al can be used for all types of applications, and affords the programmer complete freedom in adapting special programming techniques to his specific needs. This paper discusses a macro language that programmers can invoke to reduce al programming effort and shorten al source programs.
    With the aid of the macro language, any sequence of al statements can be "summarized" into a single macro definition. Once prepared, this definition may be stored and referred to at any time. In each case, only a single statement, a macroinsiruction, is written by the programmer. In using macroinstructions, the programmer retains access to all machine facilities; each macroinstruction is expanded into individual al statements in a predetermined way, and the programmer can intermingle macro-instructions and al statements.
    Systematic employment of macroinstructions simplifies the coding of programs, reduces the frequency of programming errors, and encourages the use of carefully standardized sequences of al statements for routine functions such as subroutine linkage. Because the programmer has to code fewer lines, fewer source cards are used. Since the programmer often suppresses the listing of generated al statements when writing in macro language, only fragments of the total program listing require review. Computer throughput on macro assemblies is thus improved by the reduced volume of printing.
    Each macroinstruction is expanded by the macro generator into a sequence of al statements, the exact sequence being governed by the corresponding macro definition. The generated al statements are then processed like any other al statements: the basic assembly program translates them into machine-language instructions, assigns storage locations, and performs auxiliary functions necessary to produce an executable machine-language program.
    An additional facility, called conditional assembly, allows the programmer to specify al statements which may or may not be generated, depending upon certain programmer-control led conditions. These conditions are usually tests of values, which may be defined, set, changed, and tested during the course of the assembly itself. By design, conditional assembly may be used independently of maeroiiistructions, as well as with maeroinstructions.
    A major objective in the design of the macro language was the inclusion of the most successful features of prior macro languages, as long as these features were not contradictory. Tt was felt that most macroinstruction formats from prior languages should be acceptable to the systkm/360 macro generator. To retain further continuity with the past, maeroinstructions should be expandable, if possible, into one-for-one statements (one al statement for one machine instruction) that are functionally oquivalent to one-for-one statements in prior assembly languages.
    Some additional design objectives were:
    *   Macro definitions should be simple in syntax and only require a small number of distinct facilities.
    *    The macro language should be a nucleus language that meets the linguistic needs of most users, but can be enlarged to accommodate specialized requirements,
    *    Marginally useful facilities whose implementation would require excessive amounts of main storage should be excluded.
    *  Assembly speeds should be excellent for simple source programs and acceptable for complex source programs.

    Extract: The language
    The macro language
    When writing a program in system/360 macro language, two categories of macroinstructions may be used:
    System macroinstructions. These instructions correspond to system macro definitions available in the systems library. Such macro definitions (also called library macro definitions) for standard instruction sequences have been prepared by IBM and can be supplemented by the user. These definitions are available for unlimited use in any number of source programs. Once a macro definition has been edited into the macro library, it can be used and reused by writing its corresponding macroinstruction into source programs.
    Programmer macroinstructions. These instructions and their corresponding programmer macro definitions are created by the programmer for certain sequences in a single program as the need arises. Programmer macro definitions must be placed at the beginning of the source program so that they can be totally edited onto one sequential file. For this type of macroinstruction, the programmer may select his own mnemonic operation codes. If a programmer macro definition becomes useful for several applications, it may be entered into the macro library; it then becomes a library macro definition. There are no format distinctions between programmer and library macro definitions.
    Most macro generators can retrieve library macro definitions faster than programmer macro definitions, because the former are read at high speed from systems residence, whereas the latter are usually read from a card reader. Thus, use of library macro-instructions (and definitions) results in faster assembly speeds and reduced card handling.
    In addition to macroinstructions, each source program may include single al statements. Such statements, requiring no expansion, are forwarded by the macro generator without any substantive change to the basic assembly process.
  • IBM Operating Systeml360: Assembler Language, Form C28-6514, IBM Corporation, Poughkeepsie, New York, 1966. view details
  • Mealy, G. H. "The functional structure of os/360, Part I, Introductory survey," IBM Systems Journal 5, No. 1, 3-11 (1966). view details
  • Brown, Peter "A survey of macro processors" pp37-88 view details Extract: 360 MA
    The System/360 Macro-Assembler [...] is a good example of a powerful
    macro-assembler. The macro processor acts as a two-pass preprocessor
    to the assembler. The first pass builds up a dictionary of all the assembly language variables and their attributes. (It also collects all the macro definitions, but this is not a feature of its base language dependence.)
    Macro replacement is performed on the second pass. Within the
    replacement text of a macro the attributes of variables appearing as its arguments may be examined and code generated accordingly. This
    facility adds considerable power to the macro processor. It is an example of a more general concept, called context-dependent replacenzent, which will be discussed later.
          in Halpern, Mark I and Shaw Christopher J (eds) "Annual Review in Automatic Programming" (6) 1969 Pergamon Press, Oxford view details