The format of these files revolves around the notion of a common header that is prepended to each file ending with the .pom or .pdp suffix.
The purpose of the header is to structure what follows so that programs can access parts of file quickly. A secondary consideration is in the identity of what follows as being really a proper object file.
The format of the header is given below in the implementation language C. A word object is a 16-bit quantity, with a u_word the same size but unsigned.
struct exec {
word a_magic; /* magic number */
u_word a_text; /* size of text segment */
u_word a_syms; /* size of symbol table */
u_word a_norel; /* relocation info stripped
off (by the linker) */
};
The a_magic field identifies the file as being a PDP-11 object module. If the number is not a pre-defined magic number, then an error results when programs attempt to read the rest.
The a_text field gives the size of the resulting text and relocation tables present in bytes.
The a_syms field gives the size of the symbol table in bytes. The number of actual symbols present is obtained by dividing this number by the size of a single symbol object ``sizeof(struct nlist)''. The symbol table is carried around in all object modules; there is no way to get rid of it. The C definition of a symbol table type is given as:
struct nlist {
char n_name[8]; /* name of symbol */
word n_type; /* its type */
u_word n_value; /* its value */
};
At present, because of NULL termination, the number of bytes left for user defined symbol names is 7 characters per symbol. In the future this may be increased using a flex-names approach and adding an extra table to the very end of an object module (the string table). Names under this approach may be arbitrary in length.
The a_norel flag signifies that the relocation table is not present. If the value of this flag is 0 then a relocation table is right after the text table.
The format of .pdp files is illustrated below. The size of each segment is in emphasized typeface. All segments are contiguous in that there is never any padding required to round them up to some size. Since the nature of the file is in a simulation type environment, making the sizes of the segments some size other than their actual size is unnecessary.
1#1