PiDP-8/I Software

Changes To A Field Guide to PDP-8 Assemblers
Log In

Changes to "A Field Guide to PDP-8 Assemblers" between 2017-12-10 12:20:33 and 2017-12-10 12:35:58

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
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
209
210
211
212
213







-

















+
+
+
+
+
+
+
+
+



-
-
+
+

-
+

-
+







*   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. SABR therefore provides two different ways to define custom opcodes, one for each case, which allows the programmer to clue the assembler into the correct output.

SABR has a bunch of pseudo-operators to support 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

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 in SABR which are not consequent to any of the above design constraints:

*   `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-in-decimal-context flip case
*   `IF`: conditionally skip assembling some number of the following instructions

Finally, there are some things which are different or missing in SABR as compared to PAL8:

*   `BLOCK`: same as `ZBLOCK` in PAL8
*   `IF` not as flexible as `IFDEF`, `IFNDEF`, `IFZERO` and `IFNZRO`
*    Missing pseudo-ops:
     *   `DEVICE` and `FILENAME`: not needed, call thru FORTRAN II library instead of direct to OS/8 USR
     *   `DTORG`, `EJECT`, `XLIST, `NOPUNCH` and `ENPUNCH` output controls
     *   `RELOC`: not needed, SABR output is relocatable by default

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.
2.  Explicitly via inline assembly code in a FORTRAN II program
3.  Directly as a standalone assembler.

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. This means SABR programs can always call any FORTRAN II library routine without special effort, since it is always going to be linked to it by `LOADER`.
The third option 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. This means SABR programs can always call any FORTRAN II library routine without special effort, since it is always going to be linked to it by `LOADER`.

[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.
[Ian Schofield's CC8 compiler][cc8] compiler 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