Was there an analog of local labels in the IBM assembly language?

Question

In the assembly language used in Unix on DEC machines (PDP-11, VAX), one can use numerical labels and refer to them with suffixes "b" and "f" meaning "backwards" and "forwards", e.g. (in the insructions beql, bneq, aoblss, acbw below)

#
# search the root directory
#

    clrl    r12         # init block pointer
dirblk:
    clrl    r5          # use beginning of mem as buffer
    bsbw    lread
    bneq    stask           # eof, try another file
    clrl    r9
0:
    movzwl  (r9)+,r0        # empty entry?
    beql    2f              # yes, skip it
    clrl    r1
1:  cmpb    (r9)[r1],bootname[r1]   # MicroVAX II doesn't have cmpc
    bneq    2f
    aoblss  $DIRSIZ,r1,1b
    brb diryes          # the name we want

2:  acbw    $FSBSIZE-1,$DIRSIZ,r9,0b
    incl    r12         # get next block
    brb dirblk

Numerical labels can be reused as the references signify the closest occurrence of the label with the given number in the given direction (and, IIRC, no further than the closest alphanumerical label in that direction). This greatly reduced the need to invent names for labels, made the assembly code quite neat, and improved readability with the relative location of the branch target explicitly specified.

Per @another-dave in the comments, the original DEC assembly language had local labels as well, with a slightly different naming convention.

Was there a similar feature in the IBM assembly language?

Answer 1

Or, more specifically, IBM/360

No.

All labels were always global.

The 360 assembler did not provide such relative labels (*1).

But.

On the other hand it provided procedural macro language (*2), which as well included the ability to generate symbols and thus labels in arbitrary manner. All needed to make them local is using a unique number - which quite handy was supplied by a macro call counter called SYSNDX. So to generate a local label within a macro, simply build one using this. For example:

A&SYSNDX  DS  0H           * Generates a label Annnn with nnnn increasing with each macro call
          ...              * Some code
          BCT R1,A&SYSNDX  * Jump to the label generated before

As said, the 360 macro language is a full figured procedural language, not just a set of random functions, making it possible to create the same effect. One macro to define such 'relative' labels and build a set of lists (*3), one for each 'number' used, to keep track of existing and future labels. Another macro would then be used to generate these jumps. Such a source may look like this:

         ...
0        RELAB             * Generating a '0' label
         ...               * Some code
         RELBR  EQ,2F      * Jump forward to the next '2' label
         ...               * Some code
1        RELAB             * The one generating the labels
         ...               * Some code
         RELBR  NE,1B      * Jump back to the last '1' label
         ...               * Some code
2        RELAB             * Generating a '2' label

Looks quite like your example - although, I'd split the forth and back from the label (e.g. write EQ,1,B), but that's up to taste.

The incredible simple and mighty nature of having a procedural macro language and not a bunch of replacement rules opens the range to any concept one can think up. Which in turn would lead to skipping the idea at all, and go straight for structured programming. After all, why bother with labels at all if one can let the Assembler do all low level work?

---

*1 - And I never missed them in all the decades of /360 programming. Tried them with some toy assemblers, but never really found them useful ... well, maybe if there is nothing else.

Beside that, I'd rather consider them bad idea. Put a new label between two existing (something that happens all the time when editing/extending) and the whole sequence may be screwed.

*2 - Think of macros as scripts written in a simple language. Whenever a macro is invoked, its script is executed. It may generate code, or just manipulate some data structures to be interpreted by a later macro (or macro instructions within the source as well). Every part of the invocation can be read, checked and acted upon as parameters. Noting is done by default. As output any arbitrary source line can be generated - including ofc. macro calls as well :))

*3 - Ok, lists sounds more than it is, in reality one needs to hold only two variables for each of the numbers allowed as label.

Answer 2

Yes, maybe, in a way. It depends on how you define “IBM assembly language”. If it must be officially produced and distributed by IBM, then this isn't an answer, but if the sole criterion is that it is an assembly language for an IBM computer, then the answer is definitely yes.

The IBM 650 had an assembler called SOAP, for Symbolic Optimum Assembly Program. It was “optimum” in that it tried to assign memory addresses so that the drum movement required for retrieving the next instruction was minimized. A second version of SOAP, SOAP II, was produced and distributed by IBM, becoming the canonical assembler for the 650.

In 1958, Donald Knuth (whose first experiences with a computer were with the 650) created a modification of SOAP II, which he called SOAP III. The manual for SOAP III is available online. This assembler supported local labels, although Knuth's term for them is “program point”.

D. Program points. When either the D- or I-address is to refer to location “1” which appers later, the address “IF” (1 forward) is given; to refer to location “1” which appeared earlier in the program, the address “1B” (1 backward) is given. The location 1 would be called simply “1.” Ten program points are available, 0–9, and each may be constantly redefined during the course of the program. If the program is written down on a coding form in sequence, “1F” will always refer to the next location 1 on the coding form; “3B” will always refer to the previous location "3" occurring on the form. In location 1, a D- or I-address of 1F may be given immediately, referring to a future location 1. A D- or I-address of IB would still refer to the last location 1 (not the present one), A D- or I-address of “1” will refer to its own location.

Rules: 1. A D- or I-address will be interpreted by SOAP as a program point only if the symbolizer part [i.e., the first character of the address] is a number, the second column is a “B” or an “F”, and the remaining columns are blank. 2. The L-address of an instruction will be interpreted by SOAP as a program point only if the symbolizer part is a number and all remaining columns are blank. 3. A D- or I- address consisting of a number followed by four blanks will always refer to its own location, regardless of what number is used or what type of address is used in the L-address.

This is the first implementation of the idea that I am aware of. Here's a listing of SOAP III, so you can see them in action. Knuth would go on to incorporate it into an assembler for the Burroughs 205, and some other Burroughs assemblers had them as well. Most famously program points are available in the assembler for Knuth's MIX computer.

In the SOAP III manual, Knuth credits Melvin Conway with the concept of program points.

Answer 3

In a macro language with an IBM-like syntax, local labels are implementable with macros defined approximately as

 macro
&a lbl                 define a label
 gblc &b(9),&f(9)
 aif (&f(&a) eq '').n
&b(&a) setc &f(&a)     copy from forward to backward list
 ago .e
.n anop
&b(&a) setc 'm&sysndx' will be backward-referenced, assign a name
.e anop
&b(&a) nop
 mend
 macro
&lab mbr &insn,&targ,&dir
 gblc &b(9),&f(9)
 aif (&dir ne 'b').f
 aif (&b(&targ) ne '').d
 mnote label &targ not previously defined
 ago .e
.d anop
&lab &insn &b(&targ)
 ago .e
.f aif (&dir eq 'f').ff
 mnote direction must be b or f
 ago .e
.ff aif (&f(&targ) ne '').ff2
&f(&targ) setc 'm&sysndx'
.ff2 anop
&lab &insn &f(&targ)
.e mend