USER MANUAL FOR DEIMOS AN OPERATING SYSTEM FOR THE PDP 11 B. GILMORE AUGUST 1976 REVISED MAY 1978
CONTENTS TITLE PAGE General features 3 System commands. 7 General Purpose Programmes The EDITOR. 10 The IMP compiler. 11 The LINKER. 12 Library manipulation. 14 The debugging program. 15 System Fault Messages. 19
GENERAL FEATURES Design Aims DEIMOS was designed for operation in a medium sized PDP 11. At least 16k words of core, a memory management unit, a disc or similar fast mass storage device, a terminal and a clock are required. The system was designed with six main aims: Running user programs The system is designed to run general user programs. Normally, about twenty simultaneous programs are supported, but this figure is a parameter at system generation. Each program runs in its own virtual memory environment (VM), not necessarily limited to the hardware's mapping limit of 32k words. The system, and other user programs, should be fully protected from the failure of a user program. Multiple terminal support The system supports multiple terminals, each terminal can, optionally, be linked to a command language interpreter which will enable the user to initiate and control programs from the terminal. Peripheral support The system supports a wide range of peripherals, eg, line printer, card reader, paper tape reader and punch, various discs, magnetic tape, graph plotter, asynchronous communication lines and a synchronous communication line running under the HDLC protocol. New peripherals can be added with minimum disturbance to the rest of the system. Self Supporting The system is self supporting on a medium core configuration (approx 28k words). This size is required in order to run the compiler Swapping The number and size of user programs is currently limited to the physical store size of the machine, a limited swapping strategy will be implemented to support a virtual store size of two to three times the physical store size. Minimal resident section The size of the resident system is kept small to allow as much store as possible for user programs. Constraints The resident part of the system has been kept reasonably small to enable the system to run in smaller core configurations. This constraint effects the overall design, distinguishing it from systems with a large set of facilities like UNIX and RSX11D which require at least 48k words of core to do useful work.
Structural Overview The system is based on the concept of a number of tasks, each of which manages either a resource or a user program, which commnnicate and synchronise with each other using 'messages'. The concept of messages comes from EMAS, the GEC 4080 and others. The user interface is heavily influenced by a number of machines running in the Computer Science department. The system has two main sections, a resident section and a potentially swappable section. The resident section consists of a kernel and the mass storage device handler which runs as an otherwise standard system task. The kernel provides the following services: 1) Controls the CPU allocation. 2) Passes interrupts to their device handlers. 3) Passes messages between tasks, storing them if necessary. 4) Supports the virtual memories, including mapping between them. 5) Provides clock and timer functions. 6) Controls core allocation control. All peripherals and other system functions, e. g., the file storage handler, command language interpreter and loader - are handled by system tasks. The system tasks are 'privileged', this entitles them to access parts of the real machine and other tasks. A new task is created when a user program is run and is deleted on its termination. A task consists of a virtual memory environment and a 'task descriptor block', held within the kernel. A task on this system does not have a 'task monitor'; all interrupts and messages are processed by the task in its 'user' state. The virtual memory environment of a task consists of a number of segments, these segments are used to hold the program code, data areas and shared system code. The hardware of the PDP11 allows eight segments to be mapped onto real store at any given time, giving a virtual memory address space of 32k words. The number of segments owned by a task is not limited to eight. A segment may be mapped in a read only or a read/write mode which allows protection of code areas. The 'task descriptor block' contains the registers (when the task is not actually executing) and other information such as the state, priority level and message queue that constitutes the context of the task. The list of segments used by all tasks is held in a GLOBAL SEGMENT TABLE within the kernel, with the core or disc address, access permission and the number of tasks using the segment. This table enables the kernel to maintain control over the usage of segments and can easily determine what parts of tasks may be swapped out. The core address, access permission and a pointer into the global segment table are also maintained within the task descriptor to optimise the context switch. If a task fails with either a hardware fault (eg, an address error or memory protection violation), or with a fault detected by software(eg. an
illegal supervisor call or message), the kernel generates a message to a 'system error task'; to allow later investigation the failed task is prevented from continuing. The 'error task' informs the user of the task failure and the reason for it. The 'error task' is also used by some system tasks to inform the operator about the state of devices. All communication in the system is done by sending messages. These messages are queued by the kernel, if necessary, until they are requested. Interrupts are handled similarly, the kernel generates and queues a message for the appropriate task. A table is used to determine which task a message (or interrupt) is for. A supervisor call is provided to enable tasks to 'link' thenselves to a particular message number. This is slightly less efficient than direct ownership but enables device handlers to be configured into the system dynamically. The address of a data area may be passed by a message. The segment containing this area may then be mapped from the callers VM to the receivers VM. Currently this mechanism is only used to share segments, which are eventually returned to the caller. There is no restriction to stop segments actually being transferred by this method. Input/output on this system uses a separate segment in each user's task to hold its I/O buffers. This will allow the kernel to swap the major part of a task whilest slow I/O is in progress. The sharing of segments, as described above, is used by the device handlers to process the buffers, the segment being released and a reply sent on completion. Implementation This system was written in IMP. IMP was chosen for a variety of reasons: 1) a deliberate decision was made to write the system in a high level language for ease of expansion and maintainability. 2) IMP is a proven systems implementation language, for example it was used to write both the System Four and 2900 versions of EMAS. 3) A new implementation of IMP was available on the PDP11, that was of a high enough standard to consider using it for systems implementation. Two modules of the system have been written in assembler. The first module is at the lowest level of the system, loading up the registers on context switching. Since there are no explicit register manipulations in IMP, it forced this module to be in assembler. The second assembler module provides the run time support for IMP programs. This module could probably be converted to IMP later, but was written in assembler for bootstrapping reasons. Fortunately, these two sections are changed infrequently as they have proved to be a disproportionate source of problems in relation to their size. The rest of the system consists of six IMP modules, comprising the kernel and the system tasks. These modules are compiled separately and then 'linked' by a purpose built linker which also sets up the bootstrapping area. Application programs, with the exception of the editor - which was brought from the previous system - have been written in IMP. The sources are held and compiled on the system.
Operation The first system, operational since May 1976, is used for a large spooling RJE system with the usual peripherals plus a magnetic tape drive and a graph plotter. The second system, also operational in May 1976, is part of ERTE (Edinburgh Remote Terminal Emulation - see ???). The third system, on a PDP 11/34 used as the front end for the ERCC 2970 running EMAS became operational in December 1977; the fourth and fifth systems are used part time as the drivers for an interactive benchmark of two ICL 2900s running VME/K and.vme/k. At this stage swopping has still to be implemented, though most of the necessary kernel features are already present.
SYSTEM COMMANDS All commands given to the system are interpreted by the command language interpreter (CLI). The CLI indicates its readiness to accept a command by typing the prompt '>' and '<' overlaid. If a program is running, the CLI can be invoked by typing <escape>, the command prompt should then appear. The input to the CLI has two forms, either:- A) A FILE NAME, followed by 'stream definitions' or B) A COMMAND VERB, possibly followed by parameters a) a file name If a FILE NAME is specified, that file is loaded and the program contained in it is entered. If the file does not exist, or does not contain a program, the message '*NO FRED', where FRED is the name of the file, is output and the command prompt is re-issued. The 'stream definitions' are input in the form:- <input 1>,<input 2>,<input 3>/<output 1>,<output 2>,<output 3> <input 1> etc, each represent a 'stream definition'. A 'stream definition' is of the form:- .TT - which is either input or output from a terminal. .LP - output to a line printer <any other devices on the system, specified in the same way.> <a FILE DEFINITION> A FILE DEFINITION is in the form:- <unit number>.<file name>(<file system number>) The <unit number>, a digit in the range '0' to '4', and refers to the physical disc drive. If neither is specified, '0' is assumed. The <file name> consists of an alphanumeric string, which must be preceeded by a letter, of up to 6 characters in length The <file system number> is the file system that the file comes from, or is created in. If none is specified, the users own is used (see the command LOGON) eg FRED - the file called FRED on unit 0 in the users file system. 0.FRED - the same. 1.FRED - The file FRED is taken from disc unit one. FRED(0) - the file FRED from file sys. zero (the systems own one) 1.FRED(25)- the file FRED from disc unit one and file system 25 (octal). .TT - the terminal, input if on the left hand side, output if on the right hand side. The stream definitions are linked into the input and output streams available to an IMP program, for example, if the program FRED is run with
the following command:- FRED F1,F2/O1,O2,.TT then input stream one, used by calling 'SELECT INPUT(1)' is mapped to the file 'F1'. A 'SELECT OUTPUT(2)' will send output to the file O2', and 'SELECT OUTPUT(3)' will send the output to the terminal. If a field is left blank, as with <input 3> in the above example, the stream is mapped to 'NULL' - which causes an 'end of file' signal on input and on output, all the output is thrown away. Input stream zero and output stream zero are always mapped to the users terminal. FURTHER EXAMPLES PROG .TT - uses one input stream '.TT', no output stream (apart from zero) is defined. PROG FILE - will read from a file called FILE on stream one. PROG /FILE - no input streams defined (apart from zero), will write to a file called FILE after a 'SELECT OUTPUT(1)'. PROG FILE/FILE - this will read data from a file called FILE and create an output file called file NOTE: When a program does the first 'SELECT OUTPUT(N)', where a file is mapped to that stream, the system will create a temporary file (FILE# in the previous example). When the program stops, or calls 'CLOSE OUTPUT', the original file (FILE) is destroyed and the temporary file (FILE#) RENAMED to that name (FILE). b) a command verb There are currently seven available system commands, they are:- a) LOGON - used to 'logon' to a file system. b) TASKS - List the running programs on the system. c) HOLD - Stop a task executing. d) FREE - Release a 'HELD' task. e) KILL - Stop a program in a controlled manner. f) PURGE - Immediately remove a task from the system. g) ABORT - Used to abort a device handler transfer. a) logon This command is called in the form: LOGON nn where 'nn' is a two digit octal number, representing the users file system number.
b) tasks This command has no parameters, it lists out the tasks on the system in the form:- <task name> <task number> <task state> The states of a task are as follows:- STATE MEANING 000001 Task is in the WAIT state. 000002 Task has executed a 'POFF'. 000010 Task is on a CPU QUEUE awaiting execution. 000020 The task is in the 'RUN' state. 000200 The task has been 'HELD'. c) hold This command is called in the form: HOLD xxxx where 'xxxx' represents the name of a task running on the system. If the task is currently executing, it is suspended. If the task is waiting for a message, it will be suspended when it next requests the CPU. d) free This command is the converse of HOLD and is called: FREE xxxx it places the task 'xxxx' back on the CPU. e) kill This command is called in the form: KILL xxxx it has the effect of sending the task called 'xxxx' a message to stop, the task should then stop in a controlled manner tidying up all its streams. f) purge This command is called in the form: PURGE xxxx it has an immediate effect, completely removing the task from the system, no attempt is made to tidy the open streams. This command should not normally be used to stop a program, but MUST be used to clear a program from the system that has crashed with an 'ADDRESS ERROR' or a 'SEG FAULT'. NOTE: If a program is still running, HOLD must be called before either KILL or PURGE is used. g) abort This command is used in the form: ABORT xxxx The command is used when a device handler has attempted a transfer which fails, eg the disc handler has a 'hard' checksum error, or is attempting to access a non-existent drive. The effect of the command is to instruct the device handler to pass a failure flag back to the task which called it - this will produce different effects depending on who sent the original message, ie if a user program is attempting a transfer of a block to the
disc, it will stop with a FAULT 27.
THE EDITOR The EDITOR is a PDP11 version of the COMPATIBLE CONTEXT EDITOR. For general information on the Editor, see the USER GUIDE of the COMPATIBLE CONTEXT EDITOR by H Dewar. The command for calling the Editor has four possible forms as illustrated below: E /TEST - to produce a new file called TEST. E TEST - to edit an existing file called TEST E TEST/TEST2 - to produce a new file called TEST2 from an existing file called TEST. E TEST/.TT - used to examine, without modification, the file TEST. NOTES 1) The Editor prompts '>' when it is ready to accept a command and ':' when it expects a line of input (COMMAND: GET). 2) This version of the Editor uses a 'window' of the file, this will not normally be apparent, but it does mean that the command 'M-*' will not necessarily return right to the top of the file. WARNING If you wish to abnormally terminate the Editor, always use the command 'PURGE' rather than 'KILL'. For example, if you are editing a file to itself as in example two above, a KILL will delete the file TEST, and replace it with the temporary editor file which may well be empty.
RUNNING THE IMP COMPILER The IMP compiler is a three pass compiler to which a fourth pass, a LINKING phase, is automatically called for %BEGIN .. %ENDOFPROGRAM programs There are four main ways of calling it:- IMP A/B - which compiles source file 'A' to object 'B' IMP A/,L - which only does one pass and creates a listing file 'L' (note: 'L' can be either a filename, '.TT' or '.LP'). IMP A/B,L - which creates both an object file and a listing file. IMP A,.TT/B - this form is used to change the LINKER defaults, for more details of the defaults, see the section on the LINKER. NOTES 1) At present, an external routine file will cause a 'FAULT 100' on exit from the third pass which inhibits the entry to the linker. The object file in this case is always called 'OY'. 2) The test compiler is accessed by running the program 'NIMP'. 3) The first pass automatically uses a file of '%SPECS' called 'PRIMS' which is taken from the system file system. 4) The first pass creates a temporary output file 'O' for use with the econd pass. The second pass creates 'O2' and 'O3' and the third pass 'OY'. 5) The output from the third pass 'OY' is useful. It can be used as input to the programs 'RECODE' and 'VIEW' if it is necessary to de-compile the compiler output. If the linker is to be run as a seperate 4th pass, the file 'OY' is used as its input.
THE LINKER The LINKER is normally run automatically as a fourth pass to the IMP compiler. It is run individually by typing one of the four following forms of command to the COMMAND LANGUAGE INTERPRETER. LINK A/B or LINK A,.TT/B or LINK A/B,C or LINK A,.TT/B,C Both of the above commands take the file 'A', which must be the output from the third pass of the compiler and create a runnable file 'B'. The second form of the command overrides the standard LINKER defaults, the LINKER prompts for the new data as follows (defaults in brackets):- NAME: - up to 4 characters are typed in as the TASK NAME for the program (the first four characters of the object file name are used). STACK: - the desired stack size (in octal bytes), excluding the GLA (default: 14000). STREAMS: - the max number of input and output streams that the program is going to use, excluding INPUT and OUTPUT (0) (default: 3). If a program has external references in it, the LINKER will first attempt to satisfy then using 'LIB000' in the users file system. If there are still unsatisfied references, the LINKER will look at 'LIB000' in file system zero (the system file system). For more information on LIBRARIES, see the section on them. If the optional second output parameter is specified, a link map (see example below) is output to it. In the above examples this would be in a file called C. .TT or .LP could also be specified. Sample LINKER Output Map CODE: 040000 GLA: 140020 XREF:PON POFF PONOFF MAPVIRT XDEF: 040000 #GO FILE:SHARED CODE: 046506 GLA: 140752 XREF: 004000 RUN XDEF: 022656 PON XDEF: 022700 POFF XDEF: 022736 MAPVIRT XDEF: 023006 MAPABS TOTALS: CODE = 006506 GLA/STACK = 002016 The TASK NAME of the program (TEST) is printed along with the base address for its code (040000) and its GLA (140020). The 'XREF' refers to 'external references' from that section of code (in this case they are all declared by the system). The 'XDEF' is an 'external definition', in this case '#GO' which is the entry point for the main program.
The 'FILE:' indicates that the LINKER has loaded an object file , it specifies its name (SHARED) and the start address of its code (046506) and GLA (140752) sections. The list beneath that is the 'external definitions', in this case entry points that the file contains. The last line gives the overall code length of the program (006506) and the total size of the GLA and the declared stack. If any references are left undeclared, the LINKER will list them along with an 'UNDEFINED REFERENCE' message. If the LINKER attempts to load a file that contains an entry point that has already been loaded, the message '*DOUBLE DEF' is output and the LINKER stops.
LIBRARY MANIPULATION When the LINKER finds an EXTERNAL REFERENCE in a program file it will attempt to satisfy the reference by:- 1) Searching the library 'LIB000' in the USER file system, loading object files as necessary, then 2) Searching the library 'LIB000' in the SYSTEM file system (zero). There are three programs currently available to the user to manipulate libraries, they are:- 1) NEWLIB - creates a new library file. 2) INSERT - Inserts the entries of an object file into a library. 3) INDEX - lists the contents of a library. NOTE: Each of the programs will manipulate libraries other than 'LIB000', but at present the LINKER will not link them. 1) newlib The command for using NEWLIB is as follows:- NEWLIB /LIB This command will create a new library file 'LIB', if it already exists the old copy is destroyrd. 2) insert There are two main forms of this command as follows: INSERT TESTY,LIB/LIB and INSERT TESTY,LIB/LIB2 The first command will add the entries of the file called TESTY into the library called LIB. The second command will add the contents of the file called TESTY into the library called LIB, creating a new library called LIB2. 3) index The form of this command is as follows:- INDEX LIB This command will print out all the entries in the library file 'LIB'
COMPILER LISTINGS WITH CODE ADDRESSES A program called ALIST is available to generate an IMP listing along with the address of the generated code. It can either be run using the output from the third pass of the compiler (File OY) or by using the final object program which is usually more convenient. example: ALIST TESTS,TEST/L which takes the source file 'TESTS', is associated object file 'TEST' and creates the listing in file 'L'. It is of course possible to specify tt or lp instead of file 'L'.
CHECKING THE COMPILED OBJECT CODE A program called 'RECODE' exists to take either the output from the 3rd pass of the compiler, or the final object program and recode it back into assembler and merge it with the source program. example: RECODE TESTS,TEST/L which takes the source file 'TESTS', is associated object file 'TEST', and creates the listing in file 'L'. It is of course possible to specify tt or lp instead of file 'L'.
TRANSFER PROGRAM A program called 'T' exists to allow source or object files to be copied from file to file, device to file, file to device, or device to device. It can also be used to concatenate two files by specifying a second input parameter. example: T FRED/2.FRED(20) - copies the file 'FRED' on disc drive 0 - users current file system, to file system 20 on disc unit 2 T FRED/.LP - lists file 'FRED' on the line printer T pr/fred - transfers a file from the paper tape reader to file 'FRED' T FRED,JIM(21)/FRED - takes the file 'FRED' and appends the file 'JIM' on file system 20 on to the end of it T tt/fred - reads a 'file' from the terminal and creates a file 'FRED'. To terminate the transfer, it is necessary to 'HOLD' and then 'KILL' T. NB: The preferred way is to use the editor.
FILE SYSTEM INTERROGATOR A file system interrogator program called F exists to enable a user to examine the contents of directories it has the following facilities:- A : Lists all files in the current directory along with the start block, protect code and number of blocks in the file. B Filename : Gives data for specific file as in A. C : Get current L values D Filename : Delete file, D ? lists all files and requests Y to delete, N to keep, unless answer to automatic request is 'Y'. F : Lists filenames in current directory G Filename : Search all directories for file L X,YY : Alter current directory to disc X, and file system YY(octal).L CR returns to current logon. R ; Rename file, prompts for old and new filenames. S : Stop T Filename : Transfer file, prompts for destination disc, FSYS or tt or lp. U : Lists all files for all users The program assumes the current logon file system on disc 0 on entry, A ? in a file name means do the command to all files starting with letters up to the ?. Unwanted output can be interrupted by sending A to task 'F' using the INT mechanism. example: INT A F
Magnetic Tape Support Currently the system supports a TU16 controller and tape drive, which enables either 800bpi or 16bpi tapes to be read or written. The older version of tape drive (TU10) is not currently supported, although it is reasonably similar to the TU16 and hence would not be a major job to implement. The following general purpose programs exist to use the TU16. ARCHDK - archives a complete RK05 disc pack to 1600 bpi tape in 4K word blocks. RESTDK - restores tapes written by ARCHDK. START - standard labelled Tape Archive and Restore. STAN - standard labelled Tape Analysis. TAUL - Tape Analysis for unlabelled tapes. INSL - standard Tape labeller. Note: In systems where the page device handler (TU167) is not loaded by the system initialisation program LOADUP, it is necessary to 'RUN TU167' before running a tape program. A description or a reference for each program follows.
ARCHDK This program prompts: DRIVE? when it is loaded. The user then types in the unit number of the drive to be archived and the program will then write the entire contents of the disc up to tape sector by sector in 4K blocks. An entire RK05 disc takes approximately 45 seconds. The existing program writes the tape at 1600 bpi but it is a simple modification to change this to 800 bpi. In systems where there is a double density pack and the system treats both 'units' as one unit, the entire disc i.e. 5.4Mb is written to Tape. The program is run by typing: ARCHDK (carriage return) in response to the system prompt.
RESTDK This program takes a tape with a disc image written by ARCHDK and transfers the tape contents back onto a RK05 pack. When the program is loaded it prompts: DRIVE? and the user responds with the drive number that contains the disc pack to be overwritten. As a sensible precaution the user is advised to 'write protect' all other drives. The program then asks for confirmation, thus: CONFIRMATION? If any reply other than 'Y(carriage return)' is given the program stops.
STAR - Standard labelled Tape Archive and Restore This program is generally used to create archives from disc to tape. It creates a standard IBM labelled tape and files are written to, and read from, it. For full documentation see the document by C. McArthur (ERCC) 11.AUGUST.76. STAN - Standard Labelled Tape Analysis This is an interactive tape analysis program driven by commands from a console or a file, bytes of data on the tape can be identified and dumped on the printer. For full documentation see the document by C. McArthur (ERCC) 4.OCT.76. TAUL - Tape Analysis for Unlabelled Tapes This program is the same as STAN, but no assumptions are made about the format. See document by C. McArthur (ERCC) 19.AUGUST.76. INSL - Standard Tape Labeller This program is used to create (or overwrite an old) a standard IBM label in a magnetic tape. See the document by C.D. McArthur (ERCC) ?
DEBUGGING PROGRAM OBJECT: DBUG This program is used as an aid to debugging programs, it will mormally be 'linked' to a running program on the system using the command 'T' (for details see later), all accesses to locations will then be made in that programs virtual memory. It may be used to:- 1) SET and CLEAR breakpoints 2) Dump out the PSECT, REGISTERS and/or the IMP STACK. 3) EXAMINE and CHANGE locations in core. 4) DUMP general areas of core. DEBUG indicates its readiness to accept commands by typing 'DEBUG:'. The following commands may be used. T - Set Task number of program to be debugged. B - Set breakpoint. C - Clear breakpoint. N - Set a new program code base. R - Dump the REGISTERS. P - Dump the PSECT. I - Dump the IMP stack. A - Do 'P', 'R', and 'I'. D - Dump an area of core. O - Change the output device. W - WAIT DEBUG. S - Stop DEBUG. ? - Print options. In addition to these commands, there is an implied command, activated by typing an octal digit, that enters the location examination/change part of DEBUG. A detailed description of each command follows. T - SET TASK NUMBER The prompt 'TASK ID:' is output and the (octal) ID of the program to be debugged should be entered. The TASK ID of a running program may be obtained by typing the command 'TASKS' to the command language interpreter. NOTE: Only the commands 'T', 'N', 'O', 'S' and 'W' may be used before 'T' is used for the first time.
B - SET BREAKPOINT The prompt 'ADDR:' is output, the reply is the RELATIVE address (wrt the start of the program) of the desired breakpoint. Debug will remember the contents and place a 'BR ' in the location. This will cause the program to loop when it executes that instruction. Debug replies: BP: n ADDR: n2 CONT= n3 - where 'n' is the breakpoint number (between 0 and 20), 'n2' is the virtual address, and 'n3' the original contents. The message 'BP TABLE FULL' is output if more than 21 breakpoints are used. See the command 'N' for setting breakpoints in external routines. C - CLEAR BREAKPOINTS Prompts 'NO?'. The breakpoint number should be typed. 'A' or '-1' is typed if ALL the breakpoints are to be cleared. If the specific breakpoint has not been set, the message '?' is output. The original contents are replaced. N - SET A NEW PROGRAM CODE BASE Prompts 'NEW PROGRAM CODE:'. Reply giving the new address. This command is useful for programs using external routines. To set a breakpoint in an external routine, the code base is set to that of the external routine, as printed out by the LINKER, and the relative address specified. This does not effect any previously set breakpoints. R - PRINT REGISTERS. This command prints the registers of the nominated task. The LOCAL NAME BASE (LNB) for the outer level is also printed.
P - PRINT THE PSECT The PSECT (own system variables) of the nominated task is printed. The command :- 1) Prints the name of the task 2) Prints the state of the task. 3) Indicates whether there are messages queued. 4) Calls 'REGISTERS' to dump the registers out. 5) Prints the contents of the segmentation registers in the form:- <REGISTER NUMBER> <ADDRESS> <LENGTH> <ACCESS> I - PRINT THE IMP STACK The entire IMP STACK is printed on the output device. NOTE: The GLA of the program is held at the low address end of the stack, the IMP stack (ie the SP stack) starts at the high address end and works towards the low address end. is not the same as the start of the stack. A - PRINT ALL The command executes a print psect (P), print registers (R) and the IMP stack (I). This command is useful for dumping all the relevant information about a program onto the line printer (see command 'O'). D - DUMP AN AREA OF CORE Prompts 'FROM:' and 'LENGTH:'. Both numbers should be typed in octal and the area of core from 'FROM' to 'FROM+LENGTH' is output. NOTE: 1) On all the dumps 'ZEROES' is ouput if one or more entire line contains zero. 2) An ISO equivalent is printed on the RHS of the dump. O - CHANGE THE OUTPUT DEVICE Prompts 'STREAM:'. The reply is used in the form 'SELECT OUTPUT(N)' for the output of commands R,P,I,A and D. By calling 'DBUG' in the form:- DBUG /L or DBUG /.LP etc the output may be directed to the file 'L' or to the line printer.
W - WAIT DEBUG This command is used to suspend DEBUG if it is necessary to input to a program on the same teletype. It is restarted by (ESCAPE) FREE DBUG S - STOP DEBUG Debug halts. Note: all breakpoints are cleared. IMPLIED COMMAND TO EXAMINE/CHANGE CORE ADDRESSES This command accepts the following instructions:- Note 'N' and 'M' represent numbers input in octal. N : prints contents of N. N+C : prints contents of (N+ program base). N+I : prints contents of (N+ IMP STK base). N+RM : prints contents of (N+REGISTER M) N(+ options)=m: puts M into N eg: DEBUG:100 (cr) - will print contents of locn 100. DEBUG:100+R5 (cr) - will print contents of 100 on from reg. 5. DEBUG:100+R5=200 (cr) - ditto, except plants 200. NOTES An '*N' at the end of the command will cause the following 'N' locations to be dumped out ('N' may be negative). '+' or '+=M' may be entered as a new command, this takes the last location used and steps it up by 2 (-2 if '-' is used).
SYSTEM FAULT MESSAGES There are three main classes of fault messages output by DEIMOS, they are 1) Compiler run time messages 2) Loader error messages 3) System detected error messages. 1) Compiler run time messages. These messages are produced when the compiler run time support code detects an error. The program is stopped and the error number is returned to the task which started the program up. This task will normally be the loader and the error message is produced in the form: F A U L T n where 'n' has the following values. 'n' Meaning 1 Excess Blocks. NB: only produced inside string handling routine 2 Symbol in Data. 'READ' routine. 3 String inside out. 4 Not used 5 No switch label. 6 Capacity exceeded. Strings only. 25 An input file does not exist. 26 Syntax fault on the Input/Output definitions string. 27 Read or Write a block to the disc failed (e.g. illegal block, aborted transfer etc). 28 The Disc is full or the users directory is full. 2) Loader error messages. These messages are produced when the loader attempts to load a file and fails. The format is:- fault n where 'n' has the following meanings. 'n' Meaning 1 The free core is insufficient to load the program. 2 Format of the initial block of the program is wrong - it is too short. 3 Ditto - but is too long. 4 The checksum on a block is wrong. NB: This can also be generated when the end of a file is reached prematurely. 5 Out of Range. The program is attempting to load into a
non-existent part of its VM. 6 End of file. EOF is reached before the final binary block is seen. 7 System Full. The maximum number of tasks is already loaded. In addition the following messages are also output. ERROR MESSAGES no FRED - an attempt was made to load the file 'FRED' but it didn't exist or wasn't Binary. TASK? - a command has been issued to a Task which doesn't exist. INFORMATION MESSAGES STOPPED - a program, under the control of the loader, has stopped normally. NB. This message will only appear when this is more than one user task running in the System. When only one task is running and it stops the system prompt is issued. F A U L T n - See the earlier section. TERM REQ. - a 'KILL' has been given to a task and it has stopped. XXXX PURGED - a 'PURGE' has been issued to a TASK and has been carried out. 3) System Detected Error Messages. These messages are issued when the system notices that A TASK has misbehaved in some way. The format in each case is the same:- <TASK NAME>:<ERROR MESSAGE> The following messages are used: BAD SEGMENT a b The named task has caused a segmentation trap by writing or reading outside its virtual memory. The two octal numbers 'a' and 'b' are the value of the error register and the PC at the time of the trap. This Message is fatal, the TASK cannot run any more and should be investigated (using DEBUG) or PURGEa to remove it. ADDRESS ERROR This is the same as BAD SEGMENT, except that an address error was seen by the hardware (e.g. addressing a word on a non-word aligned boundary, or an illegal stack pointer). It is also fatal to the task.
ILLEGAL INSTRUCTION Same as above except the task attempted to execute an illegal instruction. It is also fatal to the task. ILLEGAL SVC The task has called a SVC that is not recognised by the system. It will normally be fatal. BAD SER n The task has sent a message to a non-existent process. This is not fatal, the task will continue to run but if it was expecting a reply it will never receive it. 'n' is the service number that failed. TIME FAULT The task has attempted to request the clock to kick it more than once. It is not fatal but indicates problems with the code. NOT READY! n This message is issued when a peripheral wants operator action, when this is done, a FREE or ABORT command should be sent to the task. The octal number 'n' is device dependant, but will normally contain the contents of the peripheral's error register (see the Peripheral Handbook).