PiDP-8/I Software

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 a relative assembler, unlike PAL8 or FLAP, meaning that the OS/8 linking loader (`LOADER.SV`) adjusts all of the addresses in the assembled `*.RL` output to their final values.

SABR is an absolute assembler like PAL8 or FLAP, and it does not have any tie to the FPP.
SABR does not have any tie to the FPP, unlike RALF/FLAP.

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.
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 less efficient than hand-tuned code for other assemblers.

You can see this design decision in several language differences relative to PAL-III or PAL8:

*   No `FIELD` pseudo-op
*   No `FIELD` pseudo-op; not needed, given relocatable output
*   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
    *   `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
    *   `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.
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.

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 also provides some predefined custom 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:
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

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.
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:
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 interpretation of a constant in the presence of `DECIMAL`
*   `K` prefix for octal-in-decimal-context flip case
*   `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.
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`.

[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