Brief description of TIE 
Author Message
 Brief description of TIE

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.
--
 /***************************************************************************\

\ Lietuva laisva -- Brivu Latviju -- Eesti vabaks  |  people; CRIMINALS do!!  /
 \***************************************************************************/



Sun, 24 Oct 1993 07:31:03 GMT  
 Brief description of TIE
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.
--
 /***************************************************************************\

\ Lietuva laisva -- Brivu Latviju -- Eesti vabaks  |  people; CRIMINALS do!!  /
 \***************************************************************************/



Sun, 24 Oct 1993 07:31:03 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. Need a Brief description of Scheme for students

2. SP-Prolog & SP-Object : brief descriptions

3. Brief description of TCL

4. TIE is the name

5. Tying Files in DOS

6. Question of J (Concerning TIE)

7. Question of J (Concerning TIE)

8. The ties that bind...

9. Tied up in knots when opening files.

10. Problems printing (tying) in LPT2

11. want to tie the exit by windows, to the exit button in program

12. win 95,dos window,read key ties up machine

 

 
Powered by phpBB® Forum Software