PiDP-8/I Software

[fpp8a]: https://archive.org/details/bitsavers_decpdp8pdpUsersManDec76_996770
[fpp12]: https://archive.org/details/bitsavers_decpdp12DE_2606247


### <a id="flap"></a>FLAP

RALF was based on a simpler assembler called FLAP, which generates absolute-addressed code, just as PAL8 does. This section will simply describe the differences in FLAP relative to RALF. These differences aside, FLAP shares the feature set of RALF.
[RALF](#ralf) was based on a simpler assembler called FLAP, which generates absolute-addressed code, just as PAL8 does. This section will simply describe the differences in FLAP relative to RALF. These differences aside, FLAP shares the feature set of RALF.

The primary advantage FLAP has over RALF is that, because it is difficult to ascribe meaning to the "page" concept in a relocatable assembler, RALF doesn't support the `PAGE` pseudo-op, while FLAP does. FLAP also supports the PAL family's zero-page and current-page literal syntaxes, while RALF does not.

FLAP has one pseudo-op that RALF does not, `S` for defining a single-word integer constant.

Because FLAP output is absolute-addressed, it writes `*.BN` files as output rather than `*.RL`. These are linked and loaded by the OS/8 absolute loader, `ABSLDR.SV`. You can link and run several files directly this way, or you can just load them into core and `SAVE` them to a `*.SV` file for later use by the OS/8 `R` command. This is altogether simpler than the RALF scheme, but it means you miss out on the power overlay loading scheme: FLAP programs cannot be any larger than core memory unless you, the programmer, do the manual work to create your own overlay swapping scheme.

`FLAP.SV` is currently not provided on the PiDP-8/I project's OS/8 disk packs. It is not known at this time if it is because FLAP was eventually removed from the OS/8 FORTRAN IV system or if we simply missed it when curating the input media we use for building our OS/8 disk packs. When we figure that out, I'll update this article.

By the way, you may find pages online that claim that FLAP was derived from RALF, rather than the other way around. I'm basing my claim on what DEC's own documentation says: "RALF, an extension of FLAP..." This quote was found in two different OS/8 manuals published about 5 years apart.


### <a id="sabr"></a>SABR

As RALF is to OS/8's FORTRAN IV compiler, so the [Symbolic Assembler for Binary Relocatable programs](http://homepage.cs.uiowa.edu/~jones/pdp8/faqs/#langs) is to OS/8's FORTRAN II compiler.
As [RALF](#ralf) is to OS/8's FORTRAN IV compiler, so the [Symbolic Assembler for Binary Relocatable programs](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 a relative assembler, unlike [PAL8](#pal8) or [FLAP](#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 does not have any tie to the FPP, unlike RALF/FLAP.
SABR does not have any tie to the FPP, unlike RALF and 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&nbsp;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; not needed, given relocatable output
*   The `PAGE` pseudo-op takes no argument: it simply forces the assembler to go to the next page