264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
|
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
|
-
+
|
* `ABSYM`: define a symbolic name for an absolute core memory location
* `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; `INC` non-skip version of `ISZ` predefined
* `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. 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.
You may be surprised to see the `OPDEF` and `SKPDF` pseudo-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
* `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
|