hBhrvbeh mm Mamma la m mm ill ■HHR aim in *2^= To renew call Telephone Center, 333-8400 ML 2 1 )M SEP 22 m I L161—O-1096 Digitized by the Internet Archive in 2013 http://archive.org/details/semivirtualmemor641wong J Ms A/ JIdMHI UIUCDCS-R-7^-6^-1 May 197^ J7)aXm A SEMI- VIRTUAL MEMORY MULTI- PROGRAMMING SYSTEM FOR THE MINI-COMPUTER PDP 8/3 (lLLIAC-3) by Tze-Wah Wong 7 UIUCDCS-R-7^-6Ul A SEMI -VIRTUAL MEMORY MULTI- PROGRAMMING SYSTEM FOR THE MINI -COMPUTER PDP 8/3 (lLLIAC-3) by Tze-Wah Wong May 197^ Department of Computer Science University of Illinois at Urb ana- Champaign Urbana, Illinois This work was supported by the Department of Computer Science and was submitted in partial fulfillment for the Master of Science degree in Computer Science, 197*+. Ill ACKNOWLEDGMENT The author wants to express his sincere thanks to the ILLIAC III group (especially the hardware personnel) in offering the equipment from which this system software can be tested. Thanks also to Professor George Friedman for offering his time in proof reading and commenting on this paper. IV PREFACE A multiprogramming (semi-) virtual memory operating system has been written for the mini-computer PDP 8/e located in the ILLIAC-3 room of the University of Illinois. This computer is currently used to control the various picture processing peripherals in the room as well as routing information to the general purpose computer IBM 360/75 for processing. The following paper describes the usage and design principles of the operating system in coping with the above environment. V TABLE OF CONTENTS page 1 . DESIGN GUIDELINES 1 2. HARDWARE CONFIGURATION 3 2.1 PDP 8/e 3 2. 2 Peripherals 5 3. DESIGN DECISIONS 10 3 . 1 Semi-Virtual Memory System 10 3 . 2 Task Management 14 3 . 3 Peripheral Management 19 3.4 Device Independent (Assignable) I/O 21 4. SYSTEM ROUTINES AND TABLES 25 4.1 Virtual Memory Routines 26 4.1.1 LOAD 26 4.1.2 STORE 26 4.1.3 GOTO 27 4.1.4 CALLS 27 4.1.5 CORE MAP 28 4.2 Task Management Routines and Control Blocks 30 4.2.1 TASK CONTROL BLOCK (TCB) 30 4.2.2 DEVICE TABLE ENTRY (DTE) 31 4.2.3 EVENT CONTROL BLOCK (ECB) 31 4.2.4 QUEUE ELEMENT (QE) 32 VI page 4.2.5 SERVICE ELEMENT ( SE ) 33 4.2.6 POST Routine 3 3 4.2.7 WAIT Routine 34 4.2.8 QUEUE Routine 35 4.2.9 NEXTQ Routine 35 4. 3 Communication Table 36 4.4 UTILITIES 37 4.4.1 REA DC Routine 38 4.4.2 LPRINT Routine 38 4.4.3 WRITEA Routine 38 4.4.4 WRITEC Routine 39 5. EXISTING SYSTEM AND PROBLEM TASKS 40 5.1 Keyboard Monitor Task 40 5 . 2 Scanner Task 42 5.3 ODT (Octal Debug Technique) Task 44 5 . 4 Text Editor Task 44 5 . 5 Microscope Stage Task 45 5. 6 Line- tape Task 45 5. 7 Display Task 46 6. IBM 360 INTERFACE 47 7. HOW TO GET INTO A SPECIFIC FIELD 50 8. HOW TO USE OS/8 SUPPORT 52 9. CODING NEW TASKS TO THE SYSTEM 53 10. REMARKS 62 BIBLIOGRAPHY 63 APPENDIX 64 1. DESIGN GUIDELINES Since the operating system was designed with the partic- ular picture processing environment in mind, a number of design guidelines were observed to ensure convenience in use and reasonably high system performance: (a) The system must provide easy methods for on-line interactive communication with IBM 360 (or any other computer of the same class). A large amount of computation power is needed to process pictures, and it is not likely to be done entirely on the mini-computer PDP 8/e. Therefore, information must be transmitted to more powerful computers for a major part of the processing. Also since pictures are digitized and displayed on the ILLIAC III site only, the communication must be real time interactive, so as to satisfy the needs of many such algorithms. (b) The user must be able to supervise and if necessary interrupt the processing of his program on the IBM 360. Most picture processing programs are still experimental. They are far from "bug free." Allowing the user to interrupt his program can save unnecessary computer time and make debugging easier. Also ways should be provided to communicate with the IBM 360 machine room operator for specific run time instructions, (c) Facilities should be provided to output a majority of the printouts of the IBM 360 runs at the ILLIAC III site. This is the only way a user can determine the outcome of the experiment on a particular algorithm so as to decide on the next phase of the experiment. (d) Device independent I/O should be provided for programs to use (if they want to). The I/O devices should also be assignable at run time to provide maximum flexibility. (e) The system should provide ways to do part of the picture processing on site. Most picture processing algorithms require a lot of storage. Methods should be provided to swap the contents of primary memory and secondary memory. (f) Some form of on-line debug and error (I/O or program) recovery should be provided. (g) The system should be easy to maintain. (h) The system performance should be reasonably high, i.e., at least an order of magnitude higher than a mono-pro- grammed system (e.g., 0S8 ) . 2. HARDWARE CONFIGURATION 2.1 PDP 8/e The PDP 8/e is a 12 bit word minicomputer. (I.e., all instructions and data are 12 bits long. ) It has an accumulator and several status registers (to record hardware states). It does not have any index register or base register. All arithmetic is done with this accumulator. The accumulator (which is itself 12 bits long) is accompanied by a one bit register "link" as the most significant bit to form a 13 bit entity to enable multiple precision arithmetic. There are separate commands to manipulate the "link" and the accumulator. The PDP 8 instructions are also 12 bits long. The most significant 3 bits are used as operation code. So there is a maximum of 8 instructions. Only 6 of these are memory reference instructions. For these 6 instructions, the next 2 bits are address modification bits known as "indirect- addressing bit" and "current page bit" respectively. The remaining 7 least significant bits are known as the displace- ment. So there is a maximum displacement of 128. In other words, a memory reference instruction can only address 128 words directly. The PDP 8 memory is segmented into 128 word pages: page covers locations 0-127, page 1 covers locations 128-255, and so on. The "current page bit" determines which page the "displacement" is referencing. If the "current page bit" is 0, page is referenced. If the "current page bit" is 1, the page in which the memory reference instruction resides referenced. So every instruction can reference its own page or page zero directly. Page zero can therefore be used to store commonly used variables. If a PDP 8 instruction wants to reference an address not in page zero or its own page, indirect addressing must be used (indicated by 1 for the "indirect addressing bit"). In this case, instead of using the contents of the computed address as data, it is used as a 12 bit effective address. Thus using indirect addressing, an instruction can effectively access locations 0-4095. This 4K of core is known as a "field." Most PDP 8's have more than 1 field. In this case, 2 instructions are provided to switch between fields. A "CHANGE DATA FIELD n" instruction will specify all later data references to be from a particular field. The "CHANGE INSTRUCTION FIELD n" is provided to transfer control to a program in another field. The particular PDP 8/e at ILLIAC III site has 2 fields. The PDP 8/e instructions do not facilitate re-entrant or recursive programming (due to lack of a base register) . The remaining 2 non-memory reference instructions are known as IOT and OPR. The OPR instruction performs various shifts, tests, etc. with the accumulator and the link. The IOT instruction transmits information to the peripherals. There are basically 2 kinds of transmissions depending on the nature of the device. Most devices have a word oriented transmission. An IOT is provided to test the device ready flag. A second IOT is provided to transmit information to or from the device, and a third IOT is provided to clear the device ready flag so that it can be set again when the device has finished transmitting the word. Some devices use a block-oriented transmission with a cycle-stealing data-break controller. In this case, IOT's are provided to specify the buffer address, the buffer field, the word count, etc., and the controller will perform the transmission while the CPU can be executing another program. An IOT is provided to test for the completion of the transmission. The PDP 8 has a rather primitive interrupt hardware. If an interrupt device is ready and if the interrupt status bit is enabled, the computer will be interrupted by storing the address of the next instruction in location and proceeding to execute the instruction at location 1 (which presumably is the entry point of the interrupt handler). There is no indication as to the source of the interrupt. The interrupt handler must test the ready flag of each of the devices in sequence to find out which one is interrupting. 2. 2 Peripherals A variety of peripherals are connected to the PDP 8/e (see Figure 1 ) : (a) There are 2 full-duplex teletypes. These are word-oriented devices and will generate an interrupt when either keyboard or typer is ready. (b) An interval timer with variable time base and time interval is present. The timer can interrupt the CPU when the time interval has elapsed. DEC PDP-8/e SUBSYSTEM TELETYPES (2) LINCTAPE CONTROLLER LINCTAPE DRIVES (6) LINE PRINTER HANOWHEELS INTERVAL TIMER POP-8/* 8K WORDS MEMORY INTERFACE INTERFACE HIGH SPEED PAPER TAPE READER IBM 360/75 SUBSYSTEM 2701 PARALLEL DATA ADAPTER 360/73 ILLIAC 1 CORE MACHINE I SCANNER -MONITOR -VIDEO CONTROLLER STAGE a FOCUS MOTOR CONTROLLER FLYING -SPOT MICROSCOPE SCANNER 46 MM FILM SCANNER MONITOR S-M-V SUBSYSTEM VIDEO SUBSYSTEM VIDEO SWITCHING NETWORK I STAGE 3 FOCUS MOTOR CONTROLLER AUTOMATED VIDEO MICROSCOPE VIDEO MONITOR MANUAL VIDEO MICROSCOPE VIDEO MONITOR LARGE FORMAT VIDEO CAMERA VIDEO MONITOR DATA AND/OR CONTROL CONTROL ONLY FIGURE 1. OPERABLE HARDWARE (c) Two rotating knobs known as hand-wheels are located at the picture display monitor. A program can sense the angle of rotation of these wheels and use the information to control the positioning of pictures. The hand-wheels can interrupt the PDP 8 when being rotated. (d) Motors are provided to move slides on a microscope stage by program control. The program specifies the distance to be moved in each direction and the slide will be positioned as directed. Upon completion, the stage controller can interrupt the PDP 8 when needed. (e) A line printer is provided to print out information at 80 characters a second. Due to the particular design of the printer, it must be able to get 3 characters within 25 milli- seconds after the ready flag is raised, or it will generate a carriage return and ignore the rest of the line. The line printer does not generate an interrupt when ready. (f ) A high speed paper tape reader which inputs 300 characters a second is also connected to the PDP 8. It also does not generate an interrupt when ready. (g) A Line-tape controller is connected, which controls 2 Line-tape drives. These Line- tapes are preformatted tapes which contain a large number of records known as blocks. The design of the controller is such that the PDP 8 can request the controller to start I/O operation on any specified block, and the controller will search for that block automatically. So it appears to be like a random access device to the CPU, though a lot of time is used in rewinding and winding the tape 8 to the desired block. The PDP 8 must read or write within 122 microseconds when the ready flag is raised, or a program timing error flag will be raised. The Line-tape controller does not interrupt the PDP 8 when ready for transmission. (h) Two Fabritek core memory boxes each having 16K 72 bit words are connected to an Exchange net which is connected to an Exchange net interface. This interface is a block-transfer cycle-stealing data break device. The PDP 8 can be working on another program during the transfer. The interface does not interrupt the PDP 8 upon completion. (i) A scanner-monitor is connected to the system to digitize and to display pictures. Upon receiving an activate signal, the scanner-monitor will obtain its parameters from one of the Fabritek core boxes and start the scanning process. The digitized information is transmitted to the Fabritek core boxes directly by the scanner. The scanner does not interrupt the PDP 8 upon completion. (j) An IBM 360 interface is connected to the system to provide direct communication with the general purpose computer, This is also a block-transfer cycle-stealing data break device. It does not interrupt the PDP 8 upon completion. (k) A large format scanner which makes use of informa- tion from a TV camera and converts it into digitized grey levels is being completed. There is no definite information as to the nature of this device. (1) The pattern articulating unit of the ILLIAC III system is also being completed. A very limited amount of information is available at this time. It is conceivable that the above 2 devices will be added to the system in the near future. 10 3. DESIGN DECISIONS The design guide-lines of the system requires it to be quite versatile and fully interruptible (by the user) for a large number of functions. It is conceivable that the only effective system is that which performs these functions (e.g., communica- tion with IBM 360, printing output, etc.) concurrently. With the limited capability of the hardware (e.g., no protection feature, does not support re-entrant programming), the easiest (and most storage saving) implementation is a multi-programming system. Now these concurrent functions can be implemented by independent "processes" or "TASKS." The bookkeeping of TASK switching can be left to the operating system. In order to provide enough storage for this large number of "tasks," some swapping of contents of primary memory and secondary memory (Fabritek core boxes) must be done. Due to the fact that the PDP 8/e does not have address remapping (translation) hardware, a true Virtual Memory System cannot be implemented. However, the problem "task" can explicitly specify to the system when a new page is needed. This is known as a semi-virtual memory system. 3. 1 Semi-Virtual Memory System The first thing to decide is the size of a "page" or a "segment" that is to be used as the basic unit of swapping. This "segment" should be small to reduce superfluity. However, 11 this process of segmenting the primary memory must also be such that it is transparent to the programs or data being swapped. That is for most parts of the programs being swapped, it should be insignificant as to the actual physical locations they are in. Without address remapping hardware, the only way this can be true is to use a memory "field" as a segment. It is insignificant which "field" a PDP 8 program is loaded in, provided that the program is self-contained in one field and does not contain any "CHANGE DATA FIELD n" or "CHANGE INSTRUCTION FIELD n" instructions. The change of "field" must now be done via calls to operating system routines. Since the particular . PDP 8/e has 2 "fields," this scheme leaves us with 2 large "segments" (or pages) with a maximum size of 4096 words. Not all 4096 words in a "field" can be allotted to a "segment," since some storage must be left for the system to reside in. Also it would be more efficient to leave a small amount of storage for commonly used variables to reside in core all the time. Judging on the size of the system and its tables, this resident (or non- swapping) region of core must be at least IK words in each "field." The question now arises as to whether the lower most IK or the upper most IK of a "field" should be resident. Since page zero (i.e., locations 0-127) is heavily used in most problem programs to store temporary variables, it is best to leave it in the segment (or swap area). So the system should reside in high core locations, i.e., locations 6000-7777 (octal) inclusive. Also locations 0-2 12 inclusive must be reserved for the system for interrupt handling, That leaves the segment size (or the swap area) to be from locations 3-5777 (octal) inclusive, a total of 3K - 3 words. Locations 16120-16337 (octal) (field 1) inclusive is the resident portion of core that is usable by any problem task. Just as the primary memory has to be separated into "segments," the secondary memory (Fabritek core boxes) also has to be segmented. The 3K - 3 PDP 8 words amounts to 511.5 Fabritek memory words. For convenience, the secondary memory segment is 512 Fabritek core words with 0.5 word not accessible in every segment. There are a total of 32 segments in each core box. Unfortunately, the hardware addresses of the two Fabritek core boxes may not be contiguous. So the segment numbers to access the two core boxes need not be contiguous either. But this hardware dependency can be taken care of easily in any problem task without any trouble, especially when most tasks use only a small fraction of a Fabritek core box. Due to the fact that these Fabritek core boxes need not be used solely for swapping programs (e.g., they are used for the scanner to digitize pictures), and that not both of them may be working perfectly at a time, it is convenient to be able to assign the core boxes at each system loading time. A virtual memory origin (displacement) is included in the system which allows the user to specify which octant (1/8) of the core box is to be used as segment 0. Also included in the system table is the number of the segment in field and 13 the segment in field 1 which is accessible by any problem task. Since the PDP 8 hardware includes data break devices which can be transmitting data while the CPU is executing another task, it is necessary to prevent the field which is used for trans- mission from being swapped out or disturbed in any way. Two entries in the system table provide this feature. Either of the 2 fields can be "locked" (or prevented from being disturbed) by a proper entry to the table. Only one of the 2 fields can be "locked" at a time, since the system requires at least one field to function properly. If both fields need to be "locked," or in other words no other task can be swapped in, it is only necessary for the problem task to disable interrupt. The algorithm of the swapping program is that it first checks to see if either of the fields is "locked." If so, it will swap the other field. If both fields are locked, the algorithm will ignore the lock bit and swap out field 1 (anyway). If neither of the fields is locked, the algorithm will keep the field that the last problem task resided in, and swap the other field. It is believed that this least-recently-used paging scheme can reduce the number of page faults. Though the transmission between PDP 8 and Fabritek core is done by a data break device and so the CPU can be doing anything else, this feature is not used for simplicity of implementation. The convention is that the program (system or problem) that initiates the transfer stays non-interruptible until the transfer is completed. Some experimentation on the particular PDP 8/e gives the transfer time for each segment 14 one way to be 14 milliseconds. So a complete segment swap requires 28 to 30 milliseconds. This is longer than the 25 milliseconds that the line printer must be able to receive 3 characters. Thus in between checking completion flags for core transfer, the system must also transmit characters to the line printer. This is the only function that is concurrent with the core transfer. It is also possible that an I/O error occurs during the transfer. In this case, the transfer is re-started. However, the I/O error can be permanent. In this case the user should be notified. Since no system or problem task is active during a segment swap, the only way to signal the error is via display lights. In this case, the contents of the console switch register is loaded into the MQ register which can be displayed on the console lights of the PDP 8/e. Probably the first thing a user notices when such a permanent I/O error occurs is that the system fails to respond to any input. A further look at the display lights can confirm this assumption. The system can be told to "ignore" this I/O error if all the keys in the switch register are set to zero. However, due to the unknown nature of the I/O error, unpredictable results may occur. 3. 2 Task Management In a multi-programming environment, the system runs a number of asychronous "processes" or "tasks" simultaneously. Each of these "tasks" can look after a simple function of the system, so as a whole all these functions seem to be performed 15 simultaneously. At any particular time, each of these tasks can be in one of 3 states. It can be actively executing, or in other words, the CPU can be allocated to this task. It can be in the ready state waiting for the CPU to be allocated to it. It can also be in the wait state in which it cannot be run until some "event" (e.g., completion of I/O transfer) has completed. For this latter case, the "task" is said to be non-dispatchable (in contrast to the former two cases when the task is dispatchable ) . At any time, it is likely that there is more than one dispatchable "task." To decide on which of these "tasks" should be run, priority is given to each of the "tasks." In a simple multi-programming system (such as the one being used) , the highest priority dispatchable task is run until either it blocks itself to wait for an "event," or another higher priority task is dispatchable. This approach is considerably simpler (and more storage saving) to implement than a time sharing system which also has to worry about execution time quanta. In order that the system can switch from one dispatch- able task to another effectively, some task status information must be saved. This set of information is saved in contiguous locations grouped into a "TASK CONTROL BLOCK" or "TCB." The system has a "TASK TABLE" which contains all these TCB's. The TCB has to contain the address of the next instruction to be executed when the task becomes active again. This consists of 2 PDP 8 words, namely the segment number and the address 16 within the segment. The TCB must also contain the last value of the accumulator. The TCB must also contain information on the dispatchability of the task. In this case, a wait count is used. This is a positive number which represents the minimum number of "events" that must be completed before the task is dispatchable. A dispatchable task has a wait count of zero. Besides these, a task has various other kinds of status also. For example, it might be useful to save the "link," the status register of the PDP 8, and the priority number of the task. However, for the purpose of saving storage, none of the above three is saved. It is found that programs very seldom use "link" or the status register. So it is not justifiable to allocate valuable system storage space for them, It is possible to use the "link" in a problem task, provided that the interrupt is disabled beforehand. A straight priority system is used for the same reason. In selecting a task to run, the system goes through the task table sequentially. So the task that is earliest in the task table has the highest priority. However, it is generally not possible to change task priority dynamically. Though the tasks in the system are asynchronous, it is sometimes necessary to synchronize with each other. There are generally 2 kinds of task synchronization. A task may want to make sure that an event has occurred before proceeding, For example, a picture processing task may want to make sure that the monitor-scanner has finished digitizing the picture before working on it. On the other hand, several tasks may 17 be contending to use a non-reentrant resource. For example, several tasks may want to access information on tape, but only one of them can use it at a time. Two system routines have been implemented to take care of this synchronization with events. They both use 2 PDP 8 words of storage as an "EVENT CONTROL BLOCK" or "ECB" to keep track of the event. The most significant 2 bits of the first word of the ECB are known as the "wait bit" and "post bit," respectively. If a task wants to ensure that an event has occurred before proceeding (or wait for the event), it can call the system routine WAIT passing the address of the ECB designated for that event to it. If the "post bit" for the ECB is zero, the calling task will be marked non-dispatchable after setting the "wait bit" in the ECB and placing the address of the TCB in the second word. The task will become dispatchable again when another task calls the system routine POST passing it the address of the same ECB, and a 2 word completion code. The post bit is then set and the wait bit is cleared, and the 2 word completion code is placed in this ECB for the awakened task to look at. A task can be waiting for a number of events at the same time by passing a wait count and the addresses of all the ECB's to the system routine WAIT. This provides maximum flexibility in programming. The method of handling contention is quite different from most systems. Instead of allowing the contending tasks to execute the code of the non-reentrant section (or the critical section) directly, an additional task known as the 18 critical section handler is used. This critical section handler is the only task that can touch the critical section. All tasks that want to use this critical section must request service from the handler. This request is done via a system routine QUEUE with the address of the parameter list to be passed to the handler. A 6 word QUEUE ELEMENT or QE must also be given to the system to keep track of the request. The last 2 words of the QE comprise the completion ECB which will be posted when the service is completed. (A STACK is actually used for simplicity in implementation.*) The requesting task can proceed to execute asynchronously with the handler, or WAIT for this completion ECB. Each critical section handler has a 6 word SERVICE ELEMENT or SE. The last 2 words comprise the request ECB. This ECB will be POSTed with the address of the parameter list as the completion code, whenever a request comes. The handler can WAIT for this ECB when a new request is needed. When finished servicing the request, the handler calls the system routine NEXTQ , which POSTs the completion ECB for the request and checks to find the next request element in the request queue. If another one is present, the request ECB is POSTed with the new parameter list. Otherwise, the request ECB is cleared. Although this contention approach results in a slightly larger number of tasks in the system, *A STACK implementation saves one swapping and simplifies coding. Since actual contentions rarely happen, this method is preferred to the more sophisticated QUEUE in light of its simplicity. 19 it has considerably greater flexibility. The handler can perform a variety of functions in between requests (e.g., open and close files). The critical section also need not use only subroutine returns; it can use coroutine returns too. It can even be written to make use of the physical characteristics of the devices. For example, a tape handler can process requests that require minimum tape motion first. 3.3 Peripheral Management There are basically 2 kinds of peripherals: the interrupt generating ones and the non-interrupt generating ones. They are handled differently in the system. For interrupt generating peripherals , when an interrupt occurs , it is necessary to sequentially check the ready flags of each of the devices in order to find out which one is causing the interrupt. Instead of placing this flag checking code in the system directly, a device table approach is used to provide maximum flexibility and adaptability of the system to other hardware configurations. The system consists of a DEVICE TABLE in which each interrupt generating device is represented by a DEVICE ENTRY. A DEVICE ENTRY is 4 words long: the first two consist of the IOT instructions for "SKIP IF READY FLAG" and "CLEAR READY FLAG" respectively. The last 2 words are the device ready ECB, which can be WAITed for via system routine call. Since the interrupt handler checks the devices sequentially, it is most efficient to place frequent interrupt- ing devices in the earlier entries of the table. 20 For non-interrupt generating devices, the approach is to check their ready flag once every short time interval. A system task which makes use of the interval timer performs this function. The task sets the timer to interrupt every 10 milliseconds (and thus makes itself dispatchable ) . When the timer expires, this system task checks each of these devices and POSTs their device ready ECBs accordingly. The timer task also provides some crude elapsed time service to other problem tasks. It consists of a timer SERVICE ELEMENT which can be QUEUEd by any task. At the conclusion of 1 second elapsed time, this timer QUEUE is cleared by continually calling NEXTQ. Requesting tasks can check the completion ECB of their QE to find out this elapsed time. (Thus error for elapsed time is on the order of 1 second. ) The timer task also keeps track of a 1 second counter (2 words long using multiple precision arithmetic) which contains the elapsed time in seconds since the system was started. This counter is accessible to any problem task. Of all the non-interrupt generating devices, the line printer is the only one that is handled differently. This is because it has the additional requirement that it has to receive service every 25 milliseconds. This makes it necessary to check the line printer ready flag by both the timer and the virtual memory swap routines. The printer is taken care of by a subroutine which directly receives REQUESTS for printing and services them. No device ready ECB is POSTed. Some flags 21 are used in this routine to record the status of the SERVICE (e.g., printer start and stop flag). To help system updating and maintenance (without reassembling all problem tasks), all non-interrupt generating device ready ECBs and various other items of system information (e.g., second counter, timer SE , etc.) are placed together in a COMMUNICATION TABLE of the system. Any problem task can refer to this table and get the system services needed. 3. 4 Device Independent (Assignable) I/O It is often useful to provide device independent I/O in a system either for the sake of convenience in use or to place a device off-line for service. The particular system we have has 2 teletypes (at different locations in the room). It is conceivable that the user finds it convenient to use a program at one of the teletypes some of the time and another one some other time. Therefore, it is necessary to enter keyboard input from either teletype and route output to either teletype, as desired. When input can come from either teletype the question immediately arises on what will happen when both keyboards are entered at the same time. The logical solution is to put the 2 characters in a QUEUE and give them to the program one at a time as if they come from the same source in that order. Thus the user can enter part of the command in one teletype, walk over to the other one and finish the command without affecting the program (task). Thus any task 22 that requires input from keyboard has an SE. When a key is struck, QUEUE will be called with the character entered in place of the address of the parameter list. A number of tasks may be requesting keyboard input at the same time. In order to decide which task to talk to first, 2 keyboard system tasks are used, one for each teletype. These tasks have 2 modes. In the command mode, simple on-line debug commands are accepted. One of the commands allows the user to enter the address of the SE to talk to. Then the keyboard will switch to routing mode in which all the keys are routed to the particular SE. The user may switch to command mode at any time and choose to talk to another SE. The typing of output on a teletype has a similar problem. Several tasks may want to output to the teletype at the same time. In order to prevent contention, 2 system tasks are used to handle teletype output, one for each typer. Each of these typer tasks has an SE which can be QUEUEd by tasks requesting output. It was decided to have the typers as character oriented devices. That is, a task requests service from the typer task independently for each character. So if two tasks want to type at the same time, their characters may inter-mix. The reason for this decision is that teletypes are full-duplex devices. The task that receives keyboard input must route it out to the typer again to echo back to the user. Therefore, it is necessary for the typer to type the character as soon as possible without waiting for 23 a line to finish. (The keyboard task itself cannot do the echoing since otherwise the user has no way of knowing the task he talks to has accepted the character. The typer tasks also cannot lock onto one task until a line is finished since otherwise the user may leave the typer in the middle of a line and thus lock the system for a long time. It is up to the user to prevent this inter-mixing of characters by limiting the number of dispatchable tasks. ) The line printer, on the other hand, is a line oriented device. The output task collects a line (maximum 127 characters, terminated by a "return" character) before requesting service via the line printer SE. The address of the line buffer is passed by the QUEUE routine. The line printer routine reserves a buffer in the resident portion of the system. The line is copied so as to minimize swapping. These input and output routines for each task are standardized via a system supplied assembly source file. This file is to be assembled together with the problem tasks. In this assembly several routines are provided. The READC routine reads from keyboard via an SE. WRITE1, WRITE2, and LPRINT output characters to typer 1, typer 2, and line printer respectively. WRITEA outputs to all three devices at the same time. WRITEC provides assignable I/O. A word in the assembly enables the user to route output to any of the above 4 routines. This word is modifiable (assignable) via command from either keyboard. 24 So as a whole, all outputs are done via QUEUE whereas all inputs are done via SE. This is a very flexible method as the output from one task is directly ("plug to plug") compatible with the input to another task. Thus it is possible to send commands to tasks from the IBM 360 or from a file instead of from the keyboards alone. 25 4. SYSTEM ROUTINES AND TABLES The system can be separated into 3 parts from the user's point of view. Direct task synchronization and virtual memory management functions are taken care of by a set of system routines callable by any problem task. These routines are non-interruptible , and thus interrupt must be disabled before calling. They reside permanently in core and are completely transparent to the "field" where the call originates. Peripherals and timer services on the other hand are handled by a number of system tasks. These tasks either pick up parameters from fixed core locations or accept input via SE ' s to perform desired I/O on the peripherals. Most of the parameters to use these system tasks are grouped together in the COMMUNICATION TABLE. The third part of the system consists of a set of assembly source subroutines to be assembled together with problem tasks. They contain address constants, subroutines to use different features of the system conveniently, and loader codes to bootstrap the problem task into core. The system uses a lot of tables and control blocks to provide the various services. The formats for these tables are fixed so that problem tasks are unaffected when a new 26 release of the system comes up. The following section will describe these routines and tables. 4. 1 Virtual Memory Routines 4.1.1 LOAD To load the content of a virtual address (segment + location) into the accumulator. If the segment is not already in core, it will be brought into core. LOAD can be used to access locations not in the swap area. In this case, any even segment number refers to field and any odd segment number refers to field 1. (Approx. 100 inst. or 0.3 ms. without swap) USAGE : 6002 /disable interrupt before call JMS I (LOAD /call LOAD routine SEGMN;L0C /virtual memory address /interrupt remains disabled upon return 6001 /enable interrupt again 4.1.2 STORE To store the contents of the accumulator in the virtual address. The accumulator is cleared at return. Conventions for addresses in a non-swap area are the same as for LOAD. (Approx. 100 inst. or 0.3 ms. without swap) USAGE : 6002 /disable interrupt before call JMS I (STORE /call STORE routine SEGMN;LOC /virtual memory address /interrupt remains disabled; ace. cleared 27 6001 /enable interrupt again 4.1.3 GOTO To transfer control to instruction at the virtual address. No swapping will be done if the address is in a non-swap area. (Approx. 68 instr. or 0.2 ms. without swap) USAGE : 6002 /disable interrupt before call JMS I (GOTO /call GOTO routine SEGMN;LOC /virtual memory address /no return; be sure to enable /interrupt at new location. 4.1.4 CALLS To transfer control with return to a subroutine at a virtual address. The return address (segment + location) is stored in the first 2 words of the subroutine. Control is transferred to the instruction at the third word. No swapping will be done if the address is in a non-swap area. (Approx. 72 instr. or 0.22 ms. without swap.) USAGE : 6002 /disable interrupt before call JMS I (CALLS /call CALLS routine SEGMN;LOC /virtual address of subroutine 6001 /enable interrupt again The subroutine at LOC may be as follows: RETN,6002 /disable interrupt before call JMS I (GOTO /call GOTO to return to caller 28 LOC, 0;0 6001 JMP RETN /reserve 2 words to store return address /enable interrupt at entry /body of subroutine here /prepare to return to caller 4.1.5 CORE MAP The layout of the system is as follows: Octal FIELD Loc FIELD 1 Interrupt handling Loc 2 Loc 3 Free for general use Problem Problem task task swap swap area area 1-SWAP Loc 5777 Loc 6000 AREA System Routine Entry System Routine Entry Task Table Communication Table Device Table Free for general use Virtual Memory System tasks Task management Loc 7577 Loc 7600 Loc 7777 1 OS/8 OS/8 The LOAD, STORE, GOTO, and CALLS routines provide all the services for problem tasks to transfer to another segment. (The accumulator is unaffected by GOTO and CALLS. ) Experimenta- tion shows that approximately 100 instructions are executed by each call to these routines if no swapping is required. This 29 amounts to around 0.3 milliseconds per call, which is not bad for GOTO and CALLS. However, it is rather slow for LOAD and STORE if a large chunk of storage is needed, since these routines work for 1 word at a time. The reason why this was implemented despite the obvious inefficiency is that it is a lot simpler to implement and to use this way. No buffering is needed (which is not true if a block transfer routine is implemented instead). If it is found that a substantial amount of information must be copied from another segment to the current one or vice versa to be worked on, the following more efficient algorithm can be used: STEP 1: Disable interrupt; initialize word counter. STEP 2: Call LOAD (or STORE) to transfer 1 word. STEP 3: Check to see if the desired segment is in the other field or not. It should be, unless the other field is " lock"ed. The interrupt is still disabled at this point. If desired segment is not in the other field (tough luck), goto STEP 2. STEP 4: Transfer the entire chunk of core directly using "CHANGE DATA FIELD n" instruction keeping interrupt disabled. STEP 5: Be sure to enable interrupt again when done. This algorithm makes use of LOAD to get the desired segment in core. Then it seizes control and transfers the entire chunk directly. It is found experimentally that the transfer time per page (128 words) is around 4 to 6 milliseconds, an interval that is tolerable in most cases. One thing to note is that it is necessary to ensure the interrupt has a chance to be enabled at least once every 20-25 milliseconds, or the 30 line printer will be extremely unhappy. Even more efficient transfer (for large chunks of core) can be done by coding core transfer IOT's directly. This possibility exists but it is still doubtful whether the need would ever arise. 4. 2 Task Management Routines and Control Blocks 4.2.1 TASK CONTROL BLOCK (TCB) TCB's are 4 word blocks for storing task status information. They are grouped together (continuous, one TCB after another) to form a TASK TABLE. Each system or problem task must have a TCB. The tasks with TCB's near the beginning of the table have higher priority than tasks with TCB's at the bottom of the table. A task may be created by entering its TCB via program control or via keyboard commands. A task is removed when its TCB entry is removed from the table. The first few entries of the TASK TABLE are taken up by system tasks. The first usable TCB starts at symbolic address UTCB in field 0. TASK TABLE: ADDRESS ENTRY UTCB TCB 1 UTCB+4 TCB 2 UTCB+10( octal) TCB 3 The maximum number of TCB's varies depending on the release of the system, but there are at least 16 TCB's available for problem tasks. TCB: ADDRESS ENTRY +0 SEGMENT (the segment where the task resides ) 31 +1 ACC (contents of the accumulator ) +2 LOC (address of first instruction ) +3 WAIT-COUNT (usually zero) 4.2.2 DEVICE TABLE ENTRY (DTE) DTE ' s are 4 word blocks for storing IOT information on interrupt generating devices. Since the hardware configuration for the system is usually fixed, the following information is given for system maintenance. The DEVICE TABLE resides in field starting at symbolic location DIVTBL. DEVICE TABLE ADDRESS ENTRY DIVTBL DTE of device 1 DIVTBL+4 DTE of device 2 DIVTBL+10 (octal) DTE of device 3 All of the existing interrupt generating devices have been included. There is room for 2 more entries for future expansion. DTE: ADDRESS ENTRY +0 SKIP IF DEVICE READY IOT instruction +1 CLEAR READY FLAG IOT instruction +2 to +3 Device ready ECB 4.2.3 EVENT CONTROL BLOCK (ECB) ECB's are used to synchronize tasks with events. They can be operated on by system routines WAIT and POST. Storage 32 for an ECB is allocated by the problem task and resides in the problem task area. ECB: ADDRESS ENTRY +0 bit WAIT bit bit 1 POST bit (event has occurred) bit 2 to 11 , Completion code if posted, an A(TCB)+3 if waiting +1 bit to 11 An ECB cannot start at location 0. It can reside in a non-swap area. This usually saves swapping time. However, if this is chosen, then it must reside entirely in the non-swap area; i.e. , it is illegal to have 1 word of an ECB in a swap area and another word in a non-swap area. 4.2.4 QUEUE ELEMENT (QE) A QE is used to request service from a critical section handler. It is allocated by the requesting task. This block of 6 words will be used by the system as long as the request is still in the queue. (A STACK is acually used. Two tasks can seize control of the handler!) A QE can reside in a non- swap area but the same restriction as for an ECB also holds for a QE. QE: ADDRESS ENTRY +0 to +1 A (next QE in stack) +2 to +3 A (parameter list) +4 to +5 Service complete ECB The first 4 words will be automatically maintained by the system. The user need only be concerned about the completion ECB. 33 4.2.5 SERVICE ELEMENT ( SE ) An SE is used by a critical section handler to obtain requests from other tasks. It consists of 6 words which can reside in a non-swap area. The same restriction for a QE applies to an SE. The first 4 words of an SE are maintained by the system. The user need only be concerned with the REQUEST ECB. This, when POSTed, has a completion code equal to the address of the parameter list passed from the requesting task. SE : ADDRESS ENTRY +0 to +1 A (top QE of request stack) + 2 to +3 A(QE currently under service) +4 to +5 REQUEST ECB 4.2.6 POST Routine To signal the completion of an event. If the wait bit of the ECB is 1, the waiting process wait count will be reduced by 1 (unless it is zero already). In any case the post bit is set and the completion code is placed in the ECB. Interrupt is enabled upon return from POST. The contents of the accumulator are unaffected. (Approx. 200 instr. or 0.6 ms. without page fault) USAGE: 6002 /disable interrupt before call JMS I (POST /call to POST routine SEGMN;LOC /A (ECB) to be posted CC1,CC2 /completion codes /interrupt is enabled here 34 4.2.7 WAIT Routine To wait for the completion of a number of events. WAIT accepts a variable number of ECB's as its parameter. The ECB list is terminated by an address with a zero in the location portion. (That is why an ECB cannot start at location 0.) The wait count (non-zero) is used to specify the minimum number of events that have to occur before the task can be awakened again. (Hopefully this is not larger than the number of ECB's in the list, or the task deadlocks itself.) Normally the post bit of the ECB should be cleared before the WAIT. If the post bit is 1 for any of the ECB's in the list, the event is assumed to have occurred, and the wait count is reduced by 1. That particular ECB remains unchanged. The contents of the accumulator are unaffected by this call. (Approx. 154+74N instr. without swap. 2 ECB = 0.85 ms. ) USAGE 6002 /disable interrupt before c^ll JMS WCNT SECB1;LECB1 SECB2:LECB2 I (WAIT /call wait routine /wait count /A (ECB 1) /A (ECB 2) ANYTHING ; /as many as 7 ECB's may be included /end of parameter list /interrupt is enabled before return /be sure to clear the "wait" bits of all the ECB's at this point 35 4.2.8 QUEUE Routine To request service from a critical section handler. A QE must be supplied to the system to keep track of the request. QUEUE will maintain this QE including the automatic clear of the completion ECB. The requesting task thus can proceed or wait for this ECB. The restriction to this QE is that it must not be already in use by the system. Otherwise unpredictable results may occur. The contents of the accumulator are unaffected by the call. USAGE: 6002 /disable interrupt before call JMS I (QUEUE /call queue routine SESEG;SELOC /A ( SE ) PARMSG;PARMLC /A (parameter list) QESEG;QELOC /A ( QE ) /interrupt enabled at return /process asynchronously here /wait for completion ECB here to be sure it is serviced 4.2.9 NEXTQ Routine To signal the completion of service for the present request and to obtain the next request from the request stack. An SE must be supplied to the system to keep track of requests. NEXTQ will maintain this SE including the clearing and posting of the request ECB. The accumulator is unaffected by this call. The value of the accumulator is used as the completion code for the service ECB. 36 USAGE: 6002 /disable interrupt before call JMS I (NEXTQ /call nextq routine SESEG;SELOC /A ( SE ) 4. 3 Communication Table The communication table contains system variables and parameters, which problem tasks may refer to and may change. It resides in field 1. Pointers are also used to enable tasks to access field variables. ADDRESS WTSE1 (6 words WTSE2 (6 words LPSE (6 words CLKSE (6 words EPTR (2 words ETAPE (2 words ESMV (2 words ERIBMS(2 words ERIBMD(2 words EWIBMS(2 words EWIBMD(2 words TIME1 (2 words ENTRY Teletype 1 typer SE (character oriented) Teletype 2 typer SE Line printer SE ; A (line buffer used) 1 second clock SE High speed paper tape reader ready ECB Tape error ECB; POSTed whenever Linctape error bit is on. (Program timing error is one of the causes for it. ) Scanner monitor ready ECB IBM 360 read select ECB IBM 360 read complete ECB IBM 360 write select ECB IBM 360 write complete ECB Elapsed time in seconds (multiple precision arith. ) HWLX Hand wheel X reading HWLY Hand wheel Y reading AFILDO Pointer to a word in field which contains the segment number of the segment that is currently in field 37 AFILD1 Pointer to a word in field which contains the segment number of the segment that is currently in field 1 ALCKFO Pointer to "field lock flag" in field 0. If this flag is non-zero, field segment is locked in core. ALCKF1 Pointer to "field 1 lock flag" in field ATCBPT Pointer to a word in field which contains the address of the current TCB AORGVY Pointer to the virtual memory origin word in field 0. User can choose which octant of the core box is segment by entry to this word. Directly following the communication table is a block of 220 (octal) words which are free to be used by any problem task to store variables and control blocks. 4.4 UTILITIES The UTILITIES comprise a set of assembly source sub- routines to be assembled together with problem tasks. It also contains definitions for symbolic addresses, so that the references referred to in this paper may be used in coding problem tasks. A bootstrap loader is included to load problem tasks into virtual memory locations. During assembly, the literal SEGMT must be specified. This is the segment number (> 2) in which the problem task is going to reside. All the codes for the problem task must be assembled in field 1 for the loader to function properly. If a problem task requires more than 1 segment of storage, then it is necessary to assemble it a segment at a time. The routines in UTILITIES take up 2 pages of core, the last of which is used for the 38 line printer buffer. These routines are neither reentrant nor recursive. 4.4.1 READC Routine To get one character from a keyboard type device. The character will be returned in the accumulator as well as stored in the symbolic location CHAR. The SE used in getting the character starts at the second word (RDSER) of the page into which the UTILITIES are assembled. USAGE: JMS I (READC /echo character here using write routines TAD I CHAR /pick up the character again if needed 4.4.2 LPRINT Routine To output one character to the line printer by first collecting it in the buffer. A RETURN character terminates a line and initiates the printing process. This routine obtains the character from the accumulator. At return the accumulator is cleared. USAGE: JMS I (LPRINT /print character in accumulator 4.4.3 WRITEA Routine To output the character in the accumulator into both teletype typers and the line printer simultaneously. The accumulator is cleared at return. This is used mainly for important messages that require attention. USAGE: JMS I (WRITEA /output character from ace 39 4.4.4 WRITEC Routine To output the character in the accumulator to an assignable device. The word WRITAC at the first location of the page into which UTILITIES is assembled contains the address of the output routine to be used by WRITEC. In addition to LPRINT and WRITEA , WRITE1 and WRITE2 are also available which output to teletype 1 and teletype 2 respectively. The accumulator is cleared upon return. USAGE: JMS I (WRITEC /output character to console 40 5. EXISTING SYSTEM AND PROBLEM TASKS The present release of the system has a number of tasks running under it. Most of these tasks perform system functions and are transparent to the user. They have been discussed in previous sections. This section is concerned with tasks that are directly usable by the user. It must be pointed out that most of these are crude implementations mainly for testing (and illustrating) the different features of the system. More sophisticated implementations of these tasks will be done in later releases. 5. 1 Keyboard Monitor Task The keyboard monitor task enables the user to enter commands and data through the teletype keyboards. There are 2 keyboard tasks, one for each teletype. Though the commands for these 2 tasks are almost the same, they are not identical. One of the teletypes is assigned to be the operator console. It recognizes 2 additional commands. The operator may "hold" (keep other tasks from executing) all tasks. The operator may also terminate the system by transferring control to OS/8 system. Due to the fact that it is necessary for the operator to be able to "hold" all tasks and examine them, no matter what disastrous bug has happened, the keyboard is active all the time (except when an I/O error occurs during swapping). 41 That is, if the keyboard is routing characters to problem tasks, it keeps on accepting new keystrikes , no matter whether the problem task has a chance to examine them. (The problem task may have a bug and deadlock itself. ) After receiving the keystrike , if it is found that the problem task is not ready for a new character, the character is thrown away. So some characters may be lost. Thus, it is not reliable to read paper tapes at the operator console. Paper tape reading is thus disabled. (The problem task can enable this feature if needed.) The regular (other) keyboard task does not have the "hold" command. Thus, it can afford to wait until the problem task has a chance to examine the previous character before looking at the new keystrike. Reading of paper tape is therefore permitted at the regular teletype. Another distinction is that the operator console task resides in the system area, and so it is in core all the time. This again is due to its importance in debugging. Both keyboard monitor tasks operate in 2 modes. The "\" command switches them to the command mode. In this mode, the tasks accept simple debug commands. The "nQ" command switches them to routing mode. In this mode, keystrikes are routed to problem tasks. The following is a repertoire of their commands: nnnn/ To display the content of a virtual address. Octal base is used. nnnn may be any number of digits. The last 4 digits are used as the location, the next 4 digits are used as segment number. All extra leading digits are ignored. Zeroes are packed on the left if less than 8 digits are entered. 42 vvvv= To replace the contents of the location displayed by the previous nnnn/ command with the value vvvv. Only the last 4 digits are used as value. Octal base is used. ssssQ To switch to routing mode by talking to the SE at location (segment + location) ssss (octal). If ssss is zero, the address of SE for the previous Q command is used. Q also releases all tasks. \ To switch to command mode. "\" is not routed to the problem task. A \ character will be typed on the left margin when the monitor is in command mode. H To "HOLD" all tasks. This command only works at the operator console. CONTROL-C To terminate the system by transferring tC control to 7600 (octal), i.e., OS/8 system, This command only works at the operator console, and only after the "H" command has been issued. 5. 2 Scanner Task The scanner task assembles the scanner parameters and activates it to either digitize or display a picture con- tinuously on the display monitor. This task does not check the validity of the parameters. If the scanner gets an illegal parameter, it will abandon the scan and the beeper will sound. The scanner task, after finding that the scanner completion flag has not been raised within 2 seconds will re-activate the scanner again to allow the user to have a chance to change the parameters. Other than the physical beeper, there is no way the software can detect the abandoning of the scan. This is due mainly to hardware restrictions (there is no IOT to detect this) rather than software implementation. To allow problem tasks to synchronize with 43 the scan, the scanner task calls a subroutine before assembling the parameters to activate the scanner for another scan. The entry point of this subroutine is alterable by problem tasks. Thus any problem task that wants to use the scanner can assemble a subroutine and give its entry point to the scanner task. When the system is first started, a dummy subroutine is used which takes the readings of the handwheels as the starting coordinates for the scan. The problem task may of course supply subroutines to fix the parameters in any other way. ADDRESS ENTRY CORNO Device number for Fabritek core box to be used by the scanner in bits 4 to 8 (inclusive), All other bits should be zero. The scanner starts using the core box from location 0. SCDPY If zero, then digitize the picture and put it in the core box. If non-zero, display the picture from the core box. MAG The last 3 bits specify the magnification of the picture on the display with the power equal to 2 ** MAG. ROTAT The least significant bit specifies whether to digitize the picture along the X axis or along the Y axis. An entry of 1 means to scan along the Y axis (i.e., same orientation as the film). XSIZE The least significant 3 bits specify the step size between digitize points. One out of 2 ** XSIZE points are digitized on the X axis (vertical on the film). YSIZE Y step size for digitizing films. XBEGIN X coordinate to start the digitizing process. The coordinate runs from to 7777 (octal). XBEGIN must be greater than or equal to 20 (octal) and must be a multiple of the number of points used in the X step size. It must also be such that enough room is left on the right for the scanner to complete its scan. YBEGIN NUMX NUMY 44 The corresponding Y begin point. The total number of digitized points for the picture on the X axis. This must be odd to use interlace scan. The number of digitized points on the Y axis. This also must be odd to use interlace scan. +41 (octal) Address (segment + location) of parameter (2 words) fixing subroutine. It can be used for synchronization purposes. +170(octal) If bit 4 is 1 , interlace scan is used, normal scan otherwise. The scanner task uses 3 pages of storage. 5. 3 OPT (Octal Debug Technique) Task A 1 field version of the DEC ODT program is included in the system. The modifications mainly lie in intercepting the ODT teletype I/O IOT's with the standard system READC and WRITEC. The ODT itself uses locations from 4 to 5 and from 200 to 1577 (octal). Location 1600 to 5777 (octal) are usable for experimenting programs. The keyboard input SE is at location 401. Most of the commands of the original ODT are operational, except the "P" command which causes the computer to halt. ODT may be restarted at location 200 (octal). The reader is referred to DEC literature on ODT commands. 5.4 Text Editor Task A 1 field version of the DEC symbolic editor is also operational. The modifications are almost the same as those of ODT. The difference is in the smaller size of the text buffer due to storage taken up by READC and WRITEC routines. 45 Location 2 in field 1 should be set to 5400 (octal) when the editor is used. Also the switch register should be set properly as mentioned in the DEC literature. The keyboard SE is at 5401 (octal). The symbolic editor may be restarted at location 200 (octal). 5. 5 Microscope Stage Task The microscope stage task is completely experimental in nature. It does nothing but rock the stage left and right on the X axis. This task sets an example on how to use the stage when a more sophisticated program is to be implemented. 5.6 Line-tape Task The Line-tape task is also experimental in nature. It rocks Line-tape from block 200 to 2000 (octal) without reading it. However, it illustrates an important concept in using the tapes. As mentioned previously, the Line- tape controller can search for a particular block automatically. But once the block is found, the CPU must perform I/O at the rate of 1 word every 122 microseconds. This is too fast for the system, especially since the Line-tape controller does not generate an interrupt. Therefore, the only way is to make the I/O task non-interruptable during the transfer (after making sure the line printer has finished one line). The actual transfer time per block is only a fraction of a second. This is not too bad, if it were not for the lengthy period of time (half a minute) to search for the block. Since there 46 is no way to tell when you are close to the desired block, the only way is to search for a block close by. When the block is found and no I/O is done within 0.122 milliseconds, the program timing error flag will come on. This will cause ETAPE, the tape error ECB, to be POSTed. Thus the task can wait for this ECB. When the tape is at the neighborhood of the desired block, only a fraction of a second is needed to search for the actual block and transfer the data. 5. 7 Display Task The display task is a dummy task that reads the address from the switch register and displays its contents by loading it into the MQ register. This task is the lowest priority task in the system. Since the PDP 8/e does not have a wait state, it must be executing all the time. Whenever the system runs out of tasks to execute (i.e. , none of the other tasks are dispatchable ) , this display task is dispatched. So it represents the wait state of the system. The non-interrupt bit of the status register will be on whenever this task is active. Thus this bit on the display light can give an indication of the percentage of wait time. Perhaps more should be included in this dummy task in later releases to record other system measurements. For example, if the system stays in the wait state for a long time, it is an indication of a possible deadlock. 47 6. IBM 360 INTERFACE Though sophisticated IBM 360 communication tasks have not been implemented in the present release, it probably will be the most important part of the system in the future when picture processing is done. A block-transfer cycle-stealing data break device is used for the communication. Since it transmits a buffer at a time, this task must collect commands and data into a buffer before sending it to the IBM 360. When a buffer is received from the IBM 360, it is also necessary to unblock it into separate commands and data to be routed to different tasks of the system. After a buffer has been collected, the general procedure to transmit it to the IBM 360 is as follows: STEP 1: Issue "ENABLE IBM 360 READ INTERRUPT" IOT STEP 2: Wait for IBM 360 program to be ready to receive the buffer by a WAIT to ERIBMS ECB. (Be sure to clear the POST bit before hand, i.e., before step 1.) STEP 3: Lock the field of the buffer in core. This is necessary because the CPU can be executing while transmission is going on. The buffer field cannot be disturbed (or be swapped out). STEP 4: Issue IOT's to start the transfer. STEP 5: Wait for the completion of the transmission by a WAIT to the ERIBMD ECB. (Be sure to clear it before hand. ) STEP 6: Don't forget to unlock the buffer field afterwards. 48 The method for obtaining a buffer from IBM 360 is similar, with a slight difference. It may not be possible for the PDP 8/e to know when the IBM 360 is ready to send a buffer. Therefore, the "ENABLE IBM 360 WRITE INTERRUPT" IOT must be issued as soon as possible, that is, as soon as the previous buffer has been disposed of. STEP 1: (Perform as soon as possible) Issue "ENABLE IBM 360 WRITE INTERRUPT" IOT. STEP 2: Wait for IBM 360 program to be ready by WAIT for EWIBMS. STEP 3: Lock buffer in core. STEP 4: Issue IOT to start transfer. STEP 5: Wait for completion of transmission by WAIT to EWIBMD. STEP 6: Don't forget to unlock the buffer field. The IBM 360 interface hardware is not a full duplex device. It can either send or receive at a time, but not both. Therefore, it is not correct to use 2 tasks to handle send and receive separately. Only 1 IBM 360 I/O task should be used. This task after enabling the IBM 360 write interrupt, WAITs for one of 2 events: either IBM 360 is ready to send a buffer (EWIBMS) or the PDP 8 is ready to send a buffer. If both occur at the same time, the IBM 360 sending has a higher priority. Since the IBM 360 interface does not generate interrupt, the ECB's are only POSTed by the interval timer task. Therefore, it is possible that the IBM 360 send request occurs earlier in time than when the PDP 8 is ready to send, but was noticed later by the software. In all circumstances, 49 only one of the ERIBMS and EWIBMS ECB's can be POSTed at a time, and this is the one to be used to decide on the correct action. The communication between the PDP 8/e and the IBM 360 cannot be done on the PDP 8 end alone. The IBM 360 must also have a program (JOB) that will accept and interpret the data. There has to be close agreement in the way of packing the buffer for both programs. The reader is referred to the paper "A System Monitor for Programs in Artificial Intelligence" by the same author for a reference to the possible designs of the communication programs on the IBM 360 end. 50 7. HOW TO GET INTO A SPECIFIC FIELD Some programs (though not many) only work when the segment is loaded into a specific field. For example, a "device handler" of the OS/8 system can only be loaded into field 0. Therefore, it may be necessary to switch the segment to another field some of the time. The program can determine whether it is in the right field by a "READ INSTRUCTION FIELD" IOT. If it is found to be in the wrong field, it can call the system routine FLDCH via CALLS. If the other field is not locked, the program now should end up in the desired field. Otherwise, the best way is to WAIT a second before trying again until the other field is unlocked. This field switching uses a lot of swapping time and thus should be used very seldom. STEP 1: Issue disable interrupt IOT. STEP 2: Check if program is in desired field using "READ INSTRUCTION FIELD" IOT. If in right field, then go to STEP 6. STEP 3: Attempt to switch field by the following code : JMS I (CALLS /call CALLS routine 0; FLDCH /A (field switch routine) /interrupt remains disabled here STEP 4: Check if program is in desired field again. If so, go to STEP 6, otherwise be sure to enable interrupt again. 51 STEP 5: Set up code to wait for 1 second, i.e., make use of CLKSE. At the end of the second, go back to STEP 1 and try again. STEP 6: Interrupt is still disabled at this point! Either proceed with interrupt disabled with the problem program, or lock the field and enable interrupt again. The latter is preferred. 52 8. HOW TO USE OS/8 SUPPORT The system runs as a "JOB" to the OS/8 system. There- fore, it is possible to use the various features of OS/8 also. The user is referred to the DEC literature for how to interface with OS/8. One of the things that should be noted is that the interrupt must be disabled before going into OS/8. It can be enabled again when OS/8 returns to the calling program. However, the period inside OS/8 may be longer than the critical 25 milliseconds. Therefore, it may be necessary to ensure that the line printer is not busy before doing so.* Some of the features of OS/8, e.g., device handler, can only be used in field 0. The method suggested in the previous section can be used to ensure the calling program to be in field 0. *One of the methods to clear the line printer is to cause the system to swap segments continuously, since with the interrupt disabled, none of the other tasks are active, but the printer is still printing during the swaps. The line printer takes around 1 second (40 to 60 swaps) to finish the line it was printing before. 53 9. CODING NEW TASKS TO THE SYSTEM The coding of new tasks for the system is very similar to the way assembly programs are coded in OS/8. The regular OS/8 text editor and assembler are used. There are a few restrictions that the programmer has to bear in mind. (a) The system only saves the accumulator at interrupt. Therefore, if the "link" or any of the other registers, or "CHANGE DATA FIELD" IOT is used, that section of code must be non-interruptable (i.e., with interrupt disabled). None of the system routines save these registers either. The program can save them before the call. (b) The virtual memory system handles one segment at a time. The bootstrap loader also loads one segment at a time (i.e., loc 3 to 5777 (octal)). If the task requires more than one segment of storage, isolate them and assemble a segment at a time. Use LOAD, STORE, GOTO, CALLS to communicate between segments. Make good use of the small block of storage resident in core for general use (non-swap area) . (c) Let the system handle hardware device flags. Use the supplied ECB's instead of actual IOT's to check device status. Use standard system I/O routines READC and WRITEC , etc. 54 (d) Find an available segment (greater than or equal to 2) in which to place the task and specify it in SEGMT. (e) Decide on the priority of the task and find an empty spot for its TCB. Then enter its TCB at run time through keyboard commands. A very simple task is used to illustrate exactly the procedure used (see Figure 2a-g). This task accepts a character from the keyboard and echoes it twice. The first time it types the character entered. Then it is followed by the next character in the collating sequence. That is, if "A" is struck, it echoes "AB" on the typer. The segment number is arbitrarily chosen to be 3. The example assumes OS/8 has just been bootstrapped in. The reader is referred to DEC literature on OS/8 commands. The reader is reminded that though the example only illustrates the coding of a new task, the principle is similar in modifying existing programs to run under the system, if the above rules are obeyed. 55 .R EDIT (Use Editor to enter the program. ) *EXAMPL. PA- #A /ECHO KEY PROGRAM SEGMT-3 /CHOOSE SEGMENT TO PUT PROGRAM *UTCB+3j# /CHOOSE FREE TCB FOR THE TASK SEGMT;0;ECHO;0 /ENTER TCB FOR THIS TASK FIELD 1 /ASSEMBLE PROGRAM IN FIELD 1 *2.pf) /START ASSEMBLY AT LOCATION iftZfifi ECHO, JMS I (READC/GET CHARACTER FROM CONSOLE TTY JMS I (WRITEC/ECHO THE CHARACTER TO CONSOLE AGAIN TAD I (CHAR /PICK UP THE CHARACTER AGAIN IAC /INCREMENT TO GET NEXT CHAR. IN COL. SEQ. JMS I (WRITEC/WRITE THE CHARACTER ALSO JMP ECHO /GO BACK TO GET ANOTHER CHARACTER PAGE /END OF PROGRAM, UTILITY FOLLOWS (NEW PAGE) #E .R PALS (Assemble the program with UTILITIES routines. ) *EXAMPL, LPT :<-EXAMPL, UTILITY/S UO +ft.fif) .RABSLDR (Use the Loader to create OS/8 core image file.) * SYSTEM. SV/I *EXAMPL$ .SAVE SYS EXAMPL . R EXAMPL (Bootstrap program in virtual memory. ) .R SYSTEM (Start the new system.) \H (Hold all tasks to insert new TCB of the program. ) \6llk/fifififi \3= \6ll6/fi23fi \2pp= \6l2.7/fifipp \3j#4-j#lQ (Talk to the new program by specifying its SE. ) ABL2igBC78P0WXIMYZFG\ \t "~~^typed on keyboard (We are back to OS/8 again. ) Figure 2a. Echo Key Program Teletype Input 56 /ECHO KEY PROGRAM PAL8-V7 ±/lk/7h PAGE 1 /ECHO key program 0003 SEGMT=3 /CHOOSE SEGMENT TO PUT PROGRAM 6llk *UTCB+30 /CHOOSE FREE TCB FOR THE TASK 06lll+ ppp3> SEGMT;0;ECHO;0 /ENTER TCB FOR THIS TASK 06115 06n6 06117 /ASSEMBLE program IN FIELD 1 /start assembly at location 10200 10200 1+777 ECHO, JMS I (READC/GET CHARACTER FROM CONSOLE TTY 10201 1+776 JMS I (WRITEC/ECHO THE CHARACTER TO CONSOLE AGAIN 10202 1775 TAD I (CHAR /PICK UP THE CHARACTER AGAIN 10203 7001 LAC /INCREMENT TO GET NEXT CHAR. IN COL. SEQ. 10201+ 1+776 JMS I (WRITEC/WRITE THE CHARACTER ALSO 10205 5200 JMP ECHO /GO BACK TO GET ANOTHER CHARACTER 10375 10376 10377 /END OF PROGRAM, UTILITY FOLLOWS (NEW PAGE) 0200 0000 0001 FIELD 1 0200 *200 ^777 ECHO, JMS I 1+776 JMS I 1775 TAB I 7001 LAC ^776 JMS I 5200 JMP Ei 05^3 01+07 01+12 01+00 PAGE Figure 2b. Echo Key Main Program /VOS SYSTEM VARIABLES PAL8-V7 l/l4/74 PAGE 2 /VOS SYSTEM VARIABLES 6000 POST=6000 6004 WAIT-6ppU 6010 GOTO =6010 60l4 CALLS=60l4 6020 LOAD=6020 600 U STORE=6024 603)25 NEXTQ=6030 . 6034 QUEUE=6034 6212 EHWL=6212 6232 EKB2=6232 6236 ESCP-6236 6242 EUNK=6242 0207 FLDCH=207 /FIELD 1 VARIABLES 6040 WTSEl=l6040 6046 WTSE2=i6046 6054 LPSE=l6054 6062 CLKSE- 16062 6070 EPTR= 16070 6072 ETAPE=l6072 6074 ESMV=l6074 6076 ERIBMS=l6076 61025 FRIBMD=l6l00 6102 EWIBMS=l6l02 6.104 FWlBMD=l6l04 6106 TIMEl=l6l06 6107 TIME2 -16107 6110 HWLX=l6ll0 bill HWLY=l6lll /ADDRESS OF FIELD VARIABLES 6112 AFILD0=l6ll2 6113 AFILDl=l6ll3 6114 ALCKF0=l6ll4 6115 ALCKFl-16115 6116 ATCBPT=l6ll6 6117 AORGVY=l6ll7 6377 IASTUA-I6377 /LAST LOCATION OF NONSWAP AREA 6120 NONSWP=l6l20 6064 UTCB=6064 /CURRENT FIRST FREE TCB / \ , /SUB- ROUTINES TO WRITE /SEG-MT MUST HAVE BEEN DEFINED AS CURRENT SEGMENT /READC GETS CHARACTER FROM CONSOLE KEY-BOARD AND RETURNS /IT IN ACC. AND CHAR /LPRINT GOES TO LINE PRINTER /WRITEA GOES TO TTY AND PRINTER /WRITEC GOES TO CONSOLE(ASSIGNABLE) TTY /ACC. CONTAINS CHARACTER, CLEARED AT RETURN 0400 PAGE 10400 0433 WRITAC, WRTTE1 /A( CONSOLE WRITE ROUTINE) Figure 2c. Echo Key Program Symbolic Address Definition 101+01 0000 10402 0000 101+03 0000 101+01+ 0000 101+05 0000 101+06 0000 101+07 0000 101+10 4600 101+11 5607 101+12 0000 101+13 6002 101+11+ 4777 101+15 0001 0003 101+16 101+17 0405 101+20 0000 101+21 0000 101+22 7300 101+23 1206 101+21+ 3343 101+25 1343 101+26 6002 101+27 4776 101+30 0003 101+31 0401 10432 5612 101+33 0000 10434 3251 10435 6002 101+36 4777 10ii37 0001 101+1+0 0003 101+41 0551 101+1+2 0000 101+1+3 0000 101+44 6002 10445 4775 10446 0001 10447 6040 10450 pm 10451 0000 10452 0003 10453 0545 10454 5633 /VOS SYSTEM VARIABLES PAL3-V7 l/l4/74 PAGE 2-1 RDSER, 0;0;0;0;0;0 /READ ROUTINE SE WRITEC, JMS I WRITAC JMP I WRITEC L. 6002 JMS I (WAIT l;SEGMT;RDSER+4;0;0 CIA CLL TAD RDSER+5 DCA CHAR TAD CHAR 6002 JMS I (NEXTQ SEGMT; RDSER JMP I READC \ , WRITE1, DCA WRITC1 6002 JMS I (WAIT l;SEGMT;WRTQEl+4;0;0 52 JMS I (QUEUE 1;WTSE1;0 WRITC1, 0;SECMT;WRTQE1 JMP I WRITE1 'l I Figure 2d. Echo Key Program Teletype Read/Write Routines 59 /VOS SYSTEM VARIABLES PAL8-V7 l/lk/lk PAGE 2-2 101+55 101+56 101+57 101+60 101+61 101+62 101+63 101+61+ 101+65 101+66 101+67 101+70 101+71 101+72 101+73 101+7^ 10U75 101+76 101+77 10500 10501 10502 10503 10501+ 10505 10506 10507 10510 10511 10512 10513 105 lU 10515 10516 10517 10520 10521 10522 10523 10521+ 10525 10526 10527 10530 10531 10532 10533 / 0000 WRITE2, 3273 DCA WRITC2 6002 6002 U777 JMS I (WAIT 0001 l;SEGMT;WRTQE2+l+;0;0 0003 fel 0000 00^ 6002 6002 1+775 JMS I (QUEUE 0001 1;WTSE2;0 001+6 0000 0000 0003 WRITC2 , 0; SEGMT ;WRTQE2 0553 5655 1 JMP I WRITE2 /LINE PRINTER ROUTINE 0000 LPRINT, fr 37!+l+ DCA I LBFPT 17I+1+ TAD I LBFPT 1371+ TAD (-215 /- 7650 SNA CIA 5312 JMP LPWT 131+1+ TAD LBFPT 23I+I+ TSZ LBFPT 1373 TAD (-ENDLP 761+0 SZA CIA /BUFFER OVERFLOW ? 5677 JMP I LPRINT 1372 LPWT, TAD (LPBUF 33U1+ DCA LBFPT 6002 6002 1+775 JMS I (QUEUE g$ 1 ; IPSE ; SEGMT ; LPBUF ; SEGMT ; LTQE 0003 0600 0003 0561 6002 6002 1+777 JMS I (WAIT 0001 0003 0565 1; SEGMT ;LTQE+l+;0;0 0000 0000 5677 * JMP I LPRINT Figure 2e. Echo Key Program Line Printer R< 60 /VOS SYSTEM VARIABLES PAL8-V7 1/14/7^ PAGE 2-3 1053^ 0000 WPJTEA, 10535 i+233 JMS WRITE1 1^536 1251 TAD WRITC1 10537 ^255 JMS WRITE2 105^0 L273 TAD WRITC2 105U1 U277 JMS LPRINT 105^2 573^ JMP i writ: I 105^3 0000 CHAR, /CHARACTER FROM CONSOLE 105 kh fityfi LBFPT, LFBUF 105^5 0000 WRCQEL, 0;0;0;0;2000;0 105^6 105^7 0000 10550 10551 2000 10552 0000 10553 0000 WRTQE2, 0;0;0;0;2000;0 105 5*+ 0000 10555 10556 10557 10560 10561 0000 LTQE, 0;0;0;0;2000;0 10562 00j 10563 105 6i+ 10565 10566 10572 10573 7002 1057^4 7563 10575 603^ 10576 6030 10577 600U 0600 PAGE /LINE PRINTER BUFFER 10600 0000 PBUF, 0776 *LPBUF+176 10776 0000 ENDLP, PAGE 0200 *200 /LOADER^LOAD PROGRAM IN FIELD1 INTO VOS CORE /NOT APPLICABLE FOR SEGMT=0 OR 1 00200 7^02 HLT Figure 2f. Echo Key Program QE and Line Buffers 61 /VOS SYSTEM VARIABLES PAL8-V7 k/lG/lk PAGE 1-1+ 00201 00202 00203 00201+ 0^205 00206 00207 002 10 00211 00213 002ii+ $5215 002 16 00217 00220 00221 00222 00223 00221+ $£25 00226 #0227 00230 00231 00232 00233 0023*+ 00235 $236 00237 0021+0 0021+1 002 1+2 0)2521+3 0021+1+ 0021+5 0021+6 0021+7 00250 00251 00252 00253 002 5 1+ 00255 00256 00372 00373 0037U 00375 00376 00377 6007 6007 6211 6211 /CDF FIELD 1 1777 TAD I (ALCKF0 3255 DCA LLCKF0 1776 TAD I (AFILD1 3256 DCA LFILD1 6201 6201 /CDF 2655 ISZ I LLCKF0 /LOCKS FIELD SEGMENT IN CORE 1375 TAD (SEGMT 3656 DCA I LFILD1 /INSERT PROGRAM SEGMENT NUMBER 1+77^ JMS I (LOAD 0001 SMN1, SEGMT-1 ;200 0200 6007 6007 6212 6212 /CIF FIELD 1 ^773 JMS I (7700 /CALL TO USR 0001 1 /FETCH DEVICE 2331 DEV, DEVICE SYS /SYSTEM DEVICE 2300 1001 HENTR, 1001 /LOAD AT LOC 1+00 (2 PAGES) 5772 JMP I (7600 /BACK TO OS8 IF ERROR 6017 6007 12 lU TAD SMN1 /SEGMENT -1 7002 7002 /BSW 1253 TAD FILPTR+2 3253 DCA FILPTR+2 1223 TAD DEV+1 6212 6212 /CIF FIELD 1 ^773 JMS I (7700 0002 2 /LOOK UP FILE 0251 FILE, FILPTR 0000 LENG, 5772 JMP I (7600 /BACK TO OS8 AT ERROR 6007 6007 0237 TAD FILE /START BLOCK 3250 DCA PRGST 6212 6212 /CIF FIELD 1 ^773 JMS I (7700 0016 6 /CHAIN TO PROGRAM 0000 PRGST, /START BLOCK 11+17 FILPTR, FILENAME LOAD0.SV ^ift 6000 2326 ',* Wl LLCKF0, i 0000 LFILD1, 7600 7700 6020 0002 6113 6lll+ Figure 2g. Echo Key Program VOS Loader 62 10. REMARKS Though the system was written in a hurry and some of the tasks are only crudely coded, it illustrates an extended and more powerful application to the existing hardware. Both simultaneous processing and large amounts of storage are offered, which are essential for picture processing. Based on the experiments performed so far, the system performance is quite high. Both teletypes can be used by 2 users with the line printer still printing another program, without any noticeable slow down in response time in comparison to a mono-programming situation (e.g., OS/8). Surprisingly, the system is not thrashing most of the time, in contrast to what some would expect. It is because the swapping is fairly fast and the programs have been carefully organized in each segment. From these trial runs, it can be expected that the system would have no trouble running enough programs to fully (100%) utilize all the peripheral devices, which is the maximum (theoretical limit) the hardware can offer. A lot more software is still needed to make the system convenient to use. More sophisticated text editors and high level language interpreters and compilers have to be coded before the system can be used to its fullest extent. These, no doubt, will be coded in the future releases when the system is heavily used by programmers. 63 BIBLIOGRAPHY Bull, G. M. and Packhan, S. F. G. , Time- Sharing System , London, New York, McGraw-Hill, 1971. Katzan, Harry, Operating System, A Pragmatic Approach , Von Nostrand Reinhold Company, 1973. Knuth , Donald E., The Art of Computer Programming , Vol. 1, Addison-Wesley Publishing Company, 1968. Small Systems Software Documentation Group, Digital Equipment Corporation, "Introduction to Programming," PDP-8 Handbook Series, 1973. Software Documentation Programming Department , Digital Equipment Corporation, " PDP 8/e PDP 8f Small Computer Handbook," PDP-8 Handbook Series, 1973. The Software Writing Group, Programming Department, Digital Equipment Corporation, "Programming Languages, PDP-8 Family Computers," PDP-8 Handbook Series, 1973. Wong, Tze-Wah, "A System Monitor for Programs in Artificial Intelligence," Report Number UIUCDCS-R- 74-639 , Department of Computer Science, University of Illinois, Urbana, Illinois, May 1974. Wong, Tze-Wah, "A (Semi-) Virtual Memory Multi-Programming System for the Mini-Computer PDP 8/e (ILLIAC-3) Program Listing," File Number UIUCDCS-F-74-879 , Department of Computer Science, University of Illinois, Urbana, Illinois, May 1974. 64 APPENDIX A PROGRAM EXAMPLE 65 .DATE 3/13/74 •R SWAP SYS IS LTAO NEW SYS? CORO COPY NUCLEUS? YES ZERO DIRECTORY? YES COPY FILES? YES * •♦ •RUN SYS PIP */E 3/13/74 PIP -SV 11 7/18/73 SWAP -SV 11 7/18/73 EDIT «SV 10 7/17/73 PAL8 .SV 16 1/16/74 ABSLDR.SV 5 7/17/73 CREF »SV 13 7/17/73 FUTIL .SV 22 11/19/73 UTY -PA 9 3/6/74 SYSTEM. SV 21 3/7/74 L0AD2 »SV 33 3/6/74 LOAD1 .SV 33 3/6/74 FOCAL -SV 23 2/16/74 VOS28 »PA 65 2/16/74 53 53 FREE BLOCKS ♦FOCAL. SVLPT: 1 1 L0AD1 .SV 33 3/6/74 EXAMP2.PA 4 3/13/74 EXAMP3.PA 3 3/13/74 OBJECT. BN 1 3/13/74 OBJT3 .BN 2 3/13/74 L0AD2 -SV 33 3/13/74 < EMPTY > 111 122 FREE BLOCKS ♦OBJECT. BN 125 FREE 33 3/13/74 125 BLOCKS ♦ tC 69 •RUN SYS L0AD3 depress CONT switch here 2000/4227 2000G ?2 ?3=06 ?2 ?4=10 ?3 ? 3= 1 1 ?4 ?5=24 ?4 ?4=20 ?1 ? 1=01 ?7 ?7=61 ?3 ?4=14 ?8 ?8=00 ?8 ?7=70 ?0 ?0*00 ?1 ?0=00 ?0 ?4=00 ?\ \H \tC BLIOGRAPHIC DATA IEET 1. Report No. UIUCDCS-R-7 I +-6Ul 3. Recipient's Accession No. Title and Subtitle 5. Report Date A Semi-Virtual Memory Multi-Programming System for the Mini-computer PDP 8/3 (ILLIAC-3) May 197 1 * Author(s) Tze-Wah Wong 8- Performing Organization Rept. No. 1 Performing Organization Name and Address Department of Computer Science University of Illinois Urbana, Illinois 10. Project/Task/Work Unit No. 1 }. Contract/Grant No. sponsoring Organization Name and Address Department of Computer Science University of Illinois Urbana, Illinois 13. Type of Report & Period Covered 14. supplementary Notes Abstracts A multiprogramming (semi-) virtual memory operating system has been written for the mini-computer PDP 8/e located in the ILLIAC-3 room of the University of Illinois. This computer is currently used to control the various picture processing peripherals in the room as well as routing information to the general purpose computer IBM 360/75 for processing. The following paper describes the usage and design principles of the operating system in coping with the above environment. Key Words and Document Analysis. 17a. Descriptors Multiprogramming Timesharing Virtual Memory Interactive Computing Operating System Mini Computer ILLIAC-3 • Identifiers /Open-Ended Terms } COSATI Fie Id /Group K Availability Statement release unlimited 19. Security Class (This Report) UNCLASSIFIED 21. No. of Pages 7^ ii 20. Security Class (This Page UNCLASSIFIED 22. Price USCOMM-DC 40329-P7I - " 2 7 \B7& &B ■ ■ < r«fl ■ 1 1 1 ■ ■ ■ * ■ . ■ I , H - ■ < Hi i ■ 1 MM