Browse Prior Art Database

Process Input/Output in an Object-Oriented Environment

IP.com Disclosure Number: IPCOM000114786D
Original Publication Date: 1995-Jan-01
Included in the Prior Art Database: 2005-Mar-29
Document File: 2 page(s) / 100K

Publishing Venue

IBM

Related People

Chen, C: AUTHOR [+3]

Abstract

A method of abstracting hardware details from an application is disclosed. For an Object-Oriented Analysis (OOA), abstraction from hardware nuances and anomalies is desired. Microcoders, called application coders on our OOA-based project, should not need to worry about setting hardware registers and executing bit manipulation on proprietary hardware platforms. Also, hardware is very likely to change during project development. Microcode impacts resulting from actual hardware changes or hardware anomalies should be minimal.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Process Input/Output in an Object-Oriented Environment

      A method of abstracting hardware details from an application is
disclosed.  For an Object-Oriented Analysis (OOA), abstraction from
hardware nuances and anomalies is desired.  Microcoders, called
application coders on our OOA-based project, should not need to worry
about setting hardware registers and executing bit manipulation on
proprietary hardware platforms.  Also, hardware is very likely to
change during project development.  Microcode impacts resulting from
actual hardware changes or hardware anomalies should be minimal.

      Abstraction from hardware is achieved by an OOA domain called
Process Input/Output (PIO).  Hardware is used by making a request to
PIO, called a PIO_Request.  PIO is the only domain that has access to
the hardware.  This abstracts the details of hardware from the
application.

      There are other benefits from using PIO.  All of the hardware
activity is contained in one domain.  This greatly simplifies
hardware tracing, which can be used later to identify errors in the
operation of the program.

      Another benefit of PIO is its handling of hardware interrupts.
One PIO_Request, for example, may generate four or more hardware
interrupts.  The application only needs to wait for one return event
from PIO.  PIO will manage the sequence and status of all interrupts
generated by the hardware.  PIO will also set a timer for each
expected
interrupt, so that it will be able to detect timeout conditions.

      There are two types of PIO_Requests.  Disconnected PIO_Requests
are typically used for longer hardware operations that require
interrupt handling and return events back to the application.
Immediate
PIO_Requests are used for short hardware accesses not requiring
interrupts or events, such as a request for a time stamp.

      The PIO_Request Interface - All disconnected PIO_Requests must
follow this convention.  Immediate requests are not required to use
this interface (an explanation of this will follow).

      All disconnected PIO_Requests (as well as some immediate
requests) follow a standard format.  This format will be referred to
as the "PIO structure format".  In the PIO structure format, one
parameter will be passed to PIO, which will be a unique structure for
each PIO_Request that contains the following items (when
appropriate):
  o  A target_id for the event to be returned
  o  A return_code indicating the completion results of the
PIO_Request
  o  A request structure which contains all input to PIO
  o  A response structure which contains all output from PIO
  o  An error structure which contains all er...