Computer program analyzer for adapting computer programs to different architectures

Abstract

An extended mode analyzer (EMA) processes source code modules, detects suspicious instruction patterns and produces recommendations for code modification. The EMA applies knowledge based technology to the problem of massive source code conversion. The knowledge base component within the EMA models any given source code module using a hierarchical class/attribute structure. All source lines occurring in a given module are partitioned into homogenous classes characterized by function or instruction type. Higher level programming concepts are abstracted from lower level implementation details by drawing correspondences between class members which constitute instruction sequences related by common elements. When inferencing begins, the existence of class members meeting certain criteria trigger events which change the state of the world as seen by the knowledge base, in turn triggering other state changing events and so on until a state of equilibrium is achieved. The end result of this process is the body of recommendations produced by EMA for source code conversion.

Claims

I claim:

1. A computer program analyzer for aiding a computer programmer in modifying a computer program to run on a different computer architecture than an architecture for which the program was originally written comprising;

parser means for receiving a computer program in source code form and generating symbolic source information having source code lines, said source information being organized into hierarchical data structures which partition all source code lines into homogeneous classes characterized by function or instruction type;

a knowledge base containing structures for representing said source code and information on conversion rules for modifying said source code for said different computer architecture;

an inference engine connected to said parser means and knowledge base for receiving said organized symbolic source information and selectively retrieving said conversion rules for applying said conversion rules to said symbolic source information and for generating outputs including recommendations for source code modification, a trace of rules used in arriving at said recommendations and a cross reference of all symbol names used on source lines which have been cited for change; and

report formatter means connected to said parser means for receiving said organized symbolic source information and to said inference engine for receiving said recommendations, trace and cross reference for generating a report of recommendations for source code modification for use by said programmer.

2. A system, including a computer, for automatically modifying a first computer program developed to run in a first program environment, defined by a computer architecture, a computer operating system, or a computer architecture and computer operating system, to run in a different second program environment, said system comprising:

symbol generating means for generating an intermediate symbolic representation of said first computer program wherein said representation is independent of a particular program environment and wherein said intermediate symbolic representation includes class attribute structures which correspond to the first computer program;

knowledge base means for providing a plurality of rules for use in analyzing said intermediate symbolic representation, wherein at least one set of said plurality of rules is for analyzing said intermediate symbolic representation for said different second program environment;

analyzer means, coupled to said symbol generating means and to said knowledge base means, for determining a plurality of changes to make to said first computer program and

for analyzing said intermediate symbolic representation to identify a plurality of patterns of non-adjacent instructions which require modification Using said set of said plurality of rules of said knowledge base and an inference engine means for applying said set of said plurality of rules to said intermediate symbolic representation; and

output means, coupled to said analyzer means, for generating a second computer program which is fully compatible with said different second program environment based upon said plurality of changes determined by said analyzer means.

3. The system as recited in claim 2, wherein said output means includes report formatter means for generating a report of recommendations for computer program modification.

4. The system as recited in claim 3, wherein said output means includes code generator means for receiving computer program and for inserting said recommendations for computer program modification as comments in said first computer program.

5. The system as recited in claim 3, wherein said output means includes code generator means for receiving computer program and implementing said recommendations for computer program modification in said first computer program.

6. The system of claim 2, wherein said symbol generating means comprises a parser.

7. The system as recited in claim 6, wherein said parser includes means for generating formatted source code and a parser summary.

8. The system of claim 2, wherein said symbol generating means includes means for receiving as input an equivalence list of registers for each of said computer architectures and a list of changed global symbols for each of said computer architectures.

9. The system as recited in claim 2, wherein said inference engine includes means for generating a cross reference of all symbol names used on computer program lines which have been cited for change.

10. The system of claim 2 wherein said second computer program includes code to utilize a plurality of features of said second program environment which said first program did not previously include.

11. The system of claim 10 wherein one of said plurality of features is a different addressing mode from that employed in said first program environment.

12. A method of automatically modifying a first computer program developed to run in a first program environment, defined by a computer architecture, a computer operating system, or a computer architecture and computer operating system, to run in a different second program environment, comprising the computer performed steps of:

a) creating an intermediate symbolic representation of said first computer program in the form of a plurality of class structures of a knowledge base wherein said representation is independent of a particular program environment;

