120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
|
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
|
-
+
-
+
-
+
+
+
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
|
* `IFDEF`, `IFNDEF`, `IFZERO` and `IFNZRO` with angle brackets for conditional assembly
* `PAGE`: [re]set the page part of the location counter
* `NOPUNCH` and `ENPUNCH`: stop and restart binary output
* `RELOC`: assemble code for relocation after loading
* `XLIST`: suppress part of the listing output
* `ZBLOCK`: reserve memory, setting initial values to zero
PAL-III has one features not implemented in PAL8: the ability to get a brief listing of the undefined symbols in a program. The information is instead presented inline in the listing output, not grouped together into a single place, which can make refinement of an in-development program tedious as you need to comb information about undefined symbols out from among all the other output.
PAL-III has one feature not implemented in PAL8: the ability to get a brief listing of the undefined symbols in a program. The information is instead presented inline in the listing output, not grouped together into a single place, which can make refinement of an in-development program tedious as you need to comb information about undefined symbols out from among all the other output.
### RALF/FLAP
RALF is the back-end assembler for OS/8's FORTRAN IV compiler. As a result of that support role, it has several notable advantages over PAL8:
RALF is the back-end assembler for OS/8's FORTRAN IV compiler. As a result of that support role, it has a few primary advantages over PAL8:
* relocatable output code
* easy access to the optional [floating-point processor](http://dustyoldcomputers.com/pdp12/fpp12.html)
The RALF assembler has a mode switch that causes it to generate absolute-addressed code. In this mode, it is called FLAP.
The RALF assembler has a mode switch that causes it to generate absolute-addressed code, as PAL8 does. In this mode, it is called FLAP.
The FPP modes are the key advantage of RALF/FLAP. Vincent Slygnstad [suggests](http://so-much-stuff.com/pdp8/C/Assembler.php) that you think of these as assemblers for the FPP rather than for the PDP-8.
### SABR
As RALF is to OS/8's FORTRAN IV compiler, so [SABR](http://homepage.cs.uiowa.edu/~jones/pdp8/faqs/#langs) is to OS/8's FORTRAN II compiler. SABR is closer in feature set to PAL8, since FORTRAN II does not assume that you have a floating point processor, and it is not capable of all the relocation and overlay tricks that OS/8's FORTRAN IV compiler is.
As RALF is to OS/8's FORTRAN IV compiler, so [SABR](http://homepage.cs.uiowa.edu/~jones/pdp8/faqs/#langs) is to OS/8's FORTRAN II compiler.
SABR is an absolute assembler like PAL8 or FLAP, and it does not have any tie to the FPP.
The most notable feature of SABR is that the programmer normally writes SABR code as if using a flat memory model machine, ceding all control over literal placement and of page/field boundary placement to the assembler. This feature — called automatic paging — frees the programmer from having to deal with the [strange PDP-8 memory model][mm8], but it also means she is dependent upon the assembler to make smart decisions about all of this, even while SABR must itself run within those same constraints. This makes writing SABR easier than for most other PDP-8 assemblers, but because you can't get a whole lot of optimization smarts into a 6 kWord program, the output code tends to be rather inefficient.
You can see this design decision in several language differences relative to PAL-III or PAL8:
* No `FIELD` pseudo-op
* The `PAGE` pseudo-op takes no argument: it simply forces the assembler to go to the next page
* Off-page indirection is allowed; the assembler will generate instructions to jump between pages as needed
* No square bracket syntax for placing literals on page zero
* Several new pseudo-ops to get around the fallout of all this programmer freedom:
* `ABSYM`: define a symbolic location for an absolute core memory address
* `CPAGE`: reserve N words of core on the current page if space is available, else next page
* `LAP` and `EAP`: leave and re-enter automatic paging mode
* `OPDEF` and `SKPDF`: define custom op-codes
* `REORG`: similar to `*` feature of PAL, except that it's forced to the top of the page
* Arithmetic expressions banned in operands; simple `N+1` case replaced by the `#` feature
You may be surprised to see the `OPDEF` and `SKPDF` psuedo-ops grouped among these consequences of the way SABR works as compared to the PAL type assemblers. This is because the PAL way of defining custom opcodes (e.g. `DVI=7407`) assumes the programmer knows what she is doing with regard to whether the opcode can cause the next instruction to be skipped. Since the SABR programmer generally doesn't know where the page boundaries are, that means she cannot predict what certain instructions will look like in the final machine code, and thus whether a skip will do what she wants it to. Thus there are two different pseudo-ops, one for each case, which allows the programmer to clue the assembler into the correct output.
Consequent to that, there are several new predefined opcodes which distinguish these cases, such as `INC` vs `ISZ`, the former of which you use when the programmer knows there can be no possibility of an instruction skip, allowing SABR to generate shorter code in some cases.
SABR has a bunch of pseudo-operators meant for use in SABR's role as the back end of OS/8 FORTRAN II:
* `ARG`: define address/argument value pairs for calling FORTRAN subroutines
* `BLOCK`: same as `ZBLOCK` in PAL8
* `CALL`: call external subroutine
* `COMMN`: set aside storage space in field 1, which OS/8 FORTRAN II uses for `COMMON` storage
* `DUMMY`: used in the calling convention for FORTRAN subroutines
* `END`: mark end of program or subprogram; replaces meaning of `$` in PAL
* `ENTRY`: mark subprogram entry point
* `FORTR`: assemble FORTRAN tape
* `RETRN`: return from external subroutine
These are pretty good ways to identify SABR code: if you see any of the above pseudo-ops in a bit of code that otherwise adheres to the PAL-III base syntax, it's probably SABR code.
More features exist which are not consequent to either design constraint:
* `ACH`, `ACM`, `ACL`: address sub-words in a multi-word value
* `D` prefix on numeric constants cause decimal interpretation where `OCTAL` is otherwise in effect
* `K` prefix for octal interpretation of a constant in the presence of `DECIMAL`
* `IF`: conditionally skip assembling some number of the following instructions
A programmer may use SABR one of three ways:
1. Implicitly as the back-end of the OS/8 FORTRAN II compiler
2. Via inline assembly code in a FORTRAN II program
3. Directly.
The third option indirectly still depends upon FORTRAN II because SABR writes its `*.RL` output files with the assumption that they will be linked to the FORTRAN II runtime and libraries by the OS/8 `LOADER` program, so the generated code makes use of those facilities.
[Ian Schofield's CC8 compiler][cc8] compiler also operates like the OS/8 FORTRAN II compiler, emitting SABR output and depending upon the FORTRAN II library and runtime. Inline assembly via `#asm` is sent as-is to SABR.
[cc8]: /doc/trunk/src/cc8/README.md
[mm8]: https://tangentsoft.com/pidp8i/wiki?name=PDP-8+Memory+Addressing
## MACREL
| Introduced | 1980
| Manual | [text, 384 kB](http://vandermark.ch/pdp8/uploads/PDP8/PDP8.Manuals/AA-J073A-TA.txt)
| Delivery | DECtape for OS/8
|