home *** CD-ROM | disk | FTP | other *** search
/ Fish 'n' More 1 / FishNMoreVol1.bin / more / text_files / aboutexec < prev    next >
Text File  |  1990-01-03  |  13KB  |  246 lines
  1.  
  2.                   A Tutorial on exec, i/o, and Multi-tasking
  3.                            (c) By John T. Draper
  4.  
  5.   A product of the Programmers Network,  A Software Developers Guild and
  6.  Information source for Independent programmers.    Permission to distribute
  7.  this is granted as long as the title and header is included.   For more info
  8.  on how to join the Programmers Network,  Contact John Draper at the following
  9.  net address:
  10.  
  11.  USNail:  310 WestLine Dr. B210
  12.           Alameda, Calif.  94501
  13.           (415) 769-1268
  14.  
  15.  UUCP: ...ihnp4!ptsfa!well!crunch
  16.  BIX:   crunch
  17.  WELL:  crunch
  18.  DELPHI:CRUNCH
  19.  
  20.                             THE BASICS OF EXEC
  21.                             ------------------
  22.  
  23.    All programs running on the Amiga are under control of the EXEC.   You can 
  24.  think of the EXEC as a very fast program that controls all other programs
  25.  running on the Amiga.   Programs come in 3 flavors.   Processes,  Tasks,
  26.  and Interrupts.   In this tutorial,   the term "Task" will mean a separate
  27.  "Program" or set of instructions.   The EXEC has the responsibility of deciding
  28.  which TASK gets control of the CPU.   Tasks can have a specific PRIORITY.   The
  29.  range of prioritys can be from -128 to +127.    Normally,  user programs run
  30.  at priority 0.   Intuition runs at priority 50,   and programs can change their
  31.  priority if necessary.   The PRIORITY of a program determines which place in
  32.  line it has in relation to other programs waiting for their turn to run.   It's
  33.  like "Waiting in line" to get your chance to use the CPU.
  34.  
  35.  
  36.                   THE EXEC CONTROLS TASKS (among other things)
  37.                   --------------------------------------------
  38.  
  39.     Tasks can be in 3 states:  Running,  Ready,  and Waiting.   A "Running" task
  40.  actually has control over the CPU,  It now "Owns" the CPU for a specified 
  41.  period of time called a QUANTUM.    A QUANTUM is a set period of time,  that
  42.  can be changed,  and is somewhere around 50 Milliseconds.   After its time is
  43.  up,   the EXEC saves the state of the program on its own stack,   and switches
  44.  to the NEXT program in line.    The program that just gave up the CPU gets put
  45.  into another line.   This line is the "Ready" line.   If that task has a higher
  46.  priority than the highest task in that "Ready" list,  it gets shoved in the
  47.  front of that list.   When the program thats running, executes a "Wait" or
  48.  a "WaitPort" instruction,  the task in the front of the "Ready" list gets
  49.  a chance to run again, until either its QUANTUM is up,  or it executes
  50.  a "Wait" instruction.
  51.  
  52.  
  53.  
  54.  
  55.                      LISTS OF "Things" THAT EXEC CONTROLS
  56.                      ------------------------------------
  57.  
  58.     Speaking of "Lists",  the Amiga has a standard way of dealing with lists.
  59.  A good description is in the first chapter of the VOL 1 RKM.   A list is
  60.  a collection of "Nodes".   Just about everything in the Amiga has a Node. 
  61.  Tasks,  Messages,  Ports,  I/O Blocks  all have Nodes.   This gives the
  62.  Exec a consistant way of handling each of these.   This means that Messages
  63.  can be put into a "List" of messages,  Ports can be put into "Lists" of Ports
  64.  and so on.   This permits a very flexable way for an Amiga programmer to 
  65.  control the various resources of the system.   The RKM doesn't do a very
  66.  good job in explaining what lists are used for,   it just does a good job
  67.  in explaining what they are,  and how to manipulate them.
  68.  
  69.     A "List" structure is shown below, and how it connect up a few "Nodes".
  70.  
  71.                                -----------> struct Node {
  72.                                |               struct Node *ln_Succ;  (ZERO)
  73.  struct List {                 |               struct Node *ln_Pred; <------
  74.     struct Node *lh_Head; -----                UBYTE ln_Type;              |
  75.     struct Node *lh_Tail;  (Always Zero)       BYTE ln_Pri;                |
  76.     struct Node *lh_TailPred; -----            char *ln_Name;              |
  77.     UBYTE lh_Type;                 |        };                             |     
  78.          
  79.     UBYTE lh_pad;  (Not used)      |                                       |
  80.  };                                |        struct Node {                  |
  81.                                    |           struct Node *ln_Succ; <------
  82.                                    |           struct Node *ln_Pred; <------
  83.                                    |                  !!    !!             |
  84.                                    |                                       |
  85.                                    ------>  struct Node {                  |
  86.                                                struct Node *ln_Succ; <------
  87.                                                struct Node *ln_Pred;  (Zero)
  88.  
  89.  
  90.                      JUST ABOUT EVERYTHING IS A NODE
  91.                      -------------------------------
  92.  
  93.     A Node is sort of a "Connection point" where the various structures can
  94.  be connected.   Usually, Nodes are connected or arranged in some sort of
  95.  a "List".   Nodes can be move from list to list.   Nodes can be Tasks,
  96.  Processes,
  97.  Messages,  Message ports,  I/O Blocks,  and just about anything else in the
  98.  Amiga.   Not everything is a node.   For instance: Gadgets,  Menus,  and
  99.  Windows are NOT nodes.  I don't know why!!  Perhaps RJ can comment on that.
  100.  
  101.     As shown above,  Three Nodes are connected in a "List".   If these nodes
  102.  are Tasks,  and the list happens to be a "Ready" list,  these Nodes are inserted
  103.  in such a way that the Highest priority is at the "Head" of the list.
  104.  the Exec function Enqueue() is probably used.
  105.  
  106.     The "ln_Pri" field is the nodes Priority field.   Because these Nodes are 
  107.  Tasks, the ln-Pri field then determines that Tasks priority.   Other entities
  108.  have Nodes,  like Messages, and Ports.   These also have "Priorities", or
  109.  ln_Pri fields.   If you are using the sound drivers,  the ln_Pri field is used
  110.  as a "Precidance".  Sometimes,  this field isn't really used by Exec.  You can
  111.  use it in your OWN Custom nodes should you decide to create your own. So,
  112.  we now have these Lists and Nodes,  what can we really do with them?
  113.  
  114.  
  115.                             DIDDLING WITH NODES
  116.                             -------------------
  117.  
  118.     We can create a New List, by calling "NewList".   Unless you are an advanced
  119.  programmer,  you probably won't ever have to use this function.   It is probably
  120.  called when you Create a Port,  or in some of the lower level Exec functions.
  121.  
  122.  
  123.                               INSERTING A NODE
  124.                               ----------------
  125.  
  126.     After you create this "List", now you can "Attach" nodes to it.   Use the
  127.  Insert() function.   For example:   Insert(Mylist, MyNode, Pred);   Where:
  128.  
  129.  struct List *MyList;   /* Is a pointer to my List structure */
  130.  struct Node *MyNode;   /* Pointer to the Node that I want to Add to the list */
  131.  struct Node *Pred;     /* Pointer to the Node in the list, where "MyNode" gets
  132.                            inserted AFTER */
  133.  
  134.    If Pred = 0, the node will be added at the Head of the list.   If the Pred
  135.  node points to the list lh_Tail field,  it will be inserted at the "Tail" of
  136.  the list.   You can "AddHead" and "AddTail", also "Remove" a node.
  137.  
  138.  
  139.                             PRIORITIZED INSERTION
  140.                             ---------------------
  141.  
  142.    The Priority field of the Node can also be used to determine the position in
  143.  the list where a node can be inserted.  When your task finishes its turn
  144.  using the CPU,  this function is called.  This is called PRIORITIZED INSERTION.
  145.  The "Enqueue" function inserts a node into a list AFTER the last node of same
  146.  or higher priority.  For example:   Enqueue(MyList, ANode);  Inserts
  147.  "ANode" into "MyList" where they are declared as:
  148.  
  149.  struct List *MyList;     /* A pointer to the list we want to insert in */
  150.  struct Node *ANode;      /* The Node that I want to insert */
  151.  
  152.    Naturally, before "Enqueue" is called,  the Nodes ln_Pri field is set
  153.  as follows:   ANode->ln_Pri = <some priority value>,   For instance,  just
  154.  before you add a Task,  you must set the tasks Priority field.   If "MyTask"
  155.  is a pointer to a task,  then:  MyTask->tc_Node.ln_Pri = PRIORITY;   Will set
  156.  that tasks Priority.   This is usually done before your task becomes activated.
  157.  
  158.  
  159.                             FINDING NODE BY NAME
  160.                             --------------------
  161.  
  162.    Finally,  each node can have a "Name" pointer "ln_Name".   Using Names is
  163.  useful for "Debugging" purposes and otherwise identification of them.   A
  164.  Function called FindName will return a pointer to the node, given a pointer
  165.  to a null terminated string, and a list.   For example:
  166.  
  167.    FoundNode = FindName(MyList, "MyNode");  Where MyList is a pointer to a List,
  168.  and "MyNode" is the Name for that node.  "FoundNode" is a pointer to the
  169.  node with that name.   If No name exists, function returns a NULL.   To find
  170.  multiple entrys,  call function again.
  171.  
  172.  
  173.                  MOST EXEC STRUCTURES HAVE NODES IN THEM
  174.                  ---------------------------------------
  175.  
  176.    As mentioned earlier,  just about every C structure contains a "Node" 
  177.  structure within it.  Notice that the FIRST entry in a Task structure is
  178.  a "Node".    So,  a Task node can be referenced by:  tc_Node.  Notice that
  179.  this field is an "INSTANCE" of a node.   This means that the Task structure
  180.  has a Node contained within it.  This ISN'T a "Pointer",  it is the actual
  181.  structure.   If a field within a structure is a "POINTER", it contains an "*"
  182.  in front of it.   Part of a Task structure is listed below,  Refer to Pg 1-15
  183.  Vol 1 of RKM for entire structure.
  184.  
  185.  struct Task {
  186.     struct Node tc_Node;    /* Tasks Node structure */
  187.     UBYTE tc_Flags
  188.         !!   !!
  189.         !!   !!
  190.  
  191.     Each NODE has a Type.   Each List also has Types.  There are MANY DIFFERENT
  192.  Types.   For instance,  a Task Node has a type of NT_TASK.   If a node is
  193.  attached to a "Message",  its type is NT_MESSAGE.    For instance,  we might
  194.  have a "List" of Messages attached together for some purpose, for instance, 
  195.  messages queued up in a message port are lists of message nodes. 
  196.  
  197.     So the "List" lh_Type field in the list would have NT_MESSAGE as its
  198.  Type.    Then each Message in that list would have to have its ln_Type field
  199.  also set to NT_MESSAGE.  In the "exec/nodes.h" header file is a definition of
  200.  the various Types and their values.   These values are from 0 (unknown) to
  201.  13 (a Process).   You can define your OWN lists.    If you do,  make sure that
  202.  you choose a number above 64.   I'm sure that Amiga will be sequentially
  203.  "assigning"  various Node types for future use.  I am sure that Amiga would
  204.  want you to choose Node types that wouldn't have much of a chance of Clashing
  205.  with future types.  Some of the types are listed below:
  206.  
  207.  NT_TASK      - A Task node.
  208.  NT_INTERRUPT - An Interrupt node.
  209.  NT_DEVICE    - A Device.
  210.  NT_LIBRARY   - A Library
  211.  NT_FONT      - A Font
  212.  NT_MESSAGE   - A message
  213.  NT_MSGPORT   - A Message port
  214.  
  215.     These are to name a few.   There are more,  but these are the most Common
  216.  parts of the Amiga operating system. Notice that NOTHING was mentioned about
  217.  AmigaDOS.   AmigaDOS is a separate "Layer" or set of programs that run "on top"
  218.  of the Exec.  Because of this,  separately generated tasks CANNOT CALL any of
  219.  the AmigaDOS functions.   A lot of the C Library functions like "printf" must
  220.  call the AmigaDOS functions, and CANNOT be used from within a task.   They CAN
  221.  be called from separate Processes.   A Process is different than a task.  
  222.  There is a very LIGHT discussion on "Processes" in the AmigaDOS manuals
  223.  and won't be covered here.
  224.  
  225.     Next time,   I'm taking it further into the relationship of how all this
  226.  is put together.   Just about EVERYTHING works the same way,  for instance,
  227.  all the EXEC I/O can run as Tasks.   When an IO request is made to start up
  228.  the Narrator,  the "SendIO" function is called which can "Activate" an IO
  229.  task,   then when that task gets done "Doing its thing",  it sends a Message
  230.  back to a designated "Message Port" telling the calling routine that It's 
  231.  finished.  In the meantime,  your program was running off doing other things
  232.  until it recieved a "Signal" from the IO device.  The Serial,  Parallel,
  233.  
  234.  Sound, Narration, Disk Device,  and ALL other devices work in EXACTLY the same 
  235.  way.
  236.  
  237.      Enuff for a nights work.   Now if someone would hire me, and treat me
  238.  nice,   I would be able to find time to post more of these tidbits of wit.
  239.  Adios folks,  Till next time......
  240.  
  241.  Crunch (The Cap'n)
  242.  Programmers Net
  243.  On the WELL
  244.  "Da place where us global village folks live"
  245.  
  246.