b) providing a knowledge base wherein said knowledge base includes a first plurality of rules associated with said different second program environment and wherein said first plurality of rules is for use in analyzing said intermediate symbolic representation;

c) analyzing said intermediate symbolic representation of said first computer program to identify a plurality of patterns of non-adjacent instructions which require modification using said set of said plurality of rules of said knowledge base to determine a plurality of changes to make to said first computer program wherein said analyzing includes the step of using an inference engine to apply said first plurality of rules to said intermediate symbolic representation; and

d) generating a second computer program based upon said analysis of step c) which is fully compatible with said different second program environment.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention generally relates to a computer software tool for increasing productivity in software conversion tasks. In a specific example, the software tool is used to adapt an operating system for use in an extended address space architecture. More particularly, the invention is a knowledge based software tool which analyzes source code and produces detailed recommendations for code changes necessary to preserve program functionality while running on a different computer architecture than that for which the code was originally written.

2. Description of the Prior Art

Computer hardware, from microcomputers to mainframes, is rapidly evolving, providing increased processing speed and memory. This, however, creates a problem for software developers who are having an increasingly difficult time in adapting software to the new computer architectures. Even within a so-called family of computers where the architecture of the new generation of computers has been designed to maintain a certain degree of compatibility with the prior generation, there is often a major task in adapting computer programs to the new architecture.

Consider, for example, the case where a new generation of computer architecture allows extended memory addressing capability. A case in point is a new generation Unisys computer which supports a 64 MByte memory environment, in contrast to the older Unisys System 80 computer which supports only a 16 MByte memory environment. The problem presented by this new architecture was to adapt the operating system, OS3, which was written in assembly language for the System 80 to the new 64 MByte memory environment. This is a monumental task because of the thousands of lines of source code of the program that must be analyzed and, where required, modified.

The problem is not limited to operating systems which are to be ported to a new computer architecture, nor is the problem unique to mainframe computers. As a specific example in the microcomputer field, consider the Intel 80286 microprocessor which has two modes of operation; a real mode, corresponding to the 1 MByte memory addressing capabilities of the older Intel 8086 microprocessor, and a protected mode, allowing addressing capabilities of 16 MBytes. A very popular microcomputer application program is Lotus 1-2-3.TM., which is an electronic spreadsheet originally written in assembly language for the 8086 microprocessor. The task of converting this program to extended memory addressing capabilities of the 80286 microprocessor considerably delayed the introduction of the program to this new memory environment.

SUMMARY OF THE INVENTION

It is therefore an object of the present invention to provide an efficient software tool to aid programmers in modifying source code to enable a computer program to run on a different computer hardware architecture than the architecture for which it was originally written.

It is another object of the invention to provide a software tool that provides expert advice to programmers on the modification of source code for use in an extended address space architecture.

According to the present invention, an extended mode analyzer (EMA) is provided which processes source code modules, detects suspicious instruction patterns and produces recommendations for code modification in a fraction of the time it would ordinarily take a team of programmers to perform the same task. The EMA is a novel application of knowledge based technology to the problem of massive source code conversion. The knowledge base component within the EMA models any given source code module using a hierarchical class/attribute structure. All source lines occurring in a given module are partitioned into homogenous classes characterized by function or instruction type. Correspondences are drawn between class members which constitute instruction sequences related by common elements. When inferencing begins, the existence of class members meeting certain criteria trigger events which change the state of the world as seen by the knowledge base, in turn triggering other state charging events and so on until a state of equilibrium is achieved. The end result of this process is the body of recommendations produced by EMA for source code conversion.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other objects, aspects and advantages will be better understood from the following detailed description of a preferred embodiment of the invention with reference to the drawings, in which:

FIG. 1 is a block diagram providing a general overview of the extended mode analyzer according to the invention;

FIG. 2 a block diagram showing in more detail the extended mode analyzer system according to the invention;

FIG. 3 is a diagram showing the structure of class/attribute hierarchies of the knowledge base;

FIG. 4 is a flow chart showing the EMA process for one line pattern identification with no search;

FIG. 5 is a flow chart showing the EMA process for two line pattern identification with a backward search;

FIG. 6 is a flow chart showing the EMA processes for two line pattern identification with a forward search;

FIG. 7 is a flow chart showing the EMA process for three line pattern identification with a backward search, step 1;

FIG. 8 is a flow chart showing the EMA processes for three line pattern identification with a forward search, step 1;

