Sr doc disclaimer this document file was created by scanning the original document and then editing the scanned text. As much as possible, the original text
Download 70.82 Kb.
|
1 2
| SRT8.DOC DISCLAIMER This document file was created by scanning the original document and then editing the scanned text. As much as possible, the original text format was restored. Some format changes were made to insure this document would print on current laser printers using 60 lines per page. The original spelling and grammar has been preserved. SSSSSSSSSSSS RRRRRRRRRRRR TTTTTTTTTTTTTTT 888888888 SSSSSSSSSSSS RRRRRRRRRRRR TTTTTTTTTTTTTTT 888888888 SSSSSSSSSSSS RRRRRRRRRRRR TTTTTTTTTTTTTTT 888888888 SSS RRR RRR TTT 888 888 SSS RRR RRR TTT 888 888 SSS RRR RRR TTT 888 888 SSS RRR RRR TTT 888 888 SSS RRR RRR TTT 888 888 SSS RRR RRR TTT 888 888 SSSSSSSSS RRRRRRRRRRRR TTT 888888888 SSSSSSSSS RRRRRRRRRRRR TTT 888888888 SSSSSSSSS RRRRRRRRRRRR TTT 888888888 SSS RRR RRR TTT 888 888 SSS RRR RRR TTT 888 888 SSS RRR RRR TTT 888 888 SSS RRR RRR TTT 888 888 SSS RRR RRR TTT 888 888 SSS RRR RRR TTT 888 888 SSSSSSSSSSSS RRR RRR TTT 888888888 SSSSSSSSSSSS RRR RRR TTT 888888888 SSSSSSSSSSSS RRR RRR TTT 888888888 DDDDDDDDDDDD OOOOOOOOO CCCCCCCCCCCC DDDDDDDDDDDD OOOOOOOOO CCCCCCCCCCCC DDDDDDDDDDDD OOOOOOOOO CCCCCCCCCCCC DDD DDD OOO OOO CCC DDD DDD OOO OOO CCC DDD DDD OOO OOO CCC DDD DDD OOO OOO CCC DDD DDD OOO OOO CCC DDD DDD OOO OOO CCC DDD DDD OOO OOO CCC DDD DDD OOO OOO CCC DDD DDD OOO OOO CCC DDD DDD OOO OOO CCC DDD DDD OOO OOO CCC DDD DDD OOO OOO CCC DDD DDD OOO OOO CCC DDD DDD OOO OOO CCC DDD DDD OOO OOO CCC DDDDDDDDDDDD OOOOOOOOO CCCCCCCCCCCC DDDDDDDDDDDD OOOOOOOOO CCCCCCCCCCCC DDDDDDDDDDDD OOOOOOOOO CCCCCCCCCCCC LPTSPL Version 4(137) Running on LPTl *START* User LARY,RICHARD [120,266] job SRT8 seq, 10096 Date 07-Feb-74 14:51:10 Request created: 07-Feb-74 10:50:18 Flle: DSKB0:SRT8.DOC[l20,266] Created: 07-Feb-74 10:30:00 <057> Printed: 07-Feb-74 QUEUE Switches: /PRINT:ARROW /FILE:ASCII /COPIES:3 /SPACING:l /LIMIT:302 The information in this document is subject to change without notice and should not be construed as a commitment by Digital Equipment Corporation. Digital Equipment Corporation assumes no responsibility for any errors that may appear in this manual. The Software described in this document is furnished to the purchaser under a license for use on a single computer system and can be copied (with inclusion of DIGITAL's copyright notice) only for use in such system, except as may otherwise be provided in writing by DIGITAL. Digital Equipment Corporation assumes no responsibility for the use or reliability of its software on equipment that is not supplied by DIGITAL. Copyright. (C) 1973, by Digital Equipment Corporation. SRT-8 User's Manual Page 2 Introduction What is a Real-Time System? A real-time System is a software framework under which the resources at hand (core, CPU time, peripheral devices) are divided up in a deterministic manner among Several tasks. The term "task" is difficult to define, as it overlaps with the definitions of "program" and "subroutine", but basically a task is a piece of machine code which performs a specific function, sometimes related to the outside world and sometimes related only to the needs of other tasks. The real-time system distributes resources to tasks at any time depending on whether they can make use of them, and whether a more privileged (higher priority) task wants to pre-empt them. What is SRT-8? SRT-8 is a real-time system for the family-of-8. It allows up to 64 tasks to run concurrently, competing for resources on a fixed-priority basis, included in the SRT-8 system are system tasks which control standard Digital Equipment Corporation I/O gear, a task which allows interactive system control from the console Teletype and a task which allows a single copy of the OS/8 monitor system to run in the background. SRT-8 User's Manual Page 3 Introduction What is a task under SRT-8? A task under SRT-8 Consists of the following parts: 1. A Task Number, a number from 1 to the maximum number assembled into the system (but always less than 64) which determines the task's priority (the lower the number, the higher the priority) and also serves as an index into various system tables. 2. A Task State Table entry, four words long, which is used to store the task's PC, AC, etc. when the task is not running. 3. A Task Flags table entry, one word long, which contains bits which indicate if the task can run, or why it cannot. 4. A Task input Message Queue Header, two words long, which is the beginning of the task's input message queue, all inter-task communication in SRT-8, is done via "messages" (blocks of core) sent between tasks. 5. The task coding itself, which consists of PDP-8 instructions interspersed with calls to the SRT-8 executive for services. SRT-8 User's Manual Page 4 Concepts How Do Tasks communicate? There are two main types of task communication in SRT-8 - message sending and synchronization, since synchronization is more basic, we will discuss it first. Task Synchronization and Event Flags Whenever two processes occur independently, there will be a need for one to wait on the other. The most common example of this is the PDP-8 Teletype interface. The Teletype sits there waiting for the PDP-8 to produce a character worth printing. When the PDP-8 has one, it "wakes up" the Teletype by issuing a TLS instruction. If the PDP-8 then has another character to print, it must first "go to sleep" in a TSF;JMP .-1 loop until the Teletype signals that it is finished by raising the ready flag. Then the PDP-8 "wakes up" from its loop and proceeds to print the next character. Similarly, tasks in SRT-8 may synchronize with each other by means of Event Flags. An Event Flag is a location which contains the status of an Event. An Event is anything which is important enough that you would want to keep track of it with an Event Flag (How's that for a circular definition?). Like the Teletype ready flag, an Event Flag has the states PENDING(>0) and FINISHED(<0). So, a task could (via a message) direct another task to perform some action, at which time it would set a (mutually agreed upon) Event Flag to the PENDING value. When the other task was finished it would set the Event Flag to the FINISHED value (this is known as Posting the Event Flag). If the first task had been waiting for the Event Flag with a: TAD Event Flag; SZA CLA; JMP .-2 then the Posting of the Event Flag would "wake up" the first task from its loop. Unfortunately, the above mentioned loop ties up a vitally important resource - the PDP-8 processor. Therefore, in SRT-8 (and here the analogy to the Teletype breaks down) Event Flags have a third state: WAITING(<0). In the example above, the first task would tell the SRT-8 executive it wanted to wait until the Event Flag was FINISHED - the monitor would save the task's PC and mark in its Task Flags Table word that it was waiting on an Event Flag, and set the Event Flag to the proper WAITING state (the proper WAITING state being octal 4000 plus the waiting task's Task Number). When the Event Flag is POSTed (via an SRT-8 executive call) the task which was waiting for it will automatically be "awakened" by SRT-8. The mnemonic for the SRT-8 Executive Request which waits for an event flag is WAITE. SRT-8 User's Manual Page 5 Concepts Intertask Messages Just as Event Flags in SRT-8 are analogous to hardware device flags, messages are analogous to instructions like TLS - i.e. they start up a task (provided the task was waiting for a message) and pass it information at the same time. A Message in SRT-8 is a contiguous area of core storage. SRT-8 requires the first three words of the message (the Message Header) for its use; the rest may contain any desired information. Sending a message does not physically move the message information to the receiving task, but provides the receiver with the field and address of the first data word of the message, If the receiving task is not waiting for messages, the message is placed on the receiving task's input Message Queue. Messages are queued in order of decreasing priority (increasing task number) of the Sender (and in the order issued if equal priority). The Second and third words of the Message Header are used as a CDF-address Pair to link the message to the next queue entry. The first word of the Messages Header is the Event Flag for the message. When the message is sent, the Event Flag is put in the PENDING state by the SRT-8 Executive; nothing happens to the Event Flag on receipt of the message by the receiving task, but SRT-8 protocol requires that when the receiver is done with the message he Posts the Event Flag. Note again that the information in a message is not copied into the receiver's area - this has several implications: 1. Data in a message should not be modified by the sender while the Event Flag for the message is PENDING. 2. The same message cannot be sent a second time before it's Event Flag is FINISHED from the first time. SRT-8 enforces this by checking the Message Event Flag on a SEND operation and putting the sender into Event Flag Wait if it is still PENDING. 3. It is legal for the receiving task to store information into the body of the message - in this way an "answer" to the message can be returned without going through the complications of sending a return message back to the sender. For example, when a task sends a message to the disk driver task requesting I/O, the error status of the completed operation is placed in a specific word in the message by the driver to indicate whether an error occurred. SRT-8 User's Manual Page 6 Executive Requests SRT-8 Executive Requests (E.R.s) SRT-8 tasks communicate with the SRT-8 Executive via Executive Requests (abbreviated as ERs). In order to make E.R.s simple across field boundaries, SRT-8 uses locations 20-27 in every field as a Communication region for E.R.s. The Executive is called in any field via a JMS 20 instruction (hereafter referred to as a CAL). The Data field does not have to be any specific value when the CAL is given as the code in location 20 sets the DF to the IF, sets the IF to 0 and jumps to the SRT-8 Executive. Because the architecture of the PDP-8 does not permit re-entrant programs, the SRT-8 Executive runs with task-switching inhibited - i.e. interrupts are on but higher priority tasks may not grab the CPU until the Executive has finished its Request. When the Executive finishes processing on the request it checks whether any higher priority tasks became runnable while task switching was inhibited, and if so it runs the highest priority of these. Also, because of the non-reentrant architecture of the PDP-8, the SRT-8 Executive will not honor any request to switch tasks arising from an interrupt if the interrupted task's PC was less than 100. This is done to protect location 20 in each field (the SRT-8 Executive's entry point) from being destroyed. User tasks should BE CAREFUL NEVER to execute any instructions below 100 in a field. There are 5 E.R.s associated with the Messages and Event Flags described in the last section, They are: SEND Send Message format: CAL SEND TSKNUM MESSAG This ER sends the message located at MESSAG in the current field to the task whose number is TSKNUM. If the receiving task is higher-priority than the sender, and was waiting for a message, the sender is temporarily suspended and the receiver runs. In any case, the sender is not put into any Wait state once the message is sent. As stated previously, however, if the event flag in location MESSAG is PENDING (non-zero) meaning the message is still busy from a previous SEND, the sender will be put into Event Flag Wait on location MESSAG. and only when the Event Flag becomes FINISHED (zero) will this SEND be performed. SRT-8 User's Manual Page 7 Executive Requests WAITE Wait on Event Flag format: CAL WAITE EFLG This ER checks the status of location EFLG - if it is FINISHED, control returns to the caller. If it is PENDING, its state is changed to WAITING and the calling task is put into Event Flag Wait. When location EFLG is POSTed by another task or interrupt routine, the calling task becomes runnable again. SENDW Send and wait format: CAL SENDW TSKNUM MESSAG This ER is exactly equivalent to the sequence: CAL SEND /Send the message TSKNUM MESSAG CAL WAITE MESSAG /Wait for receiver to acknowledge SRT-8 User's Manual Page 8 Executive Requests RECEIVE Receive message format: TAD RESTRICTION /Only if we want to restrict CAL /sending tasks RECEIVE MADDR, 0 /Message address-stored here /CDF to message field in AC /on return If the AC is zero when the RECEIVE ER is issued, RECEIVE works as follows: If there are messages in the calling task's Input Message Queue, the first (i.e. highest-priority) message is dequeued and the address of its first data word is placed in MADDR. A CDF to the field of the message is put in the AC. If there were no messages, the task is placed in message wait until such time as there are any. There is no ER which allows a task to check for messages without being put into Message Wait if there are none, but a task may examine its Input Message Queue Header in field 0 to find this out. If the AC is non-zero when the RECEIVE ER is issued, the calling task's input Message Queue is searched for a message whose sender's Task Number matches the contents of the AC. If such a message is found, it is removed from the queue as specified above; if none is found the issuing task is placed in Message Wait. POST Post Event Flag format: TAD EFPTR /Pointer to Event Flag CAL POST EFCDF, CDF EFFLD /Field of Event Flag The Event Flag pointed to by the AC at the CAL,in the field specified by EFCDF, is set to the FINISHED (zero) state. If its previous state was WAITING, the task which was waiting on it is cleared of its Event Flag Wait. This ER never puts the calling task in a Wait state, but if the task waiting for the Event Flag is higher priority the calling task is temporarily suspended while that one is run. SRT-8 User's Manual Page 9 Executive Requests Example This example illustrates the SRT-8 E.R.s dealing with messages and Event Flags. Since we have not discussed I/O and interrupts under SRT-8 yet, this example is trivial; i.e. there are no advantages to keeping the functions of our two tasks separate, and the whole send/receive structure is being used as an elaborate subroutine call. TASK A TASK B LOOP, CAL LOOP, CAL SEND /send B a message (4) RECEIV /get a message (1) B MADDR, 0 MES1 DCA EFCDF /save CDF for POST CAL TAD EFCDF (2) SEND /and another DCA .+1 /Put CDF inline B HLT /CDF to message MES2 / field CAL (5) TAD I MADDR /Get 1st data word (3) WAITE /Wait for first one / of message MES1 CLA /I said this was JMP LOOP /loop / trivial example! STA CLL RTL /-3 in AC MES1, ZBLOCK 3 TAD MADDR /AC points to 15 CAL / message 37 POST / event-flag 23 EFCDF, HLT /CDF to message TEXT /HIKE!/ / field here JMP LOOP /loop MES2, ZBLOCK 3 -1 4 The flow of execution in this example depends on which of the two tasks is higher priority. Assuming that at some point in time both A and B both become runnable, if task A is higher priority the sequence of execution is: 1, 2, 3, 4, 5, 1, 2, 4 (2 cannot be executed because MES2 is Still PENDING), 5, 2, 3, 4, 5, 1, 2, 4, 5, 2, 3, 4, 5, etc. if task B is higher priority the sequence is: 4, 1, 5, 4, 2, 5, 4, 3, 1, 5, 4, 2, 5, 4, 3, etc. SRT-8 User's Manual Page 10 Executive Requests Inter-task control through Task Flags Table entry A task's Task Flags Table entry is used by SRT-8 to determine if the task can run. A zero Task Flags Table entry indicates a runnable task. Each bit which is on in a non-zero word indicates a reason why the task cannot run. The currently defined bits and their meaning, if set, are: DNEWT Does Not Exist Wait - This Task cannot run because it is non-existent. MSGWT Message Wait - this task is waiting for someone to send it a message. EFWT Event Flag Wait - this task is waiting for some Event Flag (which contains a WAITING value corresponding to this task) to be Posted. SWPWT Swap Wait - This Task cannot run because it is not in core - this bit is reserved for future SRT-8 releases. RUNWT Run Wait - this task is waiting for a RUN ER to be executed with its number in the AC, or for the operator to type "REQUEST task" to the Monitor Console Routine. EORMWT Event or Message Wait - this task is waiting for an Event Flag to be set or a message to arrive, whichever comes first. ENABWT Enable Wait - this task is waiting to be Enabled. Use of this bit is restricted to the Monitor Console Routine for use by the "ENABLE task" and "DISABLE task" commands. USERWT User Wait - this bit is reserved for use by user-written tasks. SRT-8 will not touch this bit at all. SRT-8 User's Manual Page 11 Executive Requests Several ER's exist which allow a task to explicitly set and clear wait bits in other task's Task Flags Table entry, and to set bits in its own. BLKARG - Block task for specified reason: Format: TAD TASKNUM /OR 0 IF MYSELF CAL BLKARG WAITBITS Where TASKNUM contains the number of the task to be blocked, and WAITBITS specifies one or more bits to be set on in that task's Task Flags word. Assuming WAITBITS is non-zero, this will cause the specified task to become non-runnable. If TASKNUM contains 0 the issuing task will be blocked on the specified wait bits. The TASKNUM=0 form of this ER is the only legal way to specify the issuing task as the task to be blocked; if TASKNUM is equal to the issuing task number the action of this ER is undefined. UNBARG - Unblock task for specified reason Format: TAD TASKNUM CAL UNBARG WAITBITS Where TASKNUM contains the number of the task to unblock, and WAITBITS specifies one or more bits to be cleared in that task's Task Flags Word. If the Task-Flags word becomes zero as a result of this operation the specified task becomes runnable. If the specified task is of higher priority than the issuing task and becomes runnable, the issuing task is temporarily suspended while that task runs. This ER is a no-op if issued with TASKNUM equal to the issuing task's number. SRT-8 User's Manual Page 12 Executive Requests SUSPND - Suspend a task's execution Format: TAD TASKNUM /0 IF MYSELF CAL SUSPND This E.R. is identical in action to the following: TAD TASKNUM CAL BLKARG RUNWT RUN - Run a task Format: TAD TASKNUM CAL RUN This E.R. is identical in action to the following: TAD TASKNUM CAL UNBARG RUNWT The SUSPND and RUN E.R.s exist because their function is performed sufficiently often to warrant a shorthand version. An example of how they could be used is: SRT-8 User's Manual Page 13 Executive Requests A data collection task would like to print a report every 1000 data points without interrupting the data collection/reduction process. DATA task REPORT task LOOP, TAD (1750 /1000 DECIMAL LOOP, CAL /AC=0, SUSPEND DCA COUNT SUSPND /ME UNTIL NEEDED DATALP, CAL JMS TITLE /I'VE BEEN RUN WAITE . DATAEF . /PRINT REPORT . /GET A DATA POINT . /WITH TITLE. ISZ COUNT /AND PROCESS IT. . JMP DATALP /COUNT OFF 1000 . TAD (REPORT /POINTS . CAL /RUN REPORT TASK JMP LOOP /REPORT OVER. RUN /GO BACK AND JMP LOOP /KEEP COLLECTING /WAIT. COUNT, 0 Of course, to eliminate interference with the data collection, REPORT Should be a lower priority task than DATA. There is one task control ER which does not cause any wait bits to get set or cleared, but which derails the execution of a specified task into a subroutine: DERAIL - Derail a task's execution Format: TAD TASKNUM CAL DERAIL ADDR This ER causes a "JMS ADDR" to be simulated for the task whose number is contained in TASKNUM. ADDR is assumed to be in the same field in which the specified task is executing. The specified task's PC (from its Task State Table entry) is stored in ADDR, and the PC entry in its Task State Table entry is then set to ADDR+1. Two important things to note about the operation of the DERAIL ER: a. The specified task's AC, LINK, and Data Field setting are not saved by the DERAIL ER - therefore they must be saved and restored by the derail subroutine. In this sense, a derail subroutine is very much like an interrupt at the task level. b. The contents of the specified tasks Task Flags word are not affected by the DERAIL ER. If the specified task was not runnable, the derail subroutine would not be executed until it became runnable. SRT-8 User's Manual Page 14 Executive Requests Waiting for multiple Event Flags Sometimes it is desirable to wait on a logical combination (AND or OR) of event flags. Waiting on the logical AND of two event flags is quite simple; the sequence: CAL WAITE A /WAIT FOR EVENT FLAG A CAL WAITE B /AND THEN WAIT FOR EVENT FLAG B Waits until both A and B have been posted. Waiting on the logical OR of several event flags is more difficult, since there is a possible race condition between the various tests and the interrupts (or task executions) which POST the Event Flags involved. The key to waiting for an OR of several Event Flags successfully is not to allow any interrupts to occur between the testing of the first Event Flag and the placing of the task in a wait state if none of the flags were POSTed. To accomplish this requires a special sequence of instructions and a special SRT-8 call named WAITM. WAITM is currently defined to be a JMS I 25. It must be executed with interrupts off, the Instruction Field set to 0 and the Data Field set to the current field, and it must be followed by a word containing the blocking bit(s) to be set in the Task Flags Table. The action of WAITM is equivalent to the action of the SRT-8 ER BLKARG except that a fast path through the SRT-8 Executive is taken and interrupts remain off until the blocking bits are on in the Task Flags Table. SRT-8 User's Manual Page 15 Executive Requests For an example of the use of WAITM, assume that a task "TASK" wants to test two event flags A and B. If A is POSTed we want to go to location ADONE, and if B is POSTed we want to go to location BDONE. If neither is POSTed we want to wait until one of them is. The code to perform this function is: TESTAB, IOF /INTERRUPTS OFF - DELICATE CODE! TAD A SNA CLA JMP ADONE /ADONE must turn interrupts on! TAD (4000+TASK DCA A /set A to WAITING state TAD B SNA CLA JMP BDONE /BDONE must turn interrupts on! TAD (4000+TASK DCA B /set B to WAITING state CIF 0 CDF CUR WAITM EFWT /block task on EFWT JMP TESTAB /we're back - one of them is POSTed - which? SRT-8 User's Manual Page 16 Executive Requests Interrupts in SRT-8 The SRT-8 executive contains code to receive and dismiss interrupts and to perform interrupt-initiated task switching, but it does not provide room for an interrupt skip chain, instead, the "skip chain" is literally a chain and is built up dynamically via the following ER: SKPINS Insert code into skip chain Format: CAL SKPINS MODULE Where MODULE is the address (in the current field) of an interrupt processing module. An interrupt processing module has the following format: MODULE, 0 /this word gets a pointer /to the next module 0 /module entered here - contains /CDF CIF next module field SKDR /skip on device ready (SKP) /(only if SKDR really means skip on /device not ready) JMP I MODULE /not ready - go to next module in chain CDF CIF CUR /this one is mine - set DF and IF /correctly . /interrupt processing . . CIF 0 POSTDS /dismiss the interrupt, maybe POST /an Event Flag The SRT-8 interrupt skip chain initially consists of one such module, for the system clock. Whenever a task executes a SKPINS ER, the interrupt chain is broken at the very end and the users interrupt module is inserted. The last interrupt module points to the interrupt dismiss routine as its "next module", so that SRT-8 will try to avoid superfluous interrupts. Notice that SKPINS always inserts at the end of the skip chain. This implies that the skip in the skip chain will be ordered roughly by priority of the task which inserted them, since SKPINS E.R.s in a task are usually executed as once-only code at system startup time. SRT-8 User's Manual Page 17 Executive Requests Once an interrupt module receives control (by having its I/O skip succeed) there are several restrictions on its execution: a. The Data Field and Instruction Field are those of the NEXT interrupt module - this must be corrected before any indirect addressing or Jumps are performed. b. An interrupt module may not issue SRT-8 E.R.s c. An interrupt module should not compute excessively, since interrupts are off - typical execution time should be < 50 microseconds. If considerably more time than this is needed, it should be done at the task level and not at the interrupt level. d. Interrupt modules should not turn interrupts on, as the state of the interrupted task may be destroyed by a second interrupt; e. On entry to the interrupt module the AC, Link, and Data Field have already been saved, but the MQ has not. Therefore interrupt modules wishing to use the MQ should save it first and restore it before dismissing. f. Interrupt module should dismiss the interrupt by setting the Instruction Field to 0 and issuing a POSTDS instruction, POSTDS is currently a JMP I 24. An Event Flag may be posted when the interrupt is dismissed by setting the Data Field to the field of the Event Flag and placing the location of the Event Flag in the AC prior to issuing the POSTDS - for example. CDF CUR /DF = THIS FIELD TAD (EVFLG /EVFLG MAY NOT BE AT LOC 0! CIF 0 POSTDS /DISMISS INTERRUPT AND POST EVFLG SRT-8 does not currently provide a mechanism for dynamic removal of entries from the interrupt skip chain. When a disk - resident task facility is added, dynamic removal will be implemented as well. SRT-8 User's Manual Page 18 System Generation Assembling and Loading Tasks for SRT-8 SRT-8 tasks are assembled with the OS/8 PAL8 assembler and the use of a parameter file. SRT-8 parameter files are all edited versions of a master parameter file which is included in the distributed sources. All definitions in the master file which are to be supplied by the user are left blank in the file; i.e. a sample line in the file might be: PDP8E= /SET TO 1 IF PDP8E, ELSE 0 THERE SHOULD RE A UNIQUE PARAMETER FILE CREATED FOR EVERY SRT-8 ENVIRONMENT. WHERE ENVIRONMENT IS A COMBINATION OF THE AVAILABLE HARDWARE AND THE SET OF TASKS BEING RUN. THE PARAMETER FILE IS DIVIDED INTO 5 SECTIONS: A. EXEC SPECIFICATIONS - THESE SPECIFICATIONS CONTROL THE ASSEMBLY OF THE SRT-8 EXEC AND THEREFORE MUST BE INCLUDED. THEY INCLUDE: WHETHER THE MACHINE IS A PDP-8E, HOW MUCH CORE IS AVAILABLE, WHETHER TO SAVE/RESTORE THE MQ, HOW MANY TASKS IN THE SYSTEM, ETC. B. TASK DEFINITIONS - THIS SECTION DEFINES SYMBOLIC NAMES FOR THE VARIOUS SYSTEM TASKS IN THE SYSTEM. THE NAMES OF ALL SYSTEM TASKS WHICH ARE TO BE INCLUDED IN THE SYSTEM SHOULD BE DEFINED HERE, AND ANY SYSTEM TASK WHICH IS NOT INCLUDED SHOULD HAVE THE LINE WHICH DEFINES IT DELETED FROM THIS SECTION. THE USER IS ENCOURAGED TO ADD SYMBOLIC DEFINITIONS OF HIS OWN TASKS TO THIS SECTION. C. SYSTEM TASK SPECIFICATIONS - THESE SPECIFICATIONS CONTROL THE ASSEMBLIES OF VARIOUS SYSTEM TASKS. THEY INCLUDE THE DESIRED CLOCK RATE, THE NUMBER OF FIELDS TO ALLOCATE THE OS/8, ETC. THE SET OF PARAMETERS CONTROLLING A TASK ARE ALL GROUPED TOGETHER AND ASSEMBLED CONDITIONALLY, ONLY IF THE TASK NAME IS DEFINED. D. SYSTEMWIDE DEFINITIONS - THESE INCLUDE THE DEFINITIONS OF THE SYMBOLS USED IN THIS DOCUMENT TO DESCRIBE THE EXECUTIVE REQUESTS AND TASK FLAG BITS, PLUS MANY OTHER USEFUL DEFINITIONS. THIS SECTION SHOULD NOT BE ALTERED BY USERS. SRT-8 User's Manual Page 18 System Generation E. TASK SETUP - THIS SECTION USES FOUR SYMBOLS DEFINED IN THE BODY OF THE USER'S TASK TO SETUP THE SRT-8 TABLE ENTRIES NEEDED TO PUT THAT TASK IN THE SYSTEM. THE FOUR SYMBOLS NEEDED ARE: TASK DEFINED TO BE THE TASK NUMBER OF THE TASK CUR DEFINED TO CONTAIN THE FIELD OF THE TASKS STARTING ADDRESS IN BITS 6-8 (E,G,, CUR=10) START DEFINED TO BE THE TASK'S STARTING ADDRESS (NOT NECESSARILY THE LOWEST ADDRESS IN THE TASK) INIWT DEFINES THE INITIAL WAIT BITS IN THE TASK FLAGS TABLE - INIWT=0 MEANS THE TASK IS RUNNABLE WHEN THE SYSTEM STARTS UP, UP TO THREE TASKS MAY BE DEFINED IN ONE ASSEMBLY - THE CORRESPONDING SYMBOLS FOR THE OTHER TASKS ARE TASK2 AND TASK3, CUR2 AND CUR3, ETC. THE TASK SETUP SECTION PLACES ITS DATA INTO THE SRT-8 TABLES BY ORIGINING INTO THEM - NO EXECUTABLE CODE IS GENERATED. TO CREATE A REAL-TIME SYSTEM USING SRT-8, FIRST LAYOUT THE TASKS YOU WILL NEED ON PAPER. THEN CREATE A PARAMETER FILE WITH THE PARAMETERS FOR THAT SYSTEM, AND ALLOCATE CORE STORAGE AMONG THE EXECUTIVE, THE SYSTEM TASKS, AND YOUR OWN TASKS. WRITE YOUR TASKS AND ASSEMBLE EACH TASK PRECEDED BY THE PARAMETER FILE. LOAD THE RESULTING BINARIES WITH OS/8 ABSLDR, PLACING THE SRT-8 BINARY FIRST. AT THIS POINT YOU MAY START YOUR SYSTEM, OR SAVE IT AS CORE IMAGE FILE TO BE RUN LATER. AN SRT-8 SYSTEM CREATED AS ABOVE HAS A STARTING ADDRESS OF 00200. IF SRT-8 WAS NOT SPECIFICALLY CONFIGURED FOR A PDP 8/E IT WILL HALT INITIALLY SO THAT THE OPERATOR MAY CLEAR ANY STRAY DEVICE FLAGS. PRESS START TO RESUME OPERATION ON A PDP 8, 8/I OR 8/L; PRESS I/O PRESET FOLLOWED BY CONTINUE ON A PDP-12. SRT-8 User's Manual page 20 SYSTEM TASKS SRT-8 SYSTEM TASKS THE SOURCES OF THE SYSTEM TASKS ARE SUPPLIED WITH THE SRT-8 SYSTEM. THE TASKS REFERRED TO AS "HANDLERS" ARE COMPLETELY MESSAGE-DRIVEN - I.E. WHEN IDLE THEY ARE IN THE MESSAGE WAIT STATE, OTHER TASKS SEND THESE HANDLERS I/O request messages, and when the handler completes the I/O operation it sets the Event Flag associated with the request message and issues another RECEIVE ER. 1. Clock Handler This task can be assembled to handle any of four hardware clocks (DK8EA, DK8EC, DK8EP, KW12. , It accepts requests (in the form of SRT-8 messages) to perform actions after a specified time has elapsed. The clock handler uses an interval queue whose length is fixed at assembly time to keep track of its pending requests. The format of a clock message is: CLKMSG, ZBLOCK 3 /3 WORDS RESERVED FOR SRT-8 COMMAND+TASKNO /TASKNO=0 MEANS TASKNO=SENDING TASK TIMEHI TIMELO EXTRA1 EXTRA2 The words TIMEHI and TIMELO specify a time interval from the present time in terms of "system ticks". The duration of a "system tick" is specified by the user in the SRT-8 parameter file via the parameter SHERTZ. The hardware tick rate is specified by the parameter HERTZ. HERTZ must be an exact multiple of SHERTZ. For example, the parameters for a line-frequency clock might be: DECIMAL HERTZ= 60 SHERTZ= 10 Indicating that only l/10 Second resolution is necessary in the clock handler. The clock handler is referred to by other SRT-8 system tasks via the symbol CLOCK. This symbol should be defined in the SRT-8 parameter file to be equal to the clock handler's Task number. It should be undefined if no clock handler is to be included in the system. SRT-8 User's Manual page 21 SYSTEM TASKS COMMAND is the type of request and has the following meanings: 0000 - POST the event flag CLKMSG after the specified interval elapses. TASKNO, EXTRA1 and EXTRA2 are ignored. 1000 - Execute a RUN ER on the task specified by TASKNO after the specified interval elapses. POST CLKMSG immediately. EXTRA1 and EXTRA2 are ignored. 2000 - DERAIL the task specified by TASKNO into a subroutine whose address is specified in EXTRAl after the specified interval elapses. POST CLKMSG immediately. EXTRA2 is ignored. 3000 - Execute a RUN ER on the task specified by TASKNO after the specified interval elapses, and re-queue this command with the parameters EXTRA1 and EXTRA2 in place of TIMEHI and TIMELO. This has the effect of running the specified task periodically with a period specified by EXTRA1 and EXTRA2. POST CLKMSG immediately. 4000 - Delete from the clock queue all requests for the task specified by TASKNO. TIMEHI, TIMEL0, EXTRA1, and EXTRA2 are ignored. POST CLKMSG. The clock handler also maintains the current time-of-day (in system ticks until midnight) in locations TODH (high-order) and TODL (low-order) in Page 0 of field 0. When this time-of-day reaches zero (i.e. at midnight) it is reset to the quantity SHERTZ*86400 (24 hours until midnight) and an OS/8-format date word in location DATE in page 0 of Field 0 is incremented by one day. Note that in order for the quantity SHERTZ*86400 to be contained in 24 bits, SHERTZ must be less than 192. SRT-8 User's Manual page 22 SYSTEM TASKS Examples of clock handler calls: 1) CAL /With a 50Hz system tick rate. SENDW /this causes the current task CLOCK /to "go to sleep" for 2 seconds. SLEEPM . . SLEEPM, ZBLOCK 3 /SRT-8 message overhead 0 /set event flag after interval 0;144 /interval is 100 (decimal) system ticks Note that by changing the 144 to the assembler expression 2^SHERTZ the above sequence becomes configuration independent. 2) CAL /Run the task REPORT once SEND /every hour, indefinitely, CLOCK /assuming A 50Hz system tick rate RUNMSG . . RUNMSG, ZBLOCK 3 /SRT-8 message overhead 3000+REPORT /Run REPORT after specified interval and /periodically thereafter. 0;1 /First run is almost immediately (1/50 second). 53;7440 /period between runs is 180000 (decimal) /system ticks - 3600 seconds = 1 hour. SRT-8 User's Manual page 23 SYSTEM TASKS 2. Teletype Handler The SRT-8 Teletype handler handles a single Teletype in either line or character mode. Input in line mode is terminated by a carriage return or an ALTMODE character, and may be edited with the RUBOUT and ^U characters. The RUBOUT character deletes the last valid character typed and prints a backslash; the ^U character deletes the entire line and returns the carriage. Character mode input is not echoed and is terminated by overflow of a specified character count. If multiple Teletypes are to be handled, multiple copies of this Teletype handler must be assembled. Assembly parameters in the body of the handler specify which device codes the handler should use to access its Teletype and if the handler is to be a "console" Teletype handler (the console Teletype handler invokes the MCR whenever a ^C is typed on the keyboard; non-console Teletype handlers treat ^C as any other character). The parameters edited into the distributed version of the Teletype handler assemble it to handle the PDP-8 console Teletype as a "console" device. A message to the Teletype handler performs a (possibly null) output operation followed (optionally) by an input operation. The format of messages to the teletype handler is: TTYMSG, ZBLOCK 3 PACK+CRLF+IND+LINE+ASSIGN+LENGTH INBUF OUTTXT SRT-8 User's Manual page 24 SYSTEM TASKS where PACK =0 if output text is in packed ASCII format. =4000 if input text is in unpacked ASCII (one character per word, zero word terminates) CRLF =0 if output message should be followed by a carriage return/line feed. =2000 if it should not. IND =0 if OUTTXT is the first word of the output text =1000 if OUTTXT points to the first word of the output text LINE =0 if input is in line mode (terminated by carriage return or ALTMODE) =400 if input is in character mode (terminated after "LENGTH" input characters have been read) ASSIGN =0 for normal I/O operations. =200 "Assigns" the Teletype handler to the task specified by the LENGTH field. This will cause the Teletype handler to only accept messages from the specified task. If another task tries to SEND a message to the Teletype handler while it is assigned, the message will be placed in the Teletype handler's Message Input Queue but will not be removed for processing by the Teletype handler until the assignment is released. The task to which the Teletype handler is assigned can release the assignment by sending a message assigning the teletype handler to task number 0. No I/O operation is performed by an assignment message. LENGTH is a seven bit field which specifies the maximum size of the input buffer if input is in line mode, the number of characters to input if input is in character mode, and a task number if the ASSIGN bit is set. If input is in line mode and there are LENGTH-1 characters in the input buffer, characters other than carriage return, ALTMODE, RUBOUT and ^U will not be accepted or echoed. INBUF is a pointer to the input buffer - if it is zero, no input is taken. The input buffer is filled with input characters packed one per word with the parity bit forced on. If input is in line mode, the last character of the line is followed by a zero word (if a carriage return terminated the line) or a negative word (if an ALTMODE character terminated the line). OUTTXT is either the first word of the output text string (if IND=0) or a pointer to the first word of the output string (if IND=1000). SRT-8 User's Manual page 25 SYSTEM TASKS Examples: HIYA, ZBLOCK 3 /SRT-8 Message overhead 0 /Packed text, end with CR/LF 0 /No input TEXT /HELLO/ /Text to be output Sending the above message to the Teletype handler prints "HELLO" on the Teletype. QUEST, ZBLOCK 3 /SRT-8 Message Overhead 2060 /Packed text, no CR/LF, /48 character input limit, ANSWER /Pointer to input buffer TEXT /TYPE THE ANSWER:/ Sending the above message to the Teletype handler prints "TYPE THE ANSWER:" on the Teletype and inputs a reply without first returning the carriage. The answer obtained from the above message could be printed on the teletype by sending the following message: TYPANS, ZBLOCK 3 /The usual overhead 5000 /Unpacked text, indirect, with CR/LF 0 /No input ANSWER /Pointer to output text 3. Line Printer Handler The SRT-8 line printer handler outputs to an LE8, LS8E or LV8 line printer. The format of messages to the line printer handler is identical to the format of messages to the Teletype handler, but the INBUF word and the LINE bit are ignored (the INBUF word must, however, be present). SRT-8 User's Manual page 26 SYSTEM TASKS 4. Mass storage handlers This group of handlers all accept the same request message format to read or write blocks on various mass storage devices. Handlers have been written for TC08 Dectape, DF32 and RF08 fixed-head disks, and RK8 and RK8E moving-head disks. The format of messages to mass storage handlers is: MSMESG, ZBLOCK 3 UNIT RW + PAGES + FIELD BUFADD BLOKNO STATUS where UNIT is the number of the unit on which the operation is to be performed. DF32 and RF08 disks consist of only one unit. TC08 Dectape has units 0-7. corresponding to its physical units 0-7. RK8 disk has units 0-3 corresponding to its physical units 0-3. RK8/E disk has unit 0-7, units 0-3 correspond to the outer (lower track number) half of physical units 0-3, and units 4-7 correspond to the inner (higher track number) half of physical units 0-3. RW is 0 for a read operation, 4000 for a write operation. PAGES specifies the number of (128 word) pages to transfer, times 100(8), i.e. if PAGES=2000 it means transfer 20(8) pages or 2048 words. If PAGES=0, 40(8) pages or 4096 words will be transferred. FIELD if the PDP-8 field in which the transfer takes place, times l0(8), i.e. if FIELD=30 the transfer will take place in field 3. BUFADD is the starting address of the buffer to be transferred. SRT-8 User's Manual page 27 SYSTEM TASKS BLOKNO is the block number on the device from which the transfer will begin. All devices are assumed to have 256 word blocks. On Dectape, the first 128 words of each of an even/odd pair of 129 word Dectape records are considered to be a block. STATUS is a word which is set by the handler on completion of the operation. It will contain a zero if the operation was successful, otherwise it will contain a non-zero quantity which is the device status register. Tasks which use the mass storage handlers should test this word after the I/O operation has been completed (i.e. after the Event Flag has been Posted) to determine if any errors occurred during the transfer. All SRT-8 mass storage handlers retry operations three times if errors are encountered before setting the STATUS word non-zero. Note that the middle three words of a message to the SRT-8 mass storage handlers are identical to the arguments to an OS/8 handler which performs the same operation. Example: CAL SENDW DTA /Send a message to the Dectape handler DTAMSG /and wait for completion. TAD STATUS /Check the status of the operation. SZA CLA JMP ERR /Bad - go to error routine. DTAMSG, ZBLOCK 3 /SRT-8 message overhead 4 /Dectape unit 4 4210 /Write 256 words from field 1, BUFFER /location BUFFER, 55 /into block 55 (records 132 & 133). STATUS, 0 /status of operation stored here. SRT-8 User's Manual page 28 SYSTEM TASKS 5. OS/8 File Support Task The OS/8 File Support Task (hereafter referred to as OS8F) allows other tasks to lookup, create, and delete files in OS/8 directories. It is included in the same source file as the OS/8 Support Task, but may be assembled independently of that task (depending on which tasks are defined in the system parameter file). The format of messages to OS8F is: OSFMSG, ZBLOCK 3 /SRT-8 OVERHEAD DEVHND+UNIT+FUNCT FILPTR STATUS BLOKNO LENGTH where DEVHND is the task number of the handler for the desired device. UNIT is the unit number on which the operation is to be performed. FILPTR is a pointer to a four-word filename. The PAL8 pseudo-op FILENAME may be used to generate these filenames. FUNCT represents the function to be performed. It may have the following values: 0 Look up the specified file name and return its starting block number in BLOKNO and its (positive) length in LENGTH. 2000 Enter the specified file name into the first empty space on the device whose length exceeds the value in LENGTH. Return the starting block number of the new file in BLOKNO. If a file of the same name previously existed on the device it is deleted. The value of LENGTH is unchanged. 4000 Delete the specified file name. SRT-8 User's Manual page 29 SYSTEM TASKS STATUS Describes the final status of the operation: 0 Means operation successful. 1 Means file not found on LOOKUP or Delete. 2 Means no room for file on Enter. > |
1 2
Share in:
