PDP 11/40 SYSTEM The new system is based on a message pasing scheme. A message consists of four words, the first of which holds the routing information, both for the message and any reply. The remaining three words are used for passing parameters. In IMP it is expressed as follows:- %RECORD %FORMAT PF(%BYTEINTEGER SERVICE, REPLY, %C %INTEGER A1, A2, A3) Three routines are provided in 'PERM' to send and receive messages, they are accessed as follows:- %PERMROUTINESPEC PON(%RECORD (PF) %NAME P); ! send a message %PERMROUTINESPEC POFF(%RECORD (PF) %NAME P); ! wait for a reply %PERMROUTINESPEC SVC(%RECORD (PF) %NAME P); ! send and wait NOTE: IMP as implemented by Peter Robertson is different from EMAS IMP in its syntax in RECORD specification. These routines copy the record. The KERNAL maintains lists of messages waiting to be processed. The KERNAL also holds a list, mapping service numbers to task identifiers. A TASK is normally allocated the same service number as its own identifier and it is possible to obtain others. The rest of the KERNAL consists of 1) CPU scheduler, 2) CORE allocate/return routines and 3) a CLOCK handler. All other functions in the system are provided by 'system' tasks, running in USER mode. Interrupts are taken in KERNAL mode, and are passed up to the owning task via the message passing mechanism. The task would then deal
with the interrupt in USER mode. This strategy will work for most devices, but for some extremely time critical ones it will make sense to handle them partially in the KERNAL, or in other words a 'software' interrupt interface is used. All TASKS on the system run in a virtual memory environment, ensuring that tasks cannot overwrite either other tasks or the system itself. In general a full 32k word virtual memory is available for each task, but certain segments (a 4k area) is normally used to contain shared material ie PERM (with read only access). A swopping strategy (to and from the disc) will be employed if the real core becomes overallocated. A task communicates with other tasks only via the PON/POFF mechanism (system tasks are allowed to access the device registers directly), consequently all interfaces will be expressed in message terms. devices RK05: The DISCS are handled by two tasks, the first one organises the transfer of data toand from core (in blocks of 256 words), see APPENDIX ONE for the definition of the interface. The second task handles the file structure on the discs, allowing files to be created, destroyed, extended etc (see APPENDIX TWO). TERMINALS: Each console device is handled by a task (whick will share common code), calls are provided to read, write and prompt on
the device. See APPENDIX THREE for details. There is also a COMMAND LANGUAGE INTERPRETER task associated with each console, to run and otherwise control programs, though it may be omitted if the terminal is only going to be used for 'simple' I/O. TU16 (MAGTAPE): A task will interface this device to the system, a preliminary specification of the interface is given in APPENDIX FOUR, but the full details of error replies may have to change in the light of experience. DQS11E (SDLC HARDWARE): One task will be used to handle data transfers on the line, a second task will interface to it and control the SDLC protocol (ie retries after errors etc). CARD READER, LINE PRINTER etc: One task will look after each device, using a subset of the terminal interface to drive it. Normally there will also be a spooling program to organise the queuing of files. node communication All communication with the NODE will be spooled. A task will be written that 1) Searches the DISC DIRECTORY for files of a particular
type of name, on finding one, it will either send it to the NODE, or use it as the basis for instructions to send other files to the NODE (this second form may not be necessary). 2) On receipt of a file from the NODE, it will transfer it to the DISC giving it a name of a particular type. These files on disc will then be interrogated by a series of programs, on to each device (ie line printer, graph plotter, or operator teletype). These programs will ask to be kicked by the clock on a regular basis (say one minute) and will interrogate the DISC DIRECTORY to see if anything has arrived. When a file arrives, it will then be RENAMED and dealt with. When all the files have been read, the program will go back to sleep. operator communication with the node A teletype will be reserved for use by the operators. A program will read a line from it, put it in a file and RENAME it for automatic transmission. The reply is put in a file and then could be either typed on the console or printed on the line printer. sending magnetic tapes to the node After discussion with Bill Gordan, it would seem that 99.9% of all tapes would easily fit on the disc (29,000 full card images), the sensible scheme would then seem to be to treat it like the card reader, ie spool it onto the disc for automatic transmission. A seperate program could be held (and run overnight say) to handle the exceptions,
but it should be pointed out that files of that length ( >29,000 card images) could well have trouble reaching their destination due to the long time required to transmit them.
appendix one rk05 (disc) handler interface SERVICE = 3 A1 = 0 - READ a block A1 = 1 - WRITE a block. A2 = (virtual) TRANSFER ADDRESS. A3 = BLOCK NUMBER ON REPLY:- A1 = 0 Transfer successful. = 1 Virtual segment too short/non existent = 2 Command wrong. = 3 DISC fault - additional information:- A2 = ERROR REGISTER, A3 = STATUS REGISTER.
appendix two directory handler interface SERVICE = 4 A1 = 0 EXAMINE FILE = 1 GET NEXT BLOCK NUMBER. = 2 DESTROY FILE. = 3 CREATE FILE. = 4 APPEND BLOCK TO FILE. = 5 RENAME FILE. = 6 RENAME IMP TEMP OUTPUT FILE. A2 = (virtual) address of name descriptor A3 = other information:- A) GET NEXT - previous block. B) APPEND - previous block. C) RENAME - (virtual) pointer to 'new' file name.
appendix three terminal handler interface SERVICE = 1 (main terminal) A1 = 0 READ request. = 1 WRITE request. = 2 CLI read request = 3 PROMPT. A2 = (virtual) address of buffer. A3 = length of data (for calls 1 and 3). ON REPLY:- READ REPLY - A1 = no of chars read (0 is end-of-file) WRITE REPLY - A1 = 0 implies an error There is no PROMPT reply.
appendix four tu16 (magtape) handler SERVICE = 6 A1 = COMMAND (see below). A2 = (virtual) address of buffer (on READ and WRITE). A3 = length of data/supplementary info. ON REPLY:- A1 = 0 indicates success, otherwise a fault Other parameter values will depend on each command COMMANDS 0 no operation. 1 rewind off line. 2 rewind. 3 drive clear (reset device). 4 erase. 5 write tape mark. 6 space forward (A3 = no of blocks). 7 space reverse (A3 = no of blocks). 8 write check forward. 9 write check reverse. 10 write forward (A3 = no of words). 11 read forward (on reply A1=NUMBER of bytes actually read).