FIG. 9 is a flow chart showing the EMA process for three line pattern identification with a backward search, step 2; and

FIG. 10 is a flow chart showing the EMA processes for three line pattern identification with a forward search, step 2.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT OF THE INVENTION

The preferred embodiment and best mode for the practice of the invention is in the environment of OS3, the Unisys System 80 operating system, which is being ported to a new Unisys platform. The new platform supports a 64 MByte memory, in contrast to the 16 MByte memory supported by the System 80. The OS/3 operating system consists of approximately 6000 assembly language modules, each of which must be examined and possibly re-coded due to the larger 64 MByte conversion.

The extended mode analyzer (EMA) according to the invention is a knowledge based software tool which analyzes OS/3 code modules and produces detailed recommendations for code modifications based on the 64 MByte conversion requirements. The EMA was written in the Knowledge Engineering System (KES) environment, a commercially available expert system development tool. KES provides an English-like language for the definition of class structures and rules, plus an inferencing mechanism which controls the way in which rules are applied to case specific information stored in the knowledge base class structures. Although the analyzer has been implemented in KES, it will be understood by those skilled in the art that the application could be implemented using any other expert system tool providing the basic capabilities for knowledge representation and inferencing.

The EMA system operates on a Unisys U5000/50 platform under the UNIX.TM. (trademark of AT&T) operation system. OS/3 modules are transferred over a data communications link from the System 80 to the U5000/50 where they are processed by the EMA. A UNIX.TM. shell script controls the cycle of the parsing, analyzing and report generating for each OS/3 module. The final report for each processed module can be scanned at the terminal or sent to a printer for the programmer's inspection.

While the preferred embodiment of the invention has been implemented in the OS/3 environment, those skilled in the art will understand that the teachings of the invention may be applied to other environments and are not limited to Unisys architectures or even operating systems. For example, assembly language application programs written for real memory mode operation in some microprocessors could be analyzed by the EMA to make recommendations for code modifications for running the application programs in protected memory mode of those microprocessors. Other examples will suggest themselves from the following detailed description of the preferred embodiment.

Referring now to the drawings, and more particularly to FIG. 1, there is shown the transformation process of an OS/3 module from its original source form into its final analyzed form. OS/3 modules at 10 are first processed by a C language parser 12 which passes symbolic information 13 on to the system's knowledge base component 14 where instruction patterns are detected and analyzed. Additional output from the parser 12, together with output from the knowledge base component 14, is combined by the output integration process to produce the final recommendation file 16 for each module. The EMA is designed to operate either in interactive mode where a single module at a time is analyzed, or in batch mode where a single command from the user spawns the processes which parse, analyze and create recommendations files for multiple source code modules.

The EMA system, as illustrated in FIG. 2, consists of three major program components: the parser 12, the analyzer 14 and the report formatter 18. As mentioned, the parser 12 is a C language program that translates OS/3 source code into symbolic representation 13 which is meaningful to the analyzer 14. In addition to the OS/3 source modules, the parser 12 receives as inputs an equivalence list 9 of registers and a list 11 of changed global symbols for the two architectures. In addition to the symbolic source information 13, the parser 12 also produces a formatted version 15 of source code for the given module and a summary 17 of parser messages for that module which are later used by the report formatter 18.

The analyzer 14 consists of the knowledge base 20 and inference engine 22 components. All knowledge of OS/3 and details concerning the 64 MByte conversion reside in the knowledge base 20. OS/3 knowledge exists in the form of classification hierarchies which are designed to store the symbolic information produced by the parser 12. These structures give representation to and logically connect all entities in a given OS/3 source module such as instructions, registers and program data. Knowledge of the 64 MByte conversion requirements exists in a group of rules which embody the facts and guidelines one would apply in converting OS/3 source code to the 64 MByte platform.

The inference engine 22 is a program that controls the way in which knowledge base rules are applied. In the case of EMA, the inference engine applies conversion rules to the module-specific information stored in the classification hierarchies in order to draw a conclusion. The output of the inferencing process is 1) a list 23 of recommended code changes for the given module, 2) a trace 24 of the rules used in arriving at these recommendations and 3) a cross reference 25 of all symbol names used on source lines which have been cited for change.

