PiDP-8/I Software

[ps8ug]: https://archive.org/details/bitsavers_decpdp8sofogrammingSystemUsersGuide_2417347
[ts8m]: http://bitsavers.org/pdf/dec/pdp8/typeset8/
[ts8p]: http://gordonbell.azurewebsites.net/digital/timeline/1968-3.htm


### <a id="ralf"></a>RALF

RALF uses more or less the same statement syntax as the PAL family, but it is a very different assembler by nature. We can divide its differences into several groups.
RALF uses approximately the same statement syntax as the PAL family, but it is a very different assembler by nature. We can divide its differences into several groups.


#### Floating Point Processor Support

RALF is not only an assembler for the PDP-8 processor, it is also an assembler for the [FPP12][fpp12] Floating Point Processor (FPP) peripheral. The OS/8 FORTRAN IV delegates all of the FPP handling to RALF, but at program load time, `FRTS` checks for the existence of an FPP and switches to a software FPP simulator if there is no FPP present. (`FRTS` does the same for the EAE, by the way.)
RALF is not only an assembler for the PDP-8 processor, it is also an assembler for the [FPP12][fpp12] Floating Point Processor (FPP) peripheral. 

RALF is the back-end assembler for the OS/8 FORTRAN IV compiler, which delegates all of the FPP handling to RALF, but at program load time, `FRTS` checks for the existence of an FPP and switches to a software FPP simulator if there is no FPP present. (`FRTS` does the same for the EAE, by the way.)

Although the FPP12 was introduced with the PDP-12, it is not restricted to use with the PDP-12: it also works with all of the other PDP-8 family computers contemporaneous with and preceding it, going back to the original PDP-8. This is possible because the FPP is a bus peripheral rather than a feature of the CPU proper. DEC justified this in their documentation, pointing out that it means that a site can upgrade their existing processors with an FPP rather than buy a whole new machine with integrated FPP features when they find that software FP is taking too much time to run.

There was also a follow-on peripheral for the PDP-8/a called the [FPP8-A][fpp8a], as well as a later variant called the FPP12A, both of which are instruction-compatible with the original FPP12. The FPP features of RALF allow you to intermix FPP instructions with PDP-8 instructions just as if the FPP were part of the PDP-8 CPU, rather than being a very different external coprocessor.

Here is a summary of the FPP-related features of RALF:

#### Justifiable Restrictions

There are restrictions in RALF relative to late-generation PAL family assemblers that are justifiable on the grounds that they follow from the requirement that the output code be relocatable:

*   It does not understand the `PAGE` pseudo-op: the PAL form of this feature — where the page number is given as an argument to the pseudo-op — inherently goes against the nature of relocatable output. The inability to accept the argument-less version understood by [SABR](#sabr) is harder to justify.

*   It does not support current-page literals — `(42` — since allowing it would complicate relocation.
*   It does not support current-page literals — `(42)` — since allowing it would complicate relocation.


#### Arbitrary Differences

There are additional differences in RALF relative to the PAL family assemblers that seem entirely arbitrary to me:

*   Indirect addressing is done differently:

        TAD I A       / PAL syntax
        TAD% A        / RALF syntax

*   The programmer must tell the assembler when zero-page addressing is needed:

        TAD A         / PAL syntax: PAL assemblers know when A is on page zero and so set the Z flag in machine code output
        TAD Z A       / PAL lets you be explicit if you want; space is not optional
        TADZ A        / RALF syntax: RALF needs to be told; no space can be given

*   Its expression syntax has no "and" operator, `&`

*   It does not support zero-page literals: `[20`
*   It does not support zero-page literals: `[20]`

    This restriction does not seem to have a good justification, even in relocatable assembler output, since the nature of the feature at both at the assembly and machine code levels is that the memory reference is inherently absolute. Thus, generation of a zero-page literal cannot affect the ability of the relocating loader to relocate the generated code.
    This restriction does not seem to have a good justification, even in relocatable assembler output, since the nature of the feature at both at the assembly and machine code levels is that the memory reference is inherently absolute. Thus, generation of a zero-page literal cannot affect the ability of the loader to relocate the generated code.


#### Further Improvements

RALF also has many other improvements over late-generation PAL family assemblers such as PAL8 which are not directly tied to driving the FPP or to relocatable code:

*   Expressions: