C/C++ User's Journal & Wi…eveloper's Journal Tools/C-C__Users_Journal_and_Windows_Developers_Journal_Tools_1997.iso/smxdemo/root.exe/TEST.DAT

Text File | 1993-05-26 | 10.9 KB | 238 lines

**************************************************************************
* This is a test file for DOSdemo.  This is the file the demo reads from *
* the hard disk.                                                         *
**************************************************************************




                                 smx Unique Features


          The proposition that "all kernels are basically alike" is not
          true.  smx has several unique features which make it especially
          well-suited for embedded systems.


          Optimized for the 80x86 Family

          Unlike many kernels, smx was not developed for an 8-bit
          processor, then extended upward to the 80x86.  Nor was smx
          designed with the idea of easily porting it to many different
          processors.  Instead, smx was designed to exploit the strengths
          of the 80x86 architecture, to make them available to the
          application programmer, and to try to simplify their complexity.
          This is evident in some of the unique features which follow.


          Two-Level Foreground

          Nearly all kernels, except smx, disable interrupts during
          "critical sections" of their code.  For example, if one kernel
          call is altering a queue, another kernel call due to an interrupt
          cannot be allowed to access that queue.  This is usually
          prevented by disabling interrupts.  But, disabling interrupts
          adds interrupt latency to every interrupt in the system --
          whether the interrupt makes kernel calls or not.  Hence, the
          kernel imposes a restraint upon interrupt responsiveness which
          can paint the application programmer into a corner!

          smx solves this problem by creating a 2-level foreground
          structure which guarantees that smx calls will never collide.
          Hence it is not necessary to disable interrupts during smx calls
          nor even while the smx scheduler is running (except for a few
          negligible periods).  The approach works as follows:  Interrupts
          are serviced by short, fast interrupt service routines (isr's).
          When necessary, (e.g. at the end of a message) isr's invoke link
          service routines (lsr's).  Link service routines are like
          foreground tasks.  They are dispatched in FIFO order after any
          interrupted smx call completes.  lsr's run with interrupts
          enabled and can perform background operations, including making
          smx calls.







                                          1


          Layered Ready Queue

          Most kernels use a single, doubly-linked list as a ready queue.
          To enqueue a task it is necessary to search from the beginning of
          the ready queue to, potentially, its end until the right place is
          found (based upon priority and time of arrival).  This can take a
          long time if there are many tasks in the ready queue.  In a real-
          time system it is possible that all, or most, tasks become ready
          at once.  Hence worst-case performance can be poor.  Even worse,
          this occurs at times of peak loads and could cause glitches.

          smx uses a different structure for its ready queue.  Each
          priority level has its own queue control block (qcb).  These
          qcb's are physically adjacent and in priority order.  The smx
          scheduler uses priority to index to the proper qcb and simply
          places the task at the end of the level (directly pointed to by
          the back link in the qcb).  This fast, two-step process takes the
          same time regardless of how many tasks are ready.


          Stack Pool

          The principal overhead of a task is the stack space it requires.
          Each task's stack must be large enough to support all local
          variables for the maximum nesting of functions in the task.  And
          it must simultaneously provide space to save registers for the
          maximum nesting of interrupt service routines.  Usually this
          requires at least 200 bytes and possibly much more.  In a typical
          situation, the memory overhead of a task can be reduced 90%, or
          more, simply by releasing its stack!

          smx is the only kernel which permits doing exactly this.  When
          tasks must wait for more work, they can release their stacks back
          to a common stack pool.  When a task is restarted due to a
          message, signal, timeout, etc. it is given a new stack from the
          same pool.  smx does this without speed penalty!

          Stack sharing opens a new vista for embedded software design --
          namely using large numbers of "small" tasks.  The advantages of
          doing so are:  easier designs, capitalization upon the proven
          code of the kernel, and greater benefit from error monitoring and
          debug features of the kernel.


          Near & Far Stacks

          Normally the stack pool is part of DGROUP -- i.e. it is "near."
          (This is often necessary because some library functions require
          that ss==ds.)  However, should space in DGROUP become too
          limited, the stack pool can be moved out to its own "far"
          segment.  Then there is 64K available for near variables in
          DGROUP and the stack pool can also occupy up to 64K in its own
          segment.  (Of course, functions requiring ss==ds must not be used
          or must be modified.)


                                          2


          smx also permits "bound" stacks.  These are stacks which are
          never given up.  (Unless the task is deleted.)  Bound stacks may
          be near or far and can be of a unique size for each task.  Near
          stacks come from the smx near heap which is in DGROUP.  Near
          stack sizes are, of course limited to available space in DGROUP.
          Far stacks come from the smx far heap and can be up to 64K in
          size.  Far stacks are useful for tasks which require extremely
          large stacks (e.g. graphics servers).


          Message Priority and Pass-Thru Exchanges

          Though not needed in all applications, message priority is a
          powerful tool.  A pass-thru exchange passes the message's
          priority thru to the receiving task.  This allows a server task
          to adopt the same priority as a client task.  Server tasks are
          useful for managing non-reentrant resources such as disk drives
          and graphics displays.  Being able to dynamically adjust their
          priorities permits them to operate as extensions of client tasks.


          Multilevel Exchanges

          Multilevel exchanges permit high priority messages to bypass low
          priority messages.  This is useful, for example, in data
          communications to pass protocol control messages (e.g. ACK/NAK)
          around data messages.  Another example is passing catastrophic
          error messages around warning messages to the error manager task.


          Extensive Error Monitoring

          smx monitors over 40 error types.  Included are:  range checking
          of all smx call parameters, checking resource availability before
          creating objects, checking for stack overflow and underflow,
          range checking ss:sp, checking for broken queues, checking for
          invalid operations, etc.  Most misuses of smx are caught and
          reported immediately.  Such thorough error checking also catches
          a wide range of other errors and malfunctions.


          Two Types of Error Management

          smx offers both central and point-of-call error management.
          Central error management is implemented with user-alterable error
          service routines (esr's).  The esr's supplied with smx typically
          display an error message and log the error into the error buffer.
          Then, non-catastrophic esr's return while catastrophic esr's exit
          or restart.  Point-of-call error management is supported by
          returning 0 instead of a value if an error or timeout has
          occurred.  The global variable, xerrno, identifies which error
          occurred.  xerrno == 0 if a timeout occurred.  The user may then
          apply his own remedy.



                                          3


          Test Mode vs Non Test Mode

          smx allows you to choose between the safety and convenience of
          full error monitoring vs the increased speed and reduced size of
          no monitoring.  In addition, non-test mode libraries are
          optimized.


          Task Level Debugger

          smxProbe is one of the most powerful debuggers available for any
          kernel, regardless of cost.  Not only does it work standalone,
          but also it can add task-aware features to standard code
          debuggers, such as breakpointing in a specified task.  smxProbe
          operates either on the development system or on the target via a
          serial port connected to an ASCII terminal or PC.

          smxProbe provides trace buffers for tasks (up to 8192 entries),
          for errors (up to 6550 entries) and for smx calls (up to 4096
          entries).  It provides symbolic display of all smx control blocks
          and queues.  Sophisticated trigger points can be set.  The
          application can be frozen below a specified priority level.  To
          top this off, any smx call can be executed from the smxProbe
          command line!


          Hook

          smx allows hooking exit/entry routine pairs into any task.  These
          are automatically called when the task is suspended or resumed,
          respectively.  Hooking permits additional task context switching
          to be performed such as:

               (1) saving & restoring coprocessor registers
               (2) switching memory banks, pages, or overlays
               (3) saving & restoring static variables to achieve
                   reentrancy by task
               (4) moving data into and out of near memory


          Segmentation Support

          Segmentation is the most disliked feature of the 80x86
          architecture.  However, if one is using an 80x86 processor, then
          one must deal with it.  smx helps in the following ways:

               (1) smx supports all memory models.
               (2) smx globals are assigned to near memory (i.e. DGROUP) to
                   maximize its performance for all memory models.
               (3) smx saves all segment registers as part of the task
                   context.
               (4) smx allows a separate default data segment per module
                   (SDS option).



                                          4                          9/3/92