The report formatter 18 integrates the source code 15 and summary 17 output by the parser 12 and the recommended source code modifications 23, the analyzer trace 24 and the analyzer cross reference 25 output by the analyzer 14 to produce the final EMA report 16. This report is used by OS/3 programmers as a guide in making actual source code changes.

OS/3 source code is stored in classification hierarchies which give representation to and logically connect all entities in a given source module 10. The details of the OS/3 conversion problem drive the design of the classification hierarchies which group instructions based on the type of functions they perform. Source lines are effectively partitioned into classes by their functionality or instruction type providing a foundation from which higher level programming concepts can be abstracted. These classification hierarchies can be tailored to provide a representation of source code written in any programming language.

EMA represents conversion knowledge in rules which are triggered by information contained in the classification hierarchies. Each rule corresponds to a programming concept which can be achieved by certain combinations of instructions. Examples of programming concepts identified in OS/3 code are 1) loading the address of a global data structure into a register followed by a clear of the high order byte, and 2) moving two bytes of data from memory into a register and using the data in the register as an address to access other data stored in memory. The programming concepts identified by EMA rules are those which need to be re-implemented for the extended memory platform. While these rules are specific to OS/3 conversion, the abstraction of higher level concepts from these lower level implementation details is a notion which is independent of language or platform. The set of programming concepts one chooses to extract will be determined by the nature and scope of the conversion problem under consideration.

For purposes of code conversion, the difference between the System 80 platform and the new platform is in the amount of addressable memory; 16 MBytes versus 64 MBytes. System 80 memory locations are referenced by a 24-bit address, while addresses on the new platform are 26-bit addresses. The word size in both machines is 32 bits, or 4 bytes. Registers on both machines are also 4 bytes. OS/3 source code was written to accommodate the 24-bit address size on the System 80 and, as written, will not run in the 64 MByte environment. The OS/3 assembler has been modified for the 64 MByte platform in order to accommodate the extended address format. This means that source code running on the new platform will be interpreted differently than the identical source code running on the System 80 platform.

One example of an assembler change for the new platform is the interpretation of the load address (LA) instruction. On the System 80, the instruction "LA Rx,0(,Rx)" causes the contents of the register Rx to be loaded back into Rx, setting the first eight bits of the register to zero. This instruction is commonly used to clear irrelevant data from the top byte of the register after the register has been loaded with address data. On the new platform, the same form of the LA instruction causes the contents of the register Rx to be loaded back into Rx, setting only the first six bits of the register to zero. The new interpretation leaves the last twenty-six bits intact to accommodate the longer address.

If the LA instruction is used in OS/3 code to clear the top byte of a register regardless of the data stored in the lower three bytes, the execution of the same instruction on the new platform will produce undesirable results. The new assembler will clear bits 0-5 leaving data in bits 6 and 7 which may cause a program error. The problem is the use of an address dependent instruction (LA) to perform an address independent function (clearing the top byte of a register) where the instruction is interpreted differently by the new assembler to accommodate the longer address format. LA instructions of this form must be examined in context for data dependency. Those which appear to manipulate non-address data should be replaced by a different instruction which will clear the top byte of a register on the new platform just as the programmer had intended on the System 80.

Since OS/3 was written for System 80 hardware, much of the code takes advantage of the old 24-bit address limit by retrieving, storing and passing address data in 24-bit (3-byte) units. Another coding practice contingent on the 3-byte address limit is the use of the top byte of a word (the eight bits beyond the twenty-four required for storing an address) for passing flags or other program information when address data is stored in the lower three bytes. On the 64 MByte platform, these partial word addressing techniques are no longer valid.

Instructions which manipulate data in three byte units can be easily identified, but not all instructions manipulating data in units of this size necessarily deal with address data. It is perfectly valid to manipulate non-address data in three byte units, and these instructions must remain intact to preserve the existing functionality of the OS/3 code. One of the problems then in converting OS/3 to the 64 MByte environment is determining which instructions manipulate address data and which do not. Since address data and non-address data can be manipulated in the identical fashion, the distinction between the two events is not immediately obvious from the instructions alone.

