USERECGF@LNCC.BITNET (Eduardo Cavalcanti Gomes Ferreira) (04/27/91)
Phil, A multitasking program for VM/CMS? how did you do it? what does it run? Now you catch me. But I keep my point. If you where running it in UNIX, you would use C. But I'm really upset by your news. Tell us all about it, ok? Eduardo Ferreira - System Programmer at Catholic University of Rio de Janeiro.
phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) (04/29/91)
USERECGF@LNCC.BITNET (Eduardo Cavalcanti Gomes Ferreira) writes: >Phil, >A multitasking program for VM/CMS? how did you do it? what does it run? >Now you catch me. >But I keep my point. If you where running it in UNIX, you would use C. But >I'm really upset by your news. Tell us all about it, ok? What is there to be upset about? You could just pretend I never wrote it, and go on living happily ever after. First of all, this program is NOT finished. I only just recently finished writing the code and have not tested it at all yet. As complex as this kind of thing is, I'd expect a LOT of "test, trace, dump, re-ipl CMS, edit, assemble, load, and genmod" cycles. Also a few untested macros (even though of general purpose) are used in it. For the macros, this is their first time "out of the nest" and they might not fly, either. This program does NOT provide for the ability to run two or more existing CMS programs or commands at the same time. While it provides for the ability to have tasks, it does NOT attempt to manage any of the resources of CMS as would be needed by multiple tasks attempting to gain access to them at the same time. Only "well behaved" tasks are runnable. This program only makes the development cycle for those programs that need to have some background tasks a little easier to do. This program is called TIE for lack of a better name. It is an acronym for "Tasks, Interrupts, and Events". I'm still open on the name so if you have a better idea, do tell me. TIE runs as a nucleus extension. The main "TIE" command will return in register 1 the address of a list of function addresses to call for the various TIE services. One of these services is an interrupt dispatcher that handles I/O and external interrupts, except clock comparator (which TIE uses itself in 3 different ways). TIE traps interrupts at the NEW PSW level. Interrupts not requested to be handled are passed on to the handlers pointed to by the NEW PSWs that were previously in place (usually in CMS). The function that accepts requests for interrupts to be handled can also cancel those requests. Interrupts are requested in terms of a code value to be matched and a code mask that is ANDed with the actual interrupt code (prefixed by 01 for I/O and 02 for external). With mask=0 and value=0 you effectively always match every interrupt (except you won't get clock comparator). When TIE initializes, it creates a ROOT TASK and makes it the current task. CMS then effectively runs as the ROOT TASK as well as any program run by command. A program can create a new task any time (except during the handling of an interrupt). The function to do this is called FORK, but unlike its UNIX namesake, it does not copy any address spaces. The FORK function will return twice, once to the parent, and once to the child. The child will have a new savearea. When the child does its own return, the task is terminated. The parent's savearea chain context is unchanged. Most of the general registers and all of the floating registers are copied to the child. A task will typically invoke some service package, for instance a message trapper, TCP/IP, asyncronous I/O, etc. That package will contact TIE and request interrupt handling. The program will make requests of the package at a higher level (e.g. listen on TCP port 119). The package will field the actual interrupts, and when appropriate, post an event to the calling task. A TIE function can be called when a task is current to identify what the current task is. To receive an event, the WAIT function is called. The one parameter to the wait function is the wakeup time in TOD format. If an event is present now, or arrives before the wakeup time, WAIT will return with a code saying that the status of an event is being returned. Some registers are filled in with event data. If no events arrive by the timeout, a timeout code is returned instead. The termination of a child is a special case of an event identified by a code different from a posted event. I don't want to give too many specifics at this time since I am not that sure all will stay as I have initially designed it. While I am still open to ideas to be added, I am also trying to keep this thing basically simple. It is mostly to avoid writing programs that are interrupt driven, and to allow "plug and play" between interrupt driven service packages and more generic programs that use them. In the plans are: A C language interface to TIE A TCP/IP package using TIE An RSCS message handler using TIE -- /***************************************************************************\ / Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu | Guns don't aim guns at \ \ Lietuva laisva -- Brivu Latviju -- Eesti vabaks | people; CRIMINALS do!! / \***************************************************************************/
phil@UX1.CSO.UIUC.EDU (Phil Howard KA9WGN) (04/29/91)
USERECGF@LNCC.BITNET (Eduardo Cavalcanti Gomes Ferreira) writes: >Phil, >A multitasking program for VM/CMS? how did you do it? what does it run? >Now you catch me. >But I keep my point. If you where running it in UNIX, you would use C. But >I'm really upset by your news. Tell us all about it, ok? What is there to be upset about? You could just pretend I never wrote it, and go on living happily ever after. First of all, this program is NOT finished. I only just recently finished writing the code and have not tested it at all yet. As complex as this kind of thing is, I'd expect a LOT of "test, trace, dump, re-ipl CMS, edit, assemble, load, and genmod" cycles. Also a few untested macros (even though of general purpose) are used in it. For the macros, this is their first time "out of the nest" and they might not fly, either. This program does NOT provide for the ability to run two or more existing CMS programs or commands at the same time. While it provides for the ability to have tasks, it does NOT attempt to manage any of the resources of CMS as would be needed by multiple tasks attempting to gain access to them at the same time. Only "well behaved" tasks are runnable. This program only makes the development cycle for those programs that need to have some background tasks a little easier to do. This program is called TIE for lack of a better name. It is an acronym for "Tasks, Interrupts, and Events". I'm still open on the name so if you have a better idea, do tell me. TIE runs as a nucleus extension. The main "TIE" command will return in register 1 the address of a list of function addresses to call for the various TIE services. One of these services is an interrupt dispatcher that handles I/O and external interrupts, except clock comparator (which TIE uses itself in 3 different ways). TIE traps interrupts at the NEW PSW level. Interrupts not requested to be handled are passed on to the handlers pointed to by the NEW PSWs that were previously in place (usually in CMS). The function that accepts requests for interrupts to be handled can also cancel those requests. Interrupts are requested in terms of a code value to be matched and a code mask that is ANDed with the actual interrupt code (prefixed by 01 for I/O and 02 for external). With mask=0 and value=0 you effectively always match every interrupt (except you won't get clock comparator). When TIE initializes, it creates a ROOT TASK and makes it the current task. CMS then effectively runs as the ROOT TASK as well as any program run by command. A program can create a new task any time (except during the handling of an interrupt). The function to do this is called FORK, but unlike its UNIX namesake, it does not copy any address spaces. The FORK function will return twice, once to the parent, and once to the child. The child will have a new savearea. When the child does its own return, the task is terminated. The parent's savearea chain context is unchanged. Most of the general registers and all of the floating registers are copied to the child. A task will typically invoke some service package, for instance a message trapper, TCP/IP, asyncronous I/O, etc. That package will contact TIE and request interrupt handling. The program will make requests of the package at a higher level (e.g. listen on TCP port 119). The package will field the actual interrupts, and when appropriate, post an event to the calling task. A TIE function can be called when a task is current to identify what the current task is. To receive an event, the WAIT function is called. The one parameter to the wait function is the wakeup time in TOD format. If an event is present now, or arrives before the wakeup time, WAIT will return with a code saying that the status of an event is being returned. Some registers are filled in with event data. If no events arrive by the timeout, a timeout code is returned instead. The termination of a child is a special case of an event identified by a code different from a posted event. I don't want to give too many specifics at this time since I am not that sure all will stay as I have initially designed it. While I am still open to ideas to be added, I am also trying to keep this thing basically simple. It is mostly to avoid writing programs that are interrupt driven, and to allow "plug and play" between interrupt driven service packages and more generic programs that use them. In the plans are: A C language interface to TIE A TCP/IP package using TIE An RSCS message handler using TIE -- /***************************************************************************\ / Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu | Guns don't aim guns at \ \ Lietuva laisva -- Brivu Latviju -- Eesti vabaks | people; CRIMINALS do!! / \***************************************************************************/