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 2018-01-30 09:59:25 and 2018-01-30 10:08:31

252
253
254
255
256
257
258
259

260
261
262
263
264
265
266
267

268
269
270
271
272
273
274
252
253
254
255
256
257
258

259
260
261
262
263
264
265
266

267
268
269
270
271
272
273
274







-
+







-
+







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:

*   More instructions and pseudo-ops:
    *   Arithmetic: `FADD`, `FADDM`, `FDIV`, `FLDA`, `FMUL`, `FMULM`, `FSTA`, `FSUB`
    *   Arithmetic: `FADD`, `FADDM`, `FDIV`, `FMUL`, `FMULM`, `FSUB`
    *   Conditional jumps: `JEQ`, `JGE`, `JLE`, `JA`, `JNE`, `JGT`, `JAL`
    *   FPP to PDP-8 jumps: `JXN`, `TRAP3`, `TRAP4`
    *   Indexing: `ADDX`, `INDEX`, `LDX`
    *   Mark module as requiring double-precision hardware: `DPCHK`
    *   No-op: `NOP`
    *   Pointer moves: `JSA`, `JSR`, `SETB`, `SETX`
    *   Processor operations: `FCLA`, `FEXIT`, `FNEG`, `FNORM`, `FPAUSE`, `JAC`, `STARTD`, `STARTF`
    *   Register manipulation: `ALN`, `ATX`, `XTA`
    *   Register manipulation: `ALN`, `ATX`, `FLDA`, `FSTA`, `XTA`
    *   Set single-word addressing mode base address: `BASE`
*   Use 15-bit (double-word) addresses directly in FPP instructions, rather than the [PDP-8's memory model][mm8]

If you see any of those instructions in a PDP-8 assembly language program, it's a pretty good indicator that it's meant to be assembled by RALF or [FLAP](#flap).


#### Relocatable Code
315
316
317
318
319
320
321


322

323
324
325
326
327
328

329
330
331
332
333
334
335
336
337
338

339
340
341
342

343
344
345
346

347
348
349
350
351
352
353
315
316
317
318
319
320
321
322
323

324
325
326
327



328
329
330
331
332
333
334
335
336
337

338
339
340
341

342
343
344
345

346
347
348
349
350
351
352
353







+
+
-
+



-
-
-
+









-
+



-
+



-
+








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:
    *   Multiplication is `*` rather than `^`; this is possible because RALF offers the `ORG` pseudo-op to set the location counter, where PAL family assemblers use `*`
    *   Division is `/` rather than `%`, achieved by requiring whitespace before `/` if used to start a comment and disallowing spaces in expressions
*   Many new and changed pseudo-ops:
    *   `ADDR`: define address constant
    *   `E` and `F`: define floating-point constants
    *   Conditional assembly additions relative to PAL8: `IFPOS`, `IFNEG`, `IFSW`, `IFNSW`, `IFFLAP`, `IFRALF`
    *   `IFPOS`, `IFNEG`, `IFSW`, `IFNSW`, `IFFLAP`, and `IFRALF` conditional assembly pseudo-ops
    *   `IFREF`: replaces `IFDEF` pseudo-op, having a superset of its functionality
    *   `LISTOF`/`LISTON`: stop and start listing output rather than the PAL family's `XLIST` pseudo-op
    *   `REPEAT`: assemble the following line multiple times
    *   `ADDR`: define address constant
    *   `E` and `F`: define floating-point constants
    *   FORTRAN IV feature support: `COMMON`, `COMMZ`, `ENTRY`, `EXTERN`, `FIELD1`, `SECT`, `SECT8`
    *   `COMMON`, `COMMZ`, `ENTRY`, `EXTERN`, `FIELD1`, `SECT`, and `SECT8` pseudo-ops to support FORTRAN IV code

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


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

[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.
The primary advantage FLAP has over RALF is that, because it is difficult to ascribe meaning to the "page" concept in relocatable assembler output, 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 both simpler and less powerful than the RALF/FRTS dynamic overlay 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.
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`, rather than by the relocating loader used by RALF, `LOAD.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 both simpler and less powerful than the RALF/FRTS dynamic overlay 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 present on the OS/8 source media we're using, but we don't know if this is because it was removed from OS/8 by DEC or if we simply missed the FLAP source media when curating the input media we use for building our OS/8 disk packs. When we figure that out, I'll update this article.

There is a `FLAP.SAV` program on the PiDP-8/I project's TSS/8 boot media, but we have not yet spent the time to figure out how to make it work. None of the TSS/8 manuals we have access to talk about FLAP, so this is not likely to be a quick project.
There is a `FLAP.SAV` program on the PiDP-8/I project's TSS/8 boot media, but we have not yet spent the time to figure out how to make it work. None of the TSS/8 manuals we have access to talk about FLAP, so this is not likely to be a quick investigation.

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](#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.