Prior knowledge of a module's functionality and reference to in-line comments are both valuable aids in recognizing the manipulation of address versus non-address data. In the absence of either of these aids, an experienced OS/3 programmer can infer from program context if an instruction manipulates a memory address or some other type of program data. Contextual clues used by OS/3 programmers are stored as rules in the EMA knowledge base 14. These rules are based on sequences of instructions which a programmer knows are indicative of 24-bit addressing. Three factors complicate the job of scanning manually for instruction sequences: 1) individual instructions making up a sequence are not necessarily adjacent in the code making the pattern difficult to detect, 2) intervening instructions must be examined as they may negate the function of an otherwise adjacent sequence of instructions, and 3) instruction sequences may overlap so that a single instruction belongs to more than one sequence. To complicate matters further, each sequence carries its own rules regarding negation by intervening instructions, and sequences may overlap in such a way that one or more sequences are negated.

While each of these problems is tractable on an individual basis, the complexity involved in scanning even a single source module of 1000 lines with overlapping and nonadjacent sequences can be overwhelming. Knowledge base rules exist to detect sequences of adjacent and nonadjacent instructions, to evaluate the effect of intervening instructions on each sequence of nonadjacent instructions, and to identify overlapping sequences which have common instructions. The following are examples of four separate instruction sequences which might be found in OS/3 code. These instructions indicate that the variables A, B, C, and D are most likely being used to store 24-bit address data:

    ______________________________________
    Sequence 1          SR     R1,R1
                        ICM    R1,3,A
                        SLL    R1,8
    Sequence 2          L      R1,B
                        SLL    R1,8
                        SRL    R1,8
    Sequence 3          SRL    R1,8
                        STH    R1,C
    Sequence 4          LH     R3,C
                        STH    R3,D
    ______________________________________

    ______________________________________
    S1        XR     R1,R2     S2     L    R1,B
    S1        ICM    R1,3,A    S1     XR   R1,R1
    S2        L      R1,B      S1     ICM  R1,3,A
    S1,S2     SLL    R1,8      S4     LH   R3,C
    S4        LH     R3,C      S1,S2  SLL  R1,8
    S2,S3     SRL    R1,8      S2,S3  SRL  R1,8
    S4        STH    R3,D      S4     STH  R3,D
    S3        STH    R1,C      S3     STH  R1,C
    ______________________________________

    ______________________________________
            * .fwdarw. s
                  @ .fwdarw. a
            $ .fwdarw. d
                  ? = q
            # = p & .fwdarw. m
    ______________________________________

    ______________________________________
    ONE LINE PATTERN:
    WHEN
    all attributes of LINE are known
    THEN
    if LINE is a valid pattern then
           if invalid address symbols found then
            tag the symbols "suspect"
           endif
           recommend code changes for this LINE
    endif
    ENDWHEN
    ______________________________________

    ______________________________________
    TWO LINE PATTERN - BACKWARD SEARCH:
    WHEN
    all attributes of LINE are known and
    PREVIOUS line exists
    THEN
    if LINE is not tagged with this pattern and
    LINE and PREVIOUS are a valid pattern then
    if invalid address symbols found then
    tag the symbols "suspect"
    endif
    recommend code changes for one or both lines
    tag LINE with this pattern
    set back search for LINE to success
    set PREVIOUS line to TRUE PREVIOUS line
    else
    if back search for LINE is not set then
    if PREVIOUS negates this pattern then
    set back search for LINE to failure
    set PREVIOUS line to TRUE PREVIOUS line
    else
    set PREVIOUS back one line
    endif
    endif
    endif
    ENDWHEN
    ______________________________________

    ______________________________________
    TWO LINE PATTERN - FORWARD SEARCH
    IDENTIFICATION PART:
    WHEN
    all attributes of LINE are known and
    NEXT line exists
    THEN
    if LINE is not tagged with this pattern and
    LINE and NEXT are a valid pattern then
    if invalid address symbols found then
    tag the symbols "suspect"
    endif
    recommend code changes for one or both lines
    tag LINE with this pattern
    set forward search for LINE to success
    set NEXT to TRUE NEXT
    endif
    ENDWHEN
    SEARCH PART:
    WHEN
    all attributes of LINE are known and
    NEXT line exists and
    line after NEXT exists
    THEN
    if forward search for LINE is not set then
    if LINE is a valid target line then
    if NEXT line negates pattern then
    set forward search to failure
    set NEXT line to TRUE NEXT line
    else
    set NEXT ahead one line
    endif
    endif
    endif
    ENDWHEN
    ______________________________________

    ______________________________________
    THREE LINE PATTERN - BACKWARD SEARCH -
    STEP ONE:
    WHEN
    all attributes of LINE are known and
    PREVIOUS line exists
    THEN
    if LINE is not tagged with this pattern and
    LINE and PREVIOUS are a valid pattern then
    if invalid address symbols found then
    tag the symbols "suspect"
    endif
    recommend code changes for one or both lines
    tag LINE and PREVIOUS with this pattern
    set back search for LINE to success
    set "next pattern line" of PREVIOUS to LINE
    set PREVIOUS to TRUE PREVIOUS
    else
    if back search for LINE is not set then
    if PREVIOUS negates this pattern then
    set back search for LINE to failure
    set PREVIOUS to TRUE PREVIOUS
    else
    set PREVIOUS back one line
    endif
    endif
    endif
    ENDWHEN
    ______________________________________

    ______________________________________
    THREE LINE PATTERN - FORWARD SEARCH -
    STEP ONE
    IDENTIFICATION PART:
    WHEN
    all attributes of LINE are known and
    NEXT line exists
    THEN
    if LINE is not tagged with this pattern and
    LINE and NEXT are a valid pattern then
    if invalid address symbols found then
    tag the symbols "suspect"
    endif
    recommend code changes for one or both lines
    tag LINE and NEXT with this pattern
    set forward search for LINE to success
    set "previous pattern line" of NEXT to LINE
    set NEXT line to TRUE NEXT line
    endif
    ENDWHEN
    SEARCH PART:
    WHEN
    all attributes of LINE are known and
    NEXT line exists and
    line after NEXT exists
    THEN
    if forward search for LINE is not set then
    if LINE is a valid target line then
    if NEXT line negates pattern then
    set forward search to failure
    set NEXT line to TRUE NEXT line
    else
    set NEXT ahead one line
    endif
    endif
    endif
    ENDWHEN
    ______________________________________

    ______________________________________
    THREE LINE PATTERN - BACKWARD SEARCH -
    STEP TWO:
    WHEN
    all attributes of LINE are known and
    LINE is secondary target line and
    PREVIOUS line exists
    THEN
    if LINE is not tagged with this pattern and
    LINE and PREVIOUS are a valid pattern then
    if invalid address symbols found then
    tag the symbols "suspect"
    endif
    recommend code changes for one or both lines
    tag LINE with this pattern
    set back search for LINE to success
    set PREVIOUS to TRUE PREVIOUS
    else
    if back search for LINE is not set then
    if PREVIOUS negates this pattern then
    set back search for LINE to failure
    set PREVIOUS to TRUE PREVIOUS
    else
    set PREVIOUS back one line
    endif
    endif
    endif
    ENDWHEN
    ______________________________________

    ______________________________________
    THREE LINE PATTERN - FORWARD SEARCH -
    STEP TWO
    IDENTIFICATION PART:
    WHEN
    all attributes of LINE are known and
    LINE is secondary target line and
    NEXT line exists
    THEN
    if LINE is not tagged with this pattern and
    LINE and NEXT are a valid pattern then
    if invalid address symbols found then
    tag the symbols "suspect"
    endif
    recommend code changes for one or both lines
    tag LINE with this pattern
    set forward search for LINE to success
    set NEXT line to TRUE NEXT line
    endif
    ENDWHEN
    SEARCH PART:
    WHEN
    all attributes of LINE are known and
    LINE is secondary target line and
    NEXT line exists and
    line after NEXT exists
    THEN
    if forward search for LINE is not set then
    if NEXT line negates pattern then
    set forward search to failure
    set NEXT line to TRUE NEXT line
    else
    set NEXT ahead one line
    endif
    endif
    ENDWHEN
    ______________________________________

• Inventors
  Skidmore, Wendy C.;
• Assignee
  Unisys Corporation (Blue Bell, PA)
• Published
  Jan-30-1996
• Current US Classes:
  706/45
  717/106
  717/117
  717/143
  717/147
• Application #
  112631
• International Classes
  G06F 003/00
• Field of Search
  395/800 395/700 395/600 395/50 395/54 395/500 364/274.5 364/DIG.
• Examiner
  Bowler; Alyssa H.
• Agent
  Axenfeld; Robert R., Starr; Mark T.
• US Patent References:
  4533997
  4667290
  4803641
  4935876
  4974191
  5021992
  5127104
  5159687
  5241678