phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) (05/08/91)
The name TIE mean "Tasks, Interrupts, and Events". This package provides
for pre-emptive multitasking, Interrupt dispatching to second level handlers,
and Event/message queueing for tasks. It is written for CMS.
I have just finished writing TIE and am about to go on to test it and make
the necessary changes to get it to work. There might have to be minor
changes in what I am about to describe. I am currently doing a lot of
"desk checking" of the code.
Source code will be available along with all the macros needed to assemble
it on CMS and make the runnable MODULE.
TIE is invoked as a MODULE that makes itself nucleus free storage resident
and adds itself as a nucleus extension (to not load again). Calling the
TIE command with X'00' calling mode will result in R1 being returned with
the address of a list of addresses for the various TIE functions. They are
called via standard BALR conventions with R13 pointing to a savearea that
can be used and R14 containing the return address. R15 contains the address
of the entry point.
The various functions are:
TIEFORK - creates a new task which also returns to the same place
child
R1 = 0
R13 = new savearea
parent
R1 = taskid (TCC address) of the child
R13 = original savearea
This function may only be called from within a task.
TIESTOP - cause a task to stop
R1 = task id of task to be stopped
Stopping a task semi-abrupt. The task is not removed, but is given a
return code that indicates it should promptly exit.
This function may be called from within a task or an interrupt handler.
I am considering whether or not this function is really needed.
TIEPOST - post an event message to a task
R1 = task id of target task
R2-R5 = event data
This function may be called from within a task or an interrupt handler.
TIETID - get my task id
R1 = current task id (TCC address)
This function may only be called from within a task.
TIEWAIT - wait for an event during a timeout interval
R2-R3 = TOD at end of timeout interval
return
R0 = reason for return (TIEXSTOP,TIEXTIME,TIEXPOST,TIEXCEND)
TIEXPOST - a posted event/message is received
R2-R5 = event data
TIEXCEND - a child ended
R2 = task id of ending child
R3-R5 = R0-R2 from ending child
Note that the ending child's task id will not be reused until it is
reflected back to the parent.
TIETRAP - request interrupts be trapped for second level handlers
R2 = request id
R3 = 0 (to cancel) or address of handler
R4 = interrupt code AND MASK
R5 = interrupt code COMPARE VALUE
R6-R7 = tag data (arbitrary)
handler
R2 = request id
R3 = actual interrupt code
R4 = interrupt code AND MASK
R5 = interrupt code COMPARE VALUE
R6-R7 = tag data (arbitrary)
R13 = usable standard 18 word savearea
R14 = return address; handler MUST return here
R15 = handler address
All functions return a code in R0 that indicates the completion code.
These completion codes will be equated to a set of values in a COPY file.
A couple of examples are TIEXOK (all went OK) and TIEXOOM (out of memory).
There is no KILL function. Use "#CP IPL CMS" if you have a problem.
When TIE is called for the first time, initialization creates what is known
as the "ROOT TASK". The ROOT task is for CMS itself and the commands that
are invoked from CMS by user input.
Tasks will run as long as there are no interrupts. However there is an
internal "heartbeat" that forces a clock comparator interrupt ever so often.
Tasks with the same priority (I have not establish how this is set, yet)
will execute in FIFO order. So if two equal tasks are just using up CPU
time, they will switch back and forth each time the heartbeat occurs.
The ROOT task will have the highest (lowest value) priority. Children
probably will inherit the priority of the parent. I am open to suggestions
on how priority should be controlled.
CMS commands may fork off child tasks and then exit back to CMS. The child
tasks will keep on running (so they better be located in some allocated free
storage). Subsequent commands may fork off even more children. These tasks
can install interrupt handlers and do many sorts of background things using
logical loops around a call to TIEWAIT, instead of having to constantly
refigure its context during interrupt handling. The tasks run with interrupts
enabled, so they can even do some CPU work when they need to.
Services can be created that are implemented strictly as interrupt handlers,
or may utilize the task facility when it is better to implement them with
logical threads of control.
A typical service scenario might be a subroutine to make various requests
through. That subroutine would find out the task id via TIETID, install
an interrupt handler via TIETRAP if needed, setup information so the handler
can call TIEPOST to alert the requesting task, which would in turn use
the information given and maybe call the subroutine to elaborate on it.
CMS will not know about these tasks. The view to the end user is not changed
by this except that new programs can become available that use this. Still
only one CMS command can run at a time (too many commands use resources in
the virtual machine that can be used only one at a time anyway). Programs
that utilize TIE must be well behaved; there is no protection facility in
TIE whatsoever (it would break too many CMS things).
Future plans (vaporware) include a C language interface for the TIE functions,
a BITNET/RJE message interface, IUCV and VMCF interfaces, and a TCP/IP
interface. The interfaces will use events to post status changes. These will
all be implemented as separate modules, so if you don't like the way I or
someone else designed certain interfaces, you can use or write a different one.
--
/***************************************************************************\
/ 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) (05/08/91)
The name TIE mean "Tasks, Interrupts, and Events". This package provides
for pre-emptive multitasking, Interrupt dispatching to second level handlers,
and Event/message queueing for tasks. It is written for CMS.
I have just finished writing TIE and am about to go on to test it and make
the necessary changes to get it to work. There might have to be minor
changes in what I am about to describe. I am currently doing a lot of
"desk checking" of the code.
Source code will be available along with all the macros needed to assemble
it on CMS and make the runnable MODULE.
TIE is invoked as a MODULE that makes itself nucleus free storage resident
and adds itself as a nucleus extension (to not load again). Calling the
TIE command with X'00' calling mode will result in R1 being returned with
the address of a list of addresses for the various TIE functions. They are
called via standard BALR conventions with R13 pointing to a savearea that
can be used and R14 containing the return address. R15 contains the address
of the entry point.
The various functions are:
TIEFORK - creates a new task which also returns to the same place
child
R1 = 0
R13 = new savearea
parent
R1 = taskid (TCC address) of the child
R13 = original savearea
This function may only be called from within a task.
TIESTOP - cause a task to stop
R1 = task id of task to be stopped
Stopping a task semi-abrupt. The task is not removed, but is given a
return code that indicates it should promptly exit.
This function may be called from within a task or an interrupt handler.
I am considering whether or not this function is really needed.
TIEPOST - post an event message to a task
R1 = task id of target task
R2-R5 = event data
This function may be called from within a task or an interrupt handler.
TIETID - get my task id
R1 = current task id (TCC address)
This function may only be called from within a task.
TIEWAIT - wait for an event during a timeout interval
R2-R3 = TOD at end of timeout interval
return
R0 = reason for return (TIEXSTOP,TIEXTIME,TIEXPOST,TIEXCEND)
TIEXPOST - a posted event/message is received
R2-R5 = event data
TIEXCEND - a child ended
R2 = task id of ending child
R3-R5 = R0-R2 from ending child
Note that the ending child's task id will not be reused until it is
reflected back to the parent.
TIETRAP - request interrupts be trapped for second level handlers
R2 = request id
R3 = 0 (to cancel) or address of handler
R4 = interrupt code AND MASK
R5 = interrupt code COMPARE VALUE
R6-R7 = tag data (arbitrary)
handler
R2 = request id
R3 = actual interrupt code
R4 = interrupt code AND MASK
R5 = interrupt code COMPARE VALUE
R6-R7 = tag data (arbitrary)
R13 = usable standard 18 word savearea
R14 = return address; handler MUST return here
R15 = handler address
All functions return a code in R0 that indicates the completion code.
These completion codes will be equated to a set of values in a COPY file.
A couple of examples are TIEXOK (all went OK) and TIEXOOM (out of memory).
There is no KILL function. Use "#CP IPL CMS" if you have a problem.
When TIE is called for the first time, initialization creates what is known
as the "ROOT TASK". The ROOT task is for CMS itself and the commands that
are invoked from CMS by user input.
Tasks will run as long as there are no interrupts. However there is an
internal "heartbeat" that forces a clock comparator interrupt ever so often.
Tasks with the same priority (I have not establish how this is set, yet)
will execute in FIFO order. So if two equal tasks are just using up CPU
time, they will switch back and forth each time the heartbeat occurs.
The ROOT task will have the highest (lowest value) priority. Children
probably will inherit the priority of the parent. I am open to suggestions
on how priority should be controlled.
CMS commands may fork off child tasks and then exit back to CMS. The child
tasks will keep on running (so they better be located in some allocated free
storage). Subsequent commands may fork off even more children. These tasks
can install interrupt handlers and do many sorts of background things using
logical loops around a call to TIEWAIT, instead of having to constantly
refigure its context during interrupt handling. The tasks run with interrupts
enabled, so they can even do some CPU work when they need to.
Services can be created that are implemented strictly as interrupt handlers,
or may utilize the task facility when it is better to implement them with
logical threads of control.
A typical service scenario might be a subroutine to make various requests
through. That subroutine would find out the task id via TIETID, install
an interrupt handler via TIETRAP if needed, setup information so the handler
can call TIEPOST to alert the requesting task, which would in turn use
the information given and maybe call the subroutine to elaborate on it.
CMS will not know about these tasks. The view to the end user is not changed
by this except that new programs can become available that use this. Still
only one CMS command can run at a time (too many commands use resources in
the virtual machine that can be used only one at a time anyway). Programs
that utilize TIE must be well behaved; there is no protection facility in
TIE whatsoever (it would break too many CMS things).
Future plans (vaporware) include a C language interface for the TIE functions,
a BITNET/RJE message interface, IUCV and VMCF interfaces, and a TCP/IP
interface. The interfaces will use events to post status changes. These will
all be implemented as separate modules, so if you don't like the way I or
someone else designed certain interfaces, you can use or write a different one.
--
/***************************************************************************\
/ Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu | Guns don't aim guns at \
\ Lietuva laisva -- Brivu Latviju -- Eesti vabaks | people; CRIMINALS do!! /
\***************************************************************************/