Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1998-01-07
2003-05-20
Courtenay, III, St. John (Department: 2151)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C709S241000, C709S241000, C712S010000, C712S011000, C712S015000
Reexamination Certificate
active
06567837
ABSTRACT:
This application is related to application Ser. No. 08/525,948, filed Sep. 8, 1995 for “Distributed Processing Systems Having A Host Processor And At Least One Object Oriented Processor”, now U.S. Pat. No. 5,708,838 issued Jan. 13, 1998 and application Ser. No. 08/683,625, filed Jul. 17, 1996 for “Method And Apparatus For Distributed Processing And Rapid ASIC Development”, now U.S. Pat. No. 6,072,944 issued Jun. 6, 2000, the complete disclosures of which are hereby incorporated by reference herein in their entireties.
This application is also related to co-pending applications Ser. No. 09/004,174 filed Jan. 7, 1998 for “Event-Reaction Communication Protocol in an Object Oriented Processor Array”, now U.S. Pat. No. 6,052,729 issued Apr. 18, 2000, and Ser. No. 09/003,993 filed Jan, 7, 1998 for “Central and Distributed Script Servers in an Object Oriented Processor Array” (IQS-015), both filed simultaneously herewith, and the complete disclosures of which are hereby incorporated by reference herein.
BACKGROUND OF THE INVENTION
1. Field of the Invention
The invention relates to object oriented processors and processor systems. More particularly, the invention relates to an object oriented processor or processor system which utilizes a library of selectable processor objects in order to implement an array of processor objects. Although not limited thereto, the processors or processor system is preferably arranged such that the processor objects are self-instantiated in virtually any combination, and the processors or processor system is controlled by a high level scripting language.
2. State of the Art
Modern computers permit seemingly simultaneous execution of many operations by interrupting the microprocessor periodically to execute several software threads in turn. For example, as a user types on a keyboard, the input from this peripheral to the microprocessor is seemingly simultaneously displayed by the microprocessor on a video display peripheral. In reality, the microprocessor is interrupted periodically from displaying output on the video display in order to obtain input from the keyboard. It is only because the microprocessor operates at a very high speed that there is an illusion of simultaneity. In a more complex processing system, there may be many threads vying for microprocessor attention at any time. For example, in a desktop multimedia computer, several peripheral devices must be controlled by the microprocessor in a seemingly simultaneous manner in order to produce the proper results and different operations such as displaying video and playing audio must be handled by separate threads. The programming environment in a system having so many threads is incredibly complex. The system software must be written to schedule microprocessor attention to each thread, assign priority to each thread and allow peripherals to interrupt the microprocessor at appropriate times. The system software must then schedule tasks for the microprocessor in response to the interrupts from various peripherals.
In addition to scheduling problems, software in a multi-tasking (multi-threaded) system is difficult to debug. Single stepping techniques cannot be used, since different threads may depend on the results of other threads, and only a single thread can be operational during single stepping.
The handling of interrupts by the microprocessor is determined in part by the bus protocol and in part by the design of the microprocessor itself. Typically, the bus is designed to work with a particular microprocessor or group of microprocessors; and peripheral devices are designed to work with a particular bus. Moreover, each microprocessor-bus system handles interrupts in a different way. This makes it difficult, if not impossible, to adapt program code used on one microprocessor-bus system for use on another.
In order to relieve the host processor from performing every task, multiprocessor systems have been proposed. Some multiprocessor systems are successful in dividing tasks among processors when the tasks are well defined. For example, it is not uncommon to divide tasks between a data processor and a signal processor in systems which deal with signals and data in real time. It is more difficult to divide data processing tasks among several data processors. The operating system must decide which tasks will be performed by which processor and must schedule tasks so that processors do not remain idle while waiting for new tasks or while waiting for other processors to complete tasks so as to provide needed results. Consequently, there has been very little success in developing a general purpose multiprocessor system and there is no standard programming language for programming a multiprocessor system.
U.S. Pat. No. 5,095,522 to Fujita et al. discloses an object-oriented parallel processing system which utilizes “concept objects” and “instance objects”. The system utilizes a host processor and a plurality of general purpose processors which are programmed by the host processor. The host user must program (generate concept and instance objects) for each processor before parallel processing can begin. Fujita et al. considers this aspect of their system to be a feature which allows dynamic changes in the functionality of each of the processors. However, this aspect of their system greatly complicates the host processor software.
Similarly, U.S. Pat. No. 5,165,018 to Simor describes a system in which “nodes” are provided with generic configuration rules and are configured at runtime via resource definition messages from the control node. Simor considers this aspect of his system to be an advantage which, among other things, “isolates the hardware from the software” and “allows programs to be written as if they were going to be executed on a single processor.” In addition, Simor's system permits programs to be “distributed across multiple processors without having been explicitly designed for that purpose.”
Both Fujita et al. and Simor utilize general purpose processors and attempt to isolate the hardware from the software, freeing the programmer to write code as if it were being executed on a single processor. However, as mentioned above, writing multithreaded software for a single processor is very complex. Neither Fujita et al. nor Simor offer any solution for this complexity.
3. Related Inventions
Related application Ser. No. 08/525,948 approaches the problem of distributed processing in a manner which is completely different from that of either Fujita et al. or Simor. The system disclosed in the '948 application utilizes processors which have been pre-programmed with functionality for a specific purpose and thereby integrates hardware with software. The developer chooses specific hardware (object oriented processors) in a manner similar to choosing specific software objects. This approach requires that the developer be very aware of the hardware used in the system, but frees the developer from writing much of the code used to implement the system. Accordingly, the developer need only write a minimal amount of relatively high level code to link the pre-programmed object oriented processors which contain statically stored code for performing specific tasks. This approach is based on the belief that writing and de-bugging code is more time consuming and more expensive than linking together processors which contain pre-written, bug-free code. This approach enables rapid system development, relieves the host processor of many scheduling tasks, simplifies de-bugging, enables cross-platform support, allows software emulation of hardware devices, as well as providing other advantages.
According to the '948 application, object oriented processors communicate with each other and/or with the host processor via the exchange of high level messages. This earliest implementation of the communication protocol required that the host poll at least some of the object oriented processors (i.e. those responsible for processing input data) to determine the availability of data. This was eventually found
Bullock, Jr. Lewis A.
Courtenay III St. John
Gallagher Thomas A.
Gordon David P.
IQ Systems
LandOfFree
Object oriented processor arrays does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Object oriented processor arrays, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Object oriented processor arrays will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3059901