JP2002542524A - Object-oriented processor array - Google Patents

Abstract

(57) Abstract An object-oriented processor array includes a library of functional objects that are instantiated by command through system objects and communicate through a high-level language. An object-oriented processor array may be embodied in hardware, software, or a combination of hardware and software. Each functional object may include a separate hardware processor or may be embodied as a virtual processor within the operation of a single processor. In one embodiment, the object-oriented processor array is formed on a single chip or on a single processor chip and associated memory chips. When several objects are instantiated on a single chip, pins are assigned to each object via a high-level command language. A method and apparatus for allocating memory to an instantiated object is disclosed, wherein the instantiated object communicates directly with a script server, the script server responding to data events generated by the instantiated object. It is programmed to respond. One script server may serve several object-oriented processor arrays to service, or an object-oriented processor array may have a local script server. A method and apparatus for scheduling when several virtual processors are embodied within the operation of a single microprocessor is also disclosed. In accordance with the present invention, communication is based on an "event response" model, in which when a processor object has a message to send, the "event response" model is a data register registered by the target recipient (usually the host) of the message. Raise an event. The target responds to the data event by allowing a variable amount of I / O exchange between the processor object and the target before acknowledging the event. In one embodiment, no other data events are sent to the target until the data event is acknowledged. In another embodiment, a fixed number of data events may be pending at the same time.

Description

DETAILED DESCRIPTION OF THE INVENTION

BACKGROUND OF THE INVENTION FIELD OF THE INVENTION The present invention relates to object-oriented processors and processor systems.
In particular, the present invention relates to an object-oriented processor or processor system that utilizes a library of selectable processor objects to execute an array of processor objects. Preferably, but not limited to, the processor or processor system is arranged such that the processor objects are self-instantiated in virtually any combination, and the processor or processor system is Preferably, an event-reactive communication protocol is utilized, over which the processor objects communicate, and the event-reactive communication protocol is controlled by a high-level scripting language.

[0002] 2. 2. State of the Art Modern computers allow the simultaneous execution of many operations to be seen by periodically interrupting the microprocessor and executing several software threads in turn. For example, as the user types the keyboard, input from this peripheral to the microprocessor is simultaneously displayed as it appears on the video display peripheral by the microprocessor. In effect, the microprocessor is periodically interrupted from displaying output on a video display to obtain input from a keyboard. It is only because the microprocessor operates at a very high speed where there is an illusion of synchronization. In more complex processing systems, there are many threads competing for microprocessor attention at all times. For example, in a desktop multimedia computer, some peripherals must be controlled by a microprocessor, seemingly simultaneously, to produce appropriate results, and to display video and play audio. Different operations must be handled by separate threads.
The programming environment in such a system with many threads is very complex. System software must be written to schedule the microprocessor's attention to each thread, assign a priority to each thread, and allow the peripheral to interrupt the microprocessor at the appropriate time. The system software must then schedule tasks for the microprocessor in response to interrupts from various peripherals.

[0003] In addition to scheduling issues, software in multitasking (multithreaded) systems is difficult to debug. Since different threads depend on the results of other threads, a single stepping technique cannot be used, and only a single thread can be active during a single stepping.

[0004] The processing of interrupts by the microprocessor is partially based on a bus protocol.
Some are determined by the design of the microprocessor itself. Typically, a bus is designed to work with a particular microprocessor or a particular group of microprocessors, and peripherals are designed to work with a particular bus. Further, each microprocessor-bus system handles interrupts differently. This makes it difficult, if not impossible, to adapt the program code used in one microprocessor-bus system for use in another microprocessor-bus system.

To relieve the host computer from performing all tasks, multiprocessor systems have been proposed. Some multiprocessor systems have successfully split a task between processors when the task is well defined. For example, it is not uncommon to divide tasks between a data processor and a signal processor in a system that handles signals and data in real time. Dividing the data processing task between several data processors is more difficult.
The operating system must determine which tasks will be performed by which processor, and the operating system will complete the tasks while the processor is waiting for a new task or providing the required results. Tasks must be scheduled so that they do not remain idle waiting for other processors to do so. As a result, the development of general purpose multiprocessor systems has been largely unsuccessful, and there is no standard programming language for programming multiprocessor systems.

[0006] US Pat. 5,095,522 is "Concept (concept).
An object-oriented parallel processing system using "objects" and "instance objects" is disclosed. The system utilizes a host processor and a plurality of general-purpose processors programmed by the host processor.
The host user programs each processor before parallel processing begins (
Concept and instance objects must be generated). Fujita et al. Consider this aspect of these systems to be a feature that allows for dynamic changes in the functionality of each processor. However, this aspect of these systems greatly complicates the host processor software.

[0007] Similarly, US Pat. No. 5,165,018 describes a system in which "nodes" have generic configuration rules and are configured at runtime via resource definition messages from control nodes. Simor takes advantage of this aspect of his system, inter alia, by "separating the hardware from the software" and "allowing the program to be written as if the program were to be executed on a single processor." I believe. Further, Simon's system allows a program to be "spread across multiple processors without being explicitly designed for that purpose."

[0008] Fujita et al. And Simor both use general-purpose processors and attempt to separate hardware from software, with programmers writing code as if the code were running on a single processor. release. However, as noted above, writing multi-threaded code to a single microprocessor is a daunting task. Neither Fujita nor Simor propose any solution to this problem.

[0009] 3. Related Invention Related Application Serial No. 08 / 525,948 is Fujita et al. Or Sim
It addresses the problem of distributed processing in a completely different way to either or.
Related application Serial No. No. 08 / 525,948 discloses a system comprising:
It utilizes a processor that is pre-programmed with specific purpose functionality, thereby integrating hardware with software. The developer selects specific hardware (an object-oriented processor) in a manner similar to selecting a specific software object. This approach requires the developer to be very familiar with the hardware used in the system, but relieves the developer from writing most of the code used to run the system. Thus, developers only need to write a minimal amount of relatively high-level code to link pre-programmed object-oriented processors containing statically stored code to perform specific tasks. . This approach is based on the idea that writing and debugging code consumes more time and is more costly linking together processors containing pre-written, bug-free code. This approach allows for rapid system development,
Releases many scheduling tasks from the processor, simplifies debugging, and provides cross-platform support.
rt), enables software emulation of hardware devices, and provides other advantages.

[0010] The related application Serial No. In accordance with 08 / 525,948, the object-oriented processors communicate with each other and / or with the host processor via the exchange of high-level messages. The earliest implementation of the communication protocol required the host to poll at least some object-oriented processors (i.e., those responsible for processing input data) to determine data availability.
This eventually proved to defeat the purpose of simple coding, as the host code had to be written in a manner that frequently scanned all possible input sources. Ultimately, it was determined that this polling caused undesirable overhead and coding complexity. Since many first-developed object-oriented processors operated in real time, the polling scan speed was high and the overhead was substantial. Furthermore, early communication protocols did not provide information about the source of the data. It was instead derived by a specific information request by the host. Thus, some message exchanges may have been required before both data and source were determined.

Related application Serial No. 08 / 683,625 discloses a distributed processing system in which one or more object-oriented processors are embodied as a collection of components on a single ASIC chip. This related application includes an enhanced communication language in which the host does not need to poll the object-oriented processor and messages from one processor to another include source and destination addresses. This communication protocol is sometimes referred to as "event driven." During subsequent development of this event-driven communication architecture, it became apparent that programming the event-driven model was somewhat complicated and that communication bandwidth was not easily conserved.

In both related applications, each object-oriented processor has the functionality to define its physical connectivity. In particular, as embodied on a single chip, each object-oriented processor (a collection of object-oriented processors)
Provides a number of pins for coupling the processor to other devices. According to the previously disclosed embodiment of the object-oriented processor, the functionality of each pin is substantially
Fixed when the object-oriented processor is manufactured. For example, the related application S
rial no. As disclosed in 08 / 525,948, the user interface controller utilizes 37 pins, most of which have a set of functionality. Some of those pins have alternate functionality. For example, pins A0 to A7 are auxiliary ports. However, pins A1 and A2 are
D can be used when enabling the pin, and pins A3-A7 can be used when the LED enables the pin. Nevertheless, for the most part, the functional resources of an object-oriented processor are predefined for certain pins and cannot be changed substantially by the developer / user.

SUMMARY OF THE INVENTION As used herein, the term “object-oriented processor array” refers to a collection of object-oriented processors, each object-oriented processor incorporating a separate hardware processor, or each object-oriented processor. A collection of object-oriented processors embodied as virtual processors where the processors share the same hardware processor, or as any combination of separate hardware processors and virtual processors.

Accordingly, an object of the present invention is to provide enhanced post-manufacturability configurability.
object-oriented processor array having a high availability.

It is also an object of the present invention to provide an object-oriented processor array on a single chip having a large number of pins whose pin functionality is configurable by a developer / user.

It is another object of the present invention to provide an object-oriented processor array that includes a library of functionalities that can be virtually selected in any combination.

It is a further object of the present invention to provide an object oriented processor array that includes a library of functionality that can be assigned to pins via software instructions.

It is a further object of the present invention to utilize an enhanced communication protocol that conserves bandwidth and allows a developer / user to select a level of coding simplicity in exchange for object latency. To provide an object-oriented processor array.

It is another object of the present invention to provide an object oriented processor array that utilizes memory efficiently.

Overview In accordance with these objectives, which will be described in detail below, the object-oriented processor array of the present invention comprises a readable memory that includes a library of configurable (programmable) functions (also called objects); And writable memory in which the object is instantiated and configured. For details,
The object-oriented processor array is automatically instantiated in writable memory at power-up, calls other objects to be instantiated in writable memory in response to commands from the host processor or boot ROM, and Includes system functionality (system objects) that maintain the active task list and other information about the instantiated objects. The object oriented processor array according to the present invention further includes a communication interface, an input message processor and an output message processor. The communication interface allows the object oriented processor array to communicate with other object oriented processor arrays and / or with a host processor or script server. The output message processor preferably includes an output flow manager for processing messages from processor objects in the array, and a central output registry for queuing messages. According to the preferred embodiment, the object-oriented processor array comprises:
It is embodied as a virtual machine formed from software running on a microprocessor. Accordingly, software embodying an object-oriented processor machine array is provided with a timing kernel that simulates parallel processing and a memory manager that allocates memory to objects when they are instantiated.

Self-Instantiation In accordance with a preferred embodiment of the present invention, the library of functionality is configured as a library of objects stored in ROM. Each object includes a parser layer, a functional layer (which preferably includes a runtime layer and a background layer), a time layer, and an instantiation layer. System objects are also stored in ROM and are automatically instantiated in RAM when the processor array is powered on, and in a preferred embodiment of the present invention, the active task list
Table (functional pointer to instantiated objects), active task list name table (names of instantiated objects), and active task list data space (for each instantiated object) Allocate RAM for a pointer to the allocated memory block). System objects handle global methods and functions that are similar to other objects, but common to all objects. The main function of system objects is to call objects and ask for objects to instantiate themselves.

In response to a high level command from the host processor (or boot ROM), the system object invokes the object's instantiation layer in the object library and instantiates the object itself in RAM. Command. The object instantiation layer calls the memory manager to request the allocation of RAM. The memory manager returns a pointer (to the starting address in RAM) to the object. According to one embodiment, the object returns a pointer to the system object after completing any necessary instantiation to complete the instantiation. After the object informs the system object that the instantiation was successful, the system object stores a pointer in the active task list table for the portion of the ROM where the object resides. Each pointer in the active task list is associated with an index number. The system object also stores the name of the instance of the object in the active task list name table associating that name with the same index number, and stores a pointer to the allocated memory block, also at the same index number. Store in the active task list data space associated with. The system object then recalculates the scheduling of the object in the active task list. According to another embodiment, each instantiated object stores a pointer to its allocated RAM in a reserved area of RAM.

An instantiated object arranges its allocated RAM into several parts. The first part is the output message header, which contains the object instantiation, message length, active
Contains a pointer to the output buffer for the task list index, object instantiation flow priority, message type and source ID. This first part is common to all objects, ie all instantiated objects have this part in their allocated RAM. The second part is the private data used by the cell in performing its functionality. This second
Are different for each instantiated object, and some objects may arrange additional portions of the allocated RAM. Once the object is thus instantiated, physical pins can be assigned for object instantiation by sending a high-level command from the host processor (or boot ROM) to the instantiated object. .

The input message processor checks the syntax of all incoming messages,
It buffers the message, examines the command, looks at the active task list name table, determines the index number for the instantiated object to which the command was directed, and passes the message and index number to the object's parser layer. The object parser layer interprets the pin assignment message and stores the pin assignment for the named instantiation of the object in a private data area of RAM.

According to another preferred aspect of the invention, an object may be instantiated several times as long as sufficient hardware resources (pins and RAM) are available to support another instantiation. The system object keeps track of all object instantiations by placing entries in the active task list table, active task list name table, and active task list data space table. Hold. In addition, memory
The manager keeps a pointer to the memory heap used and issues an error message when needed to allocate more RAM available. After a pin has been assigned for object instantiation, a message flow priority can be assigned. According to the preferred embodiment, a flow priority of 0-7 may be assigned. Here, 0 indicates the priority to be polled, and 1-7 indicates a level of increasing importance. When the priority level is greater than zero, the output message from the object will be generated automatically. The flow priority is stored by the instantiation of the object in its output message header in RAM. During instantiation, the system object starts a global variable or counter that indicates the active task number = 0. When that variable is> 0, the system object returns control to the timing kernel that scans the active task list. Each time an object is instantiated, all active tasks are stopped, and all instantiated objects are called into their timing layer and tasks are scheduled. The system object assigns an offset for each object instantiation that the timing layer stores in private data. The object returns the worst case time to the system object and uses the worst case time to calculate an offset for the next active task. The time between the worst case time and the actual time is advantageously used by system objects for system (background) functions, i.e., otherwise, system functions are not scheduled and therefore require no overhead.

During basic message processing operations , messages for a particular instantiation of an object are parsed by an input message processor, which
The active task list name table is scanned for an index to the active task list, ie, a pointer to the addressed object instantiation. The object receives a message from the input message processor, and an index. The object uses the index and the active task list data space table to find out which instantiation of itself is being addressed. The message from the object instantiation is placed in the output message header portion of its RAM, and a request for registration is sent to the central output registry. Its output registry is
Keep a queue of pointers to messages in the output message header portion. The queue is scanned by one or more output flow managers, which form output messages from information held in output message header portions.

Central Script Server In accordance with one embodiment of the present invention, one or more object-oriented processor arrays are coupled to a central script server or processor. Messages resulting from data events on any of the processor objects are sent to a central script server for processing. The central script server parses the message received from the processor object and executes the script written for this type of data event. Scripts typically result in sending a message to another processor object on the same array as the array containing the processor object with the data event or on a different array. According to one aspect of the invention, the message flow is based on an event reaction architecture.

Event Response Model The event response architecture for message flow is a flexible way to assign priorities to multiple bus users that conserves bandwidth and simplifies host processor programming. According to the event response model, when a processor object has a message to send, the processor object generates a data event that is registered by the target recipient of the message (typically a script server). The target responds to the event by allowing a variable amount of I / O exchange between the processor object and the target before acknowledging the data event. According to one embodiment, no other data events are sent to the target until the data event is acknowledged. According to another embodiment,
A fixed number of data events may be pending at the same time. In one embodiment of a multi-node system, each node (each object-oriented processor array) is aware of network traffic, and data events associated with a particular target (script server) receiver will cause that receiver to Registered by all nodes that have as a goal and by goal. The number of data events that can be pending at any one time is determined by the goal and is known for each node.
The goal arbitrates message flow based on the registration of data events. The arbitration may be FIFO based, or the targeted receiver may grant priority to subsequently generated data events having a higher flow priority. As described above, the output message buffer of the instantiated object is provided for message flow priority. The event response model is based on the number of pending data events that the script server code allows.
Allows to be linear in the number of threads in server code.

According to another embodiment, a central hub (script server) arbitrates the exchange of messages between multiple object-oriented processor arrays coupled to that hub by individual links rather than a common bus. The hub communicates with each array according to the message flow priority of the cells in the array. The number of threads in the code on the hub depends on the total number of pending data events allowed in each object-oriented processor array.

Distributed Script Server In accordance with another embodiment, an internal script server is provided that is local to one or more object-oriented processor arrays. In this "distributed scripting" embodiment, additional functionality for registering and queuing data events, and an event script lookup table for determining which events are associated with internal messages Is provided to the output message processor to control according to the event response protocol. The input message processor is provided with additional functionality for queuing and buffering messages for objects in the array.

High-Level Language In accordance with another preferred aspect of the present invention, a high-level language is provided for communication between an object-oriented processor and a host processor during setup and operation. The high-level language according to the invention is an event reaction protocol,
Efficient addressing scheme, better use of bandwidth and simplified hosts
Includes support for parsing. In accordance with the preferred embodiment, high-level language messages are exchanged in variable length packets with well-defined headers. The header includes addressing information followed by an indication of the type of message, an indication of the type of method or data, and an indication of the length of the remaining data in the packet. High-level languages are self-aligned, simple, and robust.

As mentioned above, an object-oriented processor array in accordance with the present invention implements software on microprocessors, field programmable gate arrays, multiple microprocessors, and other hardware devices. It is embodied in many alternative configurations, including:

[0033] Additional objects and advantages of the present invention will become apparent to those skilled in the art with reference to the detailed description taken in conjunction with the drawings provided.

Detailed Description of the Preferred Embodiment Basic Hardware-Software Example Referring to FIG. 1, an object-oriented processor array 10 according to a preferred embodiment of the present invention comprises a readable memory 12, a writable It includes an actual interface such as a memory 14, one or more programmable processors 16 coupled to the memories 12 and 14, and a number of pins 18 coupled to the processor 16. As shown and described in further detail below, one embodiment of the present invention resides on a single chip, which includes a single general-purpose microprocessor, RAM and ROM, and includes multiple Including pins. However, one skilled in the art will recognize that the functional aspects of the present invention may be embodied using many different types of hardware and / or software.

Turning now to FIG. 2 and referring to FIG. 1, the readable memory 12 is instantiated and configured in a writable memory 14 as described in detail below. (Possible) functions (which are also called objects). In particular, the object-oriented processor array 10 includes a system object 22,
Is automatically instantiated in writable memory at power-up, as described in detail below, and calls other objects from library 20 to
Writable memory 1 in response to a command from the host processor or boot ROM
4 instantiated. Once the object is instantiated, it appears as an active object in the object-oriented processor array 10, for example, 23a, 23b, 23c. The object-oriented processor array 10 further includes a communication interface 24, an input message processor 26, and an output message processor 28. The communication interface 24 includes a communication link or bus 25 where the active objects 23a-23c communicate with other object-oriented processor arrays and / or host processors or script servers, which may be physical buses, multi-ported memories, or even wireless. (Can be in the form of a link). The communication interface also allows system object 22 to receive commands from a host or boot ROM. The input message processor 26 is responsible for routing incoming messages and performing basic syntax parsing. Once a message has been received and is syntactically correct, it is routed to the parser layer of the addressed object, as described below. The output message processor 28 includes an output flow manager 32 for processing messages from active objects in the object-oriented processor array 10 to processors external to the object-oriented processor array 10, and a central output registry 34 for queuing messages. It is preferable to include All input to output message processor 28 is through central output registry 34. As described in detail below, at the same time that the event occurs in the object, the object calls the central output registry 34 and provides a handle to a standard structure that is placed in the output queue. The output queue is scanned by the output flow manager, which looks for information about the output queue and, in some cases, the priority to which the object was assigned. Once the flow manager determines which objects have subsequent use of the port, the flow manager determines the type of message (
A standard structure that determines any data associated with the message derived by referencing the pointer, eg, data event, command acknowledgment, the name of the object that caused the message, the type or source of the data, and the pointer. A message is constructed using the information in. The newly composed message is then sent to the output port and sent.

As described above, according to one embodiment, the object-oriented processor array 10 is embodied as a virtual machine formed from software running on a microprocessor. Accordingly, the software embodying the object-oriented processor array 10 is provided with a timing kernel 36 that simulates parallel processing and a memory manager 38 that allocates memory to objects when they are instantiated. ing. Also, when the object-oriented processor array 10 is embodied as a virtual machine, the interconnections between the components shown in FIG. Will be recognized.

Basic Features of Processor Objects Referring now to FIGS. 2 and 3, each object, eg, 23c, includes a parser layer 40, a functional layer 42, a time layer 44, and an instantiation layer 46. The parser layer contains the intelligence to interpret vocabulary associated with a particular object and to perform tasks that can be performed immediately. As described above, each object has certain predefined functionality that is configurable. Thus, the vocabulary for each object is somewhat governed by the functionality it contains, and will also include some generic vocabulary for communication. An example of how the vocabulary of each object is different is described in Related Application Serial No. 08 / 529,948. The parser layer is the means by which the instantiated object is initialized and configured, and by which the object receives messages. The functional layer 42 contains all the intelligence needed to perform the predefined functionality of the object, and is preferably divided into a routine layer and a background layer. The routine layer contains the functionality required to be performed on a continuous basis, and the background layer contains the functionality for relatively low priority tasks. For example, if the object is coupled to an input device, scanning the input device
Will be part of the runtime layer. The functions performed in the background layer typically take a long time to perform, for example, a slow communication interaction with the device socket. The time layer 44 participates in the scheduling of the runtime layer by providing information about the dynamic performance and behavior of the particular object to the system object 22, as described more fully below. The instantiation layer 46 performs the tasks required to instantiate an object when it is invoked by a system object, as described more fully below.

As mentioned above, all objects, eg, 23a-23c, are preferably stored in ROM. The system objects 22 are also preferably stored in ROM and are instantiated automatically when the object-oriented processor array 10 is powered on. System object 2
2 instantiates a portion 14a of RAM 14 for itself, and an active task list table 14b (a pointer to the instantiated object), an active task list name table 1
RAM for 4c (name of instantiated object) and active task list data space table 14d (pointer to allocated memory block for each instantiated object)
14 in part. System objects 22 are similar to other objects, but global methods and functions that are common to all objects (eg, turn on / off exceptions, return shell state, etc.—shell) States handle, for example, pending events, pending acknowledgments, instantiated objects, communication errors, etc.), and consist essentially of only the parser layer. The primary function of a system object is to call other objects to be instantiated.

Initialization, Configuration and Operation Turning now to FIG. 4 and referring to FIGS. 2 and 3, the initialization, configuration and operation of an object-oriented processor array is described in terms of power. 4 begins when applied to the object oriented processor array as shown at 200 in FIG. Upon power-on, the system objects are automatically initialized as shown at 202 in FIG. The system object is
Initialize a global variable or counter indicating 0 active tasks. This variable is incremented each time the object is instantiated. When the variable is> 0, as indicated by decision point 204 in FIG. 4, the timing kernel 36 determines the active task list table 1 as indicated by 206 in FIG.
Scan 4b. However, initially, the only action that occurs after a system object is instantiated is the receipt of a command message to instantiate the object. Whenever a message is received as shown at 208 in FIG. 4, input message processor 26 checks the syntax of the message, and at 210 the message is sent to the system object (SO).
To determine if there is. Although not shown in FIG. 4, if the syntax of the message is incorrect, input message processor 26 will prepare an error message to be queued in central output registry 34. If the incoming message is determined at 210 to be for a system object (i.e., a command to instantiate the object), the input parser passes the command through the system object and then the system object is hard-coded at 212. Check wear resource availability and determine if enough pins are available to instantiate the object called in the command. Specifically, the system object queries the object's instantiation layer to determine which resources are needed to instantiate the object, and then determines whether there are sufficient resources (eg, pins and memory) To decide. If the system object determines at 212 that there are not enough pins to instantiate the object (due to other object instantiations that were earlier than this object), the system object returns an error message at 214 Buffer and send a pointer to the output registry and return an error message to the host. Control is then returned at 206 to the timing kernel, which scans the active task list.

If it is determined at 212 that sufficient resources are available to instantiate the object, the system object calls the object instantiation layer in the object library at 216 and assigns it to the object. Instructs itself to be instantiated in RAM 14. The object instantiation layer calls the memory manager 38 (at 218 in FIG. 4) and requests an allocation of RAM 14 (eg, 14e). The memory manager checks the availability of the RAM at 220 and sends an error message at 214 if sufficient memory is not available. If sufficient RAM is available, the memory manager 38 returns a pointer (for the starting address in RAM) to the instantiation layer at 222, which receives the pointer at 224 and arranges the memory. I do.
The memory manager also increments the heap pointer at 222, and the heap pointer is used by the memory manager and at 220 sufficient RA
Determine if M is available for another instantiation. Instantiation layer 4
After 6 successfully completes the instantiation, the instantiation layer 46
Inform the system object 22 that the instantiation was successful and send a pointer to the system object (SO). When an object is instantiated, the instantiation layer arranges (at 224) its allocated RAM into organized parts. The first part is the output message header, which contains a pointer to the output buffer of the object instantiation, the message length, the active task
Includes list index, object instantiation flow priority, message type and source ID. The first part is common to all objects, i.e. all instantiated objects arrange a part of their allocated RAM in this way. One or more other portions of the RAM are arranged for private data to be used by the instantiated object in performing its functionality. It should be noted that message flow priority is a variable chosen by the developer and is assigned to object instantiation during array initialization. Message flow priority is described in more detail below with respect to the "event response" communication protocol.

At 228, the system object (SO) 22 stores a pointer to the portion of the ROM where the object resides in the active task list table (ATLT) 14b. Each pointer in the active task list table is associated with an index number, and the index number for the pointer is given to the instantiation layer by a system object, which instantiates the index number in a portion of RAM . , Part of which was configured for storage of static variables. It should be appreciated that the aforementioned layers of the object are not copied into the RAM allocated for the instantiated object. The actual functionality of the object remains in the ROM and is located in the active task list table 14b by pointer. The RAM allocated for object instantiation is used by the functionality of the object. It should also be appreciated that certain objects in the object library can be instantiated several times. In fact, each object has a functional name (it refers to the object in ROM).
), And an instantiated name, which refers to the instantiation of the object. The instantiated name is given as part of a high-level directive to the system object at the beginning of the instantiation. System object 22 also stores the instantiated name of the object in an active task list name table (ATLNT) 14c, which stores the name in the same index number as the pointer to ROM. And assigns a pointer to the allocated block of RAM to the active task list data space table (ATLDS).
T) 14d, whose active task list data space table 14d is also associated with the same index number.

Next, the system object 22 recalculates the scheduling of the objects in the active task list table 14b. In particular, every time object instantiation is completed at 228 in FIG. 4, all active tasks are stopped at 230 as shown in FIG. 4, and all instantiated objects are Called on the time layer. Each instantiated object has the worst case (
WC) Return time to system object and, using worst case time,
Compute the offset for each active task (each instantiated object contains at least one active task). System object 22 assigns an offset to each object instantiation, and the time layer stores each object instantiation at 234 in private data. The time between the worst case time and the actual time is advantageously used by system objects for system (background) functions, i.e., system functions are otherwise not scheduled and thus require no overhead. After this rescheduling is complete, the system object returns control to the timing kernel, which resumes scanning the active task list at 206.

After instantiation, pins can be assigned to the instantiated object by sending a command message (if necessary) directly to the instantiated object. The functionality of a particular object may include performing certain input or output tasks that require a physical connection to an external device such as a keyboard or display. However, some objects may have functionality that requires only communication with other objects and / or the script server (as described above), in which case the pin is Need not be assigned. To assign a pin to an instantiated object, messages to the instantiated object are addressed to the object's instantiated name. For example, as shown in FIG. 4, when an incoming message is detected at 208, input message processor 26 checks the syntax of the message, buffers the message, and examines the message and at 210 the message is Determine if it is for a system object. If the message is not for a system object, the message will be addressed to the named instantiation of the object. The input message processor
Active Task List Name Table (ATLNT) 14c at 236
Look up the named instantiation in to determine the index number of the instantiated object to which the directive was directed. If not shown in FIG. 4, but the name cannot be found in the active task list name table, an error
The message will be prepared and queued by the output registry. The input message processor also scans the active task list table (ATLT) 14b using the index number at 236 to find a pointer to the portion of the ROM that contains the layer of the object. The input message processor then sends the message and index number at 238 to the object's parser layer. The object's parser layer uses the index number to determine which instantiation of the object is being addressed and finds a pointer to the appropriate portion of RAM. The parser layer also interprets the message and determines at 240 whether the message is a configuration message, eg, to assign a pin or set a flow priority. If it is determined at 240 that the message is a configuration message, the configuration data is stored at 242 in an appropriate portion of RAM.

If the parser layer of the object determines at 240 that the message is not a configuration message, the message is processed at 244 by the functional layer of the object, and control returns to the timing kernel to scan the active task list. The functional layer of the instantiated object may also generate messages that need to be sent to another object or script server outside of the object-oriented processor array 10. The message from the cell instantiation is placed in the output message header portion of its RAM, and a request for registration is sent to the central output registry 34. The central output registry 34 maintains a queue of pointers to messages in the output message header portion. The queue is scanned by one or more output flow managers. As shown in FIG. 4, when the outgoing message is determined to be in the queue at 246, the output flow manager reads at 248 the highest priority pointer in the queue. The pointer points to the output message header (OMH) portion of the RAM used by the instantiation of the object that prepared the message. The output flow manager (OFM) uses the data there at 250 in FIG. 4 to prepare and send a message or, as described in more detail below with reference to the "event response" message protocol, " Send a data event.

As mentioned above, an object has sufficient hardware resources (pins and RAM).
) Can be instantiated several times as long as it is available to support another instantiation. The system object 22 places all object instances in the active task list table 14b, active task list name table 14c, and active task list data space table 14d by placing an entry in the table. The trajectory of transformation is maintained. In addition, the memory manager 38 maintains a pointer to the memory heap, which generates an error message when the memory heap is used and requested to allocate more RAM than is available. . Message flow priorities can be assigned if any required pins are assigned for object instantiation. Alternatively, the flow priority may be assigned before assigning the pins. According to the preferred embodiment, a flow priority of 0-7 may be assigned. Here, 0 represents the polled priority and 1-7 indicates increasing levels of importance. When the priority level is greater than zero, the output message from the instantiated object will be generated automatically.
The flow priority is stored in the outgoing message header portion of RAM by object instantiation.

System Objects As mentioned above, system objects automatically instantiate themselves when power is applied to an object-oriented processor array. The operation of the system object is shown in more detail in FIG. Referring now to FIG. 4a, when power is applied to the object-oriented processor array, the system object operates in a pre-allocated portion of the RAM for its use, as shown at 1200 in FIG. 4a. Stop. 1
After performing low-level diagnostics of the object-oriented processor array at 202, the system object starts the timing kernel at 1204. At this point, the host or boot ROM may send the global configuration to a system object, such as "Enable Exception Reporting", as shown at 1206. The system object then waits at 1208 for instructions from the host to instantiate the object. Upon receiving a command to instantiate the object, the system object checks hardware resources (eg, available memory) in the object-oriented processor array and instantiates this particular object at 1210. Determine if there are enough resources available to do so. It will be appreciated that the system objects need not be given knowledge of the hardware requirements of each object in the object library. If sufficient resources are available, the system object sends an error message at 1212 (if exceptions are enabled) and returns to 1208 to await instructions to instantiate the object. In a well-developed application, for example, if the commands to the system come from a programmed ROM, there are no errors, and when the object-oriented processor array is coupled to the host processor, as shown in FIG. It will be appreciated that error reporting is used during application development. If it is determined at 1210 that sufficient resources are available, the system object invokes at 1214 the instantiation layer of the given object. The instantiation layer is
Perform the tasks previously described at 218 to 226 with reference to FIG. 4 and perform the system object (S
Return the memory pointer to O), where the system object receives the pointer. The system object then writes to the active task list at 1218 as described above at 228 with reference to FIG. After writing to the active task list, the system object takes control from the timing kernel at 1220 and calls the timing layer of all instantiated objects at 1222. The timing layers report their worst case (WC) times at 1224, and system objects are added at 1226 to each instantiated object, as described in further detail below with reference to FIG. Calculate the offset value. These values are 234 with reference to FIG.
, As described above. The system object then returns control to the timing kernel at 1228 and
Return to 08 and wait for any further instructions to instantiate the object.

Memory Manager As described above, the memory manager uses the RA available during the instantiation process.
The trajectory of M is held. Specifically, as shown in FIG. 4b, after the system object is self-instantiated, the memory manager reads the total amount of memory in the object-oriented processor array at 2200 and is already occupied by the system object. Set the heap pointer to the next available portion of RAM beyond the portion being addressed. Then, the memory manager
At 2202, a request to allocate RAM is awaited. Memory manager is R
When a request to allocate an AM is received from the object's instantiation layer, the memory manager examines the request at 2204 and requests the requested R
Determine the amount of AM. The memory manager finds the amount of RAM currently available by subtracting the heap pointer from the total amount of memory at 2206.
The memory manager determines at 2208 whether the request for RAM can be fulfilled by comparing the requested amount to the available amount. If there is not enough RAM, the memory manager sends an error message at 2210 to the object instantiation layer. It will be appreciated that only error reporting is used as the application is being developed. Enough RA
If there is M, the memory manager allocates RAM at 2212 for the requesting object by giving the requesting object the current location of the heap pointer. The memory manager then determines RA at 2214.
Adjust the position of the heap pointer by moving the pointer to the start of the portion of RAM beyond the portion of RAM currently occupied by the object instantiated by adding the requested amount of M to the pointer I do. Then
The memory manager returns to 2202 to wait for another request for RAM.

Timing and Scheduling In accordance with one aspect of the present invention, when performing the scheduling of tasks as described above at 232 and 234 with reference to FIG. No operating time can be allocated, and the system object does not allocate any time for its own use. In particular, as shown in FIG.
0 (when initiated by a system object as described above at reference numeral 1204 with reference to FIG. 4a). 3 new objects
When instantiated at 202, the system object is
, Control is taken from the kernel at 3203 as described above at reference numeral 1220. The system object is identified by reference numeral 122 with reference to FIG.
Collect the worst case time from all instantiated objects at 3204 as described above at 2 and 1224. The system object then sums all the worst case times at 3206, and also adds the predefined time allotted for shell operations (ie, communication and message processing). These times are given by the system clock which depends on the clock frequency. The system object's pro-rates timer then interrupts at 3208 for each active object and shell. At 3210, the system object assigns a system clock time in the form of an offset, which offset is used by the timing kernel to assign time to each active object and shell. Each active object has 321
At 2, the assigned offset is stored in a portion of the assigned RAM. The system then returns control to the timing kernel at 3214. The timing kernel scans the active task list at 3216. For each object in the active task list,
The timing kernel allows the processor to devote a number of clock cycles to the object's task at the appropriate time based on the offset for that object as shown at 3218. However, an object may not need every clock cycle assigned to it. For example, if the object is an input processor coupled to a keyboard or encoder, and no input activity has occurred, the object will be idle. If an object in the active task list does not require any time, time is provided to the system object at 3220. When the system object is given time at 3220, it looks to see if there was a new object instantiated at 3202. If the new object was not instantiated, the system object looks at 3220 to see if there is a command to instantiate the new object. If there is a command to instantiate a new object, the system object calls the object's instantiation layer at 3224 as described above. If there are no instructions to instantiate at 3222, the timing kernel continues to scan the active task list (ATL) at 3216.

Initialization of the Alternative Embodiment The object-oriented processor array according to the present invention utilizes memory and instantiates objects in a slightly different manner, according to an alternative embodiment. In particular, as shown in FIG. 5, the memory 314 is arranged in a slightly different manner, ie, there is a reserved range 314e of memory in which the instantiated objects store pointers as described below. Providing this reserved range of memory eliminates the need for an active task list name table, or active task list data space table, and only the active task list 314b is needed. However, providing this reserved range may be a waste of memory that is never used.

Referring now to FIGS. 5 and 6, when the object-oriented processor array is powered on at 300 in FIG. 6, the system objects are:
At 302 in FIG. 6, itself as shown in FIG.
14a. During auto-instantiation, the system object also stores a portion 314 of RAM to maintain an active task list, a list of pointers to the objects, in the object library.
secure b. Thus, the object oriented processor array is ready to receive high level commands from the host or boot ROM.

An exemplary configuration command from the host to the object-oriented processor array according to this alternative embodiment takes the form {zF (ENC4)}. Where z is the address of the system object, F is the command to instantiate,
ENC4 is the name of the object in the object library, i.e., a 4-wide encoder. According to this alternative embodiment, the names (addresses) of the different objects are given functionally, for example LCDT (text LCD controller), ENC4 (4 wide encoder)
, KB44 (4 × 4 keypad controller) and the like. 304 in FIG.
In response to this command given at
At step 6, check the syntax of the directive and parse the directive for the system object. The system object sends a call to the instantiation layer of object "ENC4" at 308, telling object "ENC4" to instantiate itself. In response to a command from the system object, the instantiation layer of object "ENC4"
Check its predefined range 314e of reserved memory for the previous instantiation of "C4" and at 312 whether there is enough hardware resources available for one (other) instantiation To decide. According to this alternative embodiment, each object in the library is given a pre-coded address for a small block of RAM (portion 314e in FIG. 5), and that address therefore keeps track of the instantiation. Reserved for use. If it is determined at 312 that not enough resources are available, at 313 the error message received by the output registry is:
Sent to the host, which receives the error message at 316. If it is determined at 312 that sufficient resources exist for instantiation, then the instantiation layer of "ENC4"
Call the manager and request sufficient RAM allocation for its needs.
The memory manager maintains a pointer to the next byte of available memory in the "heap", as well as the address of the edge of the heap. In response to the "n bytes" request, the memory manager subtracts "n bytes" from the end of the heap address at 320 and compares the result with the heap pointer to determine if there is enough available Determine if RAM is present. If not enough RAM is available,
The error message is sent to the output registry at 322, which passes the message to the host. If it is determined at 320 that RAM is available, the memory manager moves the pointer to "ENC" at 324.
4 "and instantiate the heap pointer by n bytes. The instantiation layer of "ENC4" receives the pointer at 326 and writes the pointer at 328 to that block of reserved memory in 314e. As shown in FIG. 6, the pointer points to the start of memory block 314e. According to this alternative embodiment, the object "E
"NC4" allocates a portion of RAM space allocated to object "ENC4" for outgoing message headers and another portion of RAM allocated to object "ENC4" for "private data". When object "ENC4" is instantiated, the task dispatcher in the system object stores at 330 a pointer to object "ENC4" in the active task list (ATL). According to this alternative embodiment, the position in the active task list is used as the instantiation name of the object instantiation. For example, if the active task list has six entries (af), the first instantiated object will have the instantiation name "a", the second "b", the third "c". And so on. Further communication with the instantiation of the object will make use of this name.

After the object is instantiated as described above, pins can be assigned to the object by the host using a command language according to the present invention. For example, from host to object-oriented processor array
The command of aP (B)} is directed to the instantiated object with the name "a" and assigns a pin using command P, where parameter B is assigned to "a". Pin position. As shown in FIG. 6, such a command is issued at 332. Upon receiving such a message from the host, the input message processor checks the message at 334 for the correct syntax and will generate an error message to the host if the syntax is incorrect. Based on address "a", the input message processor looks for "a" in the active task list (ATL) at 336 and directs the message to object "ENC4". According to this alternative embodiment, "a" is the first pointer in the active task list, "b" is the second pointer, and so on. In accordance with the present case given herein, the pointer at "a" is the object "ENC
4 ", so the input message processor sends the message at 338 to the object" ENC4 ". Object "ENC4" receives the addressed message, and scans its reserved memory at 340 in FIG. 6 to find a pointer to its own named instantiated assigned workspace. Then, the pin number is 342
In the private data range of the instantiation "a", the object "ENC4
Is stored. Once the pin instantiates the object "ENC4"
Once assigned to "a", the instantiation works and the pin works with a default flow priority of zero.

Each time a new object is instantiated as described above, the timing of all tasks is recalculated. Thus, as shown in FIG. 6, the system object stops all tasks at 344 and calls the timing layer of all instantiations of the object. Instantiation is 346
Respond to the system object with the worst case (WC) time at and use the worst case time to calculate the offset for the next active task. Each instantiation of the object stores its offset at 348 in its assigned RAM private data range. The time between the worst case time and the actual time used by each object instantiation is used by the system object for background tasks. After the timing of all tasks has been recalculated, the system object returns at 350,
The active task list (AT) described in more detail below with reference to FIG.
L) is scanned. As shown in FIG. 6, the timing may be recalculated in response to a host command at 352 and a particular priority level may be assigned to a particular object instantiation. Priority scheduling may be performed by a scheduler, which may be considered as part of a system object or a separate entity.

Referring now to FIG. 7, the system object's task dispatcher starts at 400, scans the active task list, and 402
Check periodically to see if a new object instantiation has been added. In effect, schedulers set timers for tasks based on their priorities, and background tasks are completed when extra time is available. Thus, the order of the operations shown in FIG. 7 is not necessarily the order in which the operations are scheduled by the scheduler. If a new object instantiation is added, the above procedure (344-350 in FIG. 6) is performed at 404 in FIG. 7, and then the system object returns to scanning for active tasks. This involves monitoring the output message processor and the input message processor to determine whether the message needs to be derived. For example, at 406, it is determined whether the incoming message is pending (in the buffer of the input message processor). If so,
The input message processor determines at 408 the active task list (
ATL) to determine to which object the message was addressed and pass the message through the object. The object's parser layer examines, at 410, its pre-allocated reserved memory to determine which instantiation of itself should receive the message, and of the object for processing as an active task. Pass the message to the appropriate layer (functional, timing, or instantiation). The system object then checks at 412 if the output message is in the queue of the output registry. If the message is in the queue, the output message processor reads 414 the highest priority pointer in the output registry. A pointer in the queue points to the output message header of the object that originated the message. As mentioned earlier, the output message
The header includes a pointer to the output buffer in RAM, as well as an indication of the type of data to be sent, a flag indicating whether the output message header has been queued, and the like. At 416, the outgoing message former uses the outgoing message header (OMH) and data to generate a message for output on the network, which sends the message, and then clears the queue flag. An example of a message format according to this alternative embodiment is @ToArraytoobjMethod (data) FromObjfr
omarray $, where the fields are delimited by cases (
delimited). ToArray is the recipient's processor address, toobj is the recipient's object address, Method is a function, data is data, and the last field from the From is the sender's address. Show. If the address designation below From is blank, the host is the sender. Then the system object is 400
Resumes scanning the active task list at.

Central Script Server Referring now to FIG. 8, a preferred embodiment of the object-oriented processor array 10 is included on a single chip having a plurality of pins, eg, p0 to p39. Three pins, eg, p0, p1 and p2, are connected to network link 2
Preferably, it is reserved for a communication link with a host processor or script server 50 and an additional object-oriented processor array, e.g. And two pins, for example p38 and p39,
Preferably, it is secured for connection to the DC power supply 52. In accordance with the presently preferred embodiment, the three pins are shared by co-pending co-pending application no. 08 / 645,262 for implementing the communication network described therein. In addition, the above-mentioned application No. 08 / 645,262 is incorporated herein by reference. However, in some cases, the host 50 and each array 10, 1
0a-10c, for example, when the arrays are physically displaced from each other by a substantial distance, when the arrays are operating at substantially different speeds, or when only one array is present. Is used, separate point-to-point
Providing a link may be advantageous. In these situations, only two pins are needed to support the link and the shared co-pending application no. The point-to-point communication method disclosed in 08 / 545,881 may be used. In addition, the above-mentioned application No. 08/545,
881 is incorporated herein by reference. Also, a script server is coupled to other conventional microprocessors and / or peripherals, and the conventional microprocessor
It should be noted that a system can be created that includes both distributed object oriented processing with the system.

In accordance with the present invention, host processor 50 is used to construct object-oriented processor arrays 10, 10a-10c utilizing a high-level command language, and also during normal operation with object-oriented processor arrays. It is preferably used for communication. According to one embodiment of the invention, the host processor operates as a central script server, and all messages generated by the object-oriented processor array are sent to the script server for processing. Specifically, when an instantiated object in one of the object-oriented processor arrays 10, 10a-10c has data to send to another object, that data is first sent to the script server 50,
Then, the program executed on the script server determines a data destination. A program on the script server may also manipulate the data before sending it on another object. In accordance with the present invention, communication between the object-oriented processor arrays 10, 10a-10c and the script server is managed according to an "event response" model.

Event Response Model When several object-oriented processor arrays are combined into a single script server, the script server is responsible for many concurrent interactions with its several object-oriented processor arrays. You may be required to participate. Each concurrent interaction requires a separate thread in the script server. However, the event-response model requires developers to use complex multi-threaded scripts
Frees up the task of writing server code. In addition, objects in the object-oriented processor array coupled to the input device generate data events at a faster rate than the script server can process (or want to process) them. Can be. For example, the rotation of the rotary encoder is
A data event may occur each time the encoder is advanced by one detent. This results in a significant amount of redundant computation and communication. The event response model solves the above problem by allowing a script server to control when data is sent to that script server. According to the event response model of the present invention, when the object-oriented processor array 10 has a message to send, the object-oriented processor array 10 generates a data event. The data event is registered with the script server 50 and with the output message processor of each object-oriented processor array 10, 10a-10c coupled to the script server 50 via a bus 51. . Script server 50 provides a variable amount of I / O between the object and the script server before sending an acknowledgment of the data event on bus 25.
React to data events by enabling O-exchange. According to one mode of operation, until a data event is acknowledged, another data event is:
It is not sent to the script server 50 from any object on any of the object oriented processor arrays 10, 10a-10c. According to another mode of operation, a fixed number of data events may be pending at the same time. The number of data events that can be pending at the same time is determined by the script server 50, and each object-oriented processor array has its outgoing message processor, when they are initialized by the script server, It is configured to know the number of pending events allowed at one time. The output message processor in each object-oriented processor array maintains a counter of pending data events. When a data event occurs, the counter is incremented,
And when the data event is acknowledged, the counter is decremented. One skilled in the art will recognize that the number of pending data events allowed will determine the number of threads required to execute on the script server.

When multiple object-oriented processor arrays are coupled via a bus to a central script server, each object-oriented processor array knows the network traffic and has a specific target (script server) receiver. Is registered with all object-oriented processor arrays. The number of data events that can be pending at any given time is
Determined by the above goals and known to each object-oriented processor array. The goal arbitrates message flow based on the registration of data events. The arbitration may be FIFO based, or the targeted receiver may have a higher priority on flow events (if the number of pending data events allowed is greater than 1) for subsequently generated data events. May be allowed. As mentioned above, the output message buffer of the instantiated object is provided for message flow priority. The event response model is based on script server code
Allows to be linear in the number of threads in the script server code depending on the number of pending data events allowed.

When multiple object-oriented processor arrays are coupled to the script server by individual links, rather than by a common bus, the script server will assign each object according to the message flow priority of the cells in the object-oriented processor array. Communicate with a directional processor array. The number of threads in the code on the hub depends on the total number of pending data events allowed in each object-oriented processor array.

Example Event Response Model (where the maximum number of pending data events is 1)
Are described below with reference to Table 1.

[0061]

[Table 1]

As shown in Table 1, an object having data to send to the script server at t 1 sends [dataEvent] to the script server,
And all other objects that can send messages to the script server must stop sending data events at that point. When the script server is ready to receive data from the object that sent the data event at t1, the script server returns $ cmdEve at t2.
issue nt. The addressed object responds at t3 with a $ cmdAck that also contains some of the data it has to send. The script server then requests at t4 that the object sends the rest of its data. The object sends the rest of the data at t5, and the script server acknowledges that all data was received at t5 + n by sending [dataAck]. All objects are now free to send data events at t5 + m as shown in Table 1. The number of polled data packets between the data event at t1 and the data acknowledgment at t5 + n depends on the timing of the system, other tasks being processed by the script server, and the data that the object needs to send. It is variable depending on the quantity. The system may also include a timer, which causes a retransmission of the original data event if the server does not respond within a certain period of time, and / or that the event generator is re-enabled. Clear any pending events so that you can.

Another example of an event response model (where the maximum number of pending data events is 2) is described below with reference to Table 2.

[0064]

[Table 2]

As shown in Table 2, the first data generator sends a data event at t1, and the second data generator sends a data event at t2. [D
At the same time as dataEvent2, all data generators are prohibited from sending data events until a [dataAck] is generated. The server polls the first data generator for data at t3, and the first data generator acknowledges the server at t4 and sends the data. All data has been sent (it can require some $ cmdEvents and $ cmdAck).
At that time, complete reception of the data is acknowledged at t5. All data generators are now free to send data events. At t6, the server starts polling the second data generator. As seen in Table 2, before the second data generator responds, the first (or another) data generator sends another data event at t7. Again, with two pending events, all data generators are barred from sending additional data events. The second data generator sends its data at t8 and its complete reception is acknowledged at t9. Now that a single data event is pending in the script server, all data generators are then free to send data events.

This example assumes that the first and second data generators have equal priority. However, if the second data generator had a higher priority than the first data generator, the server would have polled it first. Optionally, the server may implement a time division multiplexing scheme to allow both data generators to send data simultaneously. That data generators that are forbidden to send data are still allowed to perform local operations, and that these data generators are provided with buffers and servers It will be appreciated that the locally generated data may be stored until the data is allowed to be sent.

A preferred embodiment of a messaging language that supports high-level language event reactions has the following syntax: <array address | message type><object
ct name><method / data type>(<data len
gth><data>. . . <Data>). <> Indicates a byte, (
) Is a character and. . . Indicates that the number of data bytes can vary. array·
The address is 5 bits and for point-to-point communication,
The array address is set to zero. The message type is 3 bits, and currently 6 message types are defined. These are (1) exception, (
2) data acknowledgment, (3) data event, (4) command acknowledgment, (5) polled response, and (6) command event. Object names are 8 bits and are currently restricted to ASCII characters $ through Z. Method /
The data type field is 8 bits and is restricted to ASCII characters a to z. This field is interpreted as a method when the method type is a command event or command acknowledgment. There are currently five defined data types. That is, (z) a signed character, (y) a character without a sign, (x
) Signed integers, (w) unsigned integers, and (v) floating point numbers. The data length is 8 bits and does not include right and left parentheses or the data length itself. The acknowledgment of the command is mandatory, and the acknowledgment must echo the address field of the command.

Smart Phone Example Referring now to FIG. 9, an exemplary application of the object oriented processor array 10 is a "smart phone accessory". In this application, the object-oriented processor array 10 includes a speech recognition processor object 23a,
Voice Messaging Processor Object 23b, Caller ID Processor Object 23c, and DTMF Dialer (Auto Dialer) 23d
Is provided. Each of these processor objects is included in the object library 20 and is self-instantiated in response to a call from the system object 22, which in turn issues instructions to the boot ROM as described above. Receive from 51. The boot ROM also contains instructions to assign pins to objects 23a-23d. According to this application, the two pins assigned to the speech recognition processor object 23a are coupled to an external microphone 53, and the two pins assigned to the speech messaging processor object 23b are It is connected to the speaker 55. Further, the two pins assigned to the caller ID processor object 23c and the DTMF dialer 23d are RJ-11
Connected to plug and jack. Smart phone accessory applications are designed to respond to voice commands by dialing the telephone number associated with a particular recognized name. In addition, this application is also designed to answer incoming calls by announcing the name of the person's call. To accomplish these functions, script server 51 is provided with a script that is executed in response to a data event from either speech recognition processor object 23a or caller ID processor object 23c. . An example of a script that is executed in response to a data event from the speech recognition processor object 23a is shown in Table 3 below.

[0069]

[Table 3]

As shown in Table 3, when the voice recognition object registers a data event, the script server searches the database for the recognized name,
Find the name, in this case the phone number associated with "HOME".
The script server then sends a command to the DTMF dialer to dial the number associated with HOME in the database. In addition, the script server sends a command to the voice message object to send three messages, eg, "I am (I am ...)", "calling", "hom".
e (home, home) ". Another example of a script for this application is shown in Table 4 below.

[0071]

[Table 4]

As shown in Table 4, when the caller ID object registers a data event, the script server searches the database for the telephone number,
Determine the name of the caller. The script server may, for example, use “Jeff is
Construct a message to play "calling (Jeff is calling.)" and send the message to the speech recognition object.

Distributed (Local) Script Server In accordance with another embodiment seen in FIG. 10, one or more object-oriented processor arrays are provided with a local internal script server;
And no central script server or host processor is required. In this "distributed script" embodiment, the communication registers and queues data events and event script lookup tables;
Additional functionality to determine which events are associated with internal messages is provided according to the event response protocol by being provided to the output message processor. The input message processor is provided with additional functionality to queue and buffer messages destined for objects in the object-oriented processor array.

In particular, the object-oriented processor array 110 according to the present invention has many similar components to the object-oriented processor array 10 described above, wherein similar components are incremented by 100 Reference numbers. The object-oriented processor array 110 includes an object library 20, system objects 122, and a number of active objects 123a, 123b, etc. after initialization. Object-oriented processor arrays also
It has a communication receiver 124a and a communication transmitter 124b, both of which are coupled to an external bus or link 125 for coupling the object-oriented processor array 110 to another similar array. Messages bound to objects in the object-oriented processor array are routed by input router 126c, which receives messages from buffer 126b. Buffer 126b buffers messages received from global input parser 126a and internal message interface queue 130. Messages occurring outside the object-oriented processor array are transmitted to the communication receiver 1
24a and passed to a global input parser 126a. Messages originating in the object-oriented processor array are received by the internal message interface queue 130, which receives the message from the data event processor 135. Data event processor 135 also provides input to output queue 132 for transmission by communication transmitter 124b to objects external to the object-oriented processor array. The data event processor 135 receives inputs from the pending output event queue 133 and the event script 137 programmable table. As in the first embodiment, messages from objects in the object-oriented processor array are registered in the output registry 134.

According to this embodiment, the source address of the data event is read from the pending output event queue 133 by the data event processor 135 and the script associated with that address in the script table 137 is retrieved. Used to search. The script is executed by the data event processor 13
5 and usually results in the generation of a message. Messages generated by the script are addressed to objects in or outside the object-oriented processor array. In the former situation, the message is passed to an internal message interface queue. In the latter situation, the message is sent to the output queue 132. Thus, the data event processor and script table function as local script servers in an object-oriented processor array, and there is no need for a central script server. However, it should be noted that a central script server may be used with the object-oriented processor array 110. The message will be sent to the central script server when the script for the data event does not appear in the script table, or when the script associated with the data event causes the message to be sent to the central script server. .

This embodiment of the object-oriented processor array, like the first embodiment, can be embodied on a single chip using one or more microprocessors with associated RAM and ROM. When so embodied, the object-oriented processor array 110 also includes a memory manager 138 and a timing kernel 136. The script table can be stored in either RAM or ROM, and is initialized (programmed) at startup by either the boot ROM or the host processor.

[0077] As distinct embodied by a processor, objects as hardware processor described above, an object-oriented processor in the object-oriented processor array, hardware, software, or hardware and software set It can be embodied as a combination. Referring now to FIG. 11, the object-oriented processor array 510 is functionally similar to the object-oriented processor array 10 shown in FIG. In this embodiment, separate microprocessors 521, 522 and 523a-c are provided. Microprocessor 521 includes all I / Os for object-oriented processor array 510.
Used to handle O functions. Accordingly, microprocessor 521 includes the functionality of communication interface 524, input message processor 526, internal output flow manager 530, external output flow manager 532, and central output registry 534. Microprocessor 522 provides system object functionality, and microprocessors 523a-c include object library 520.
With a separate processor functionality for each instantiation of the object from. According to one embodiment, the library includes software for each object, and the object is instantiated by loading the software into one of the plurality of processors 523a.

Universal Layout of Object-Oriented Processor Array In this regard, the present invention is directed to a microprocessor-based embodiment that includes system objects implemented in software, as described above. Although described primarily with reference to embodiments, the present invention can be implemented in numerous ways, including but not limited to a programmed microprocessor, a field programmable gate array, a custom LSI, and the like. The general concept of the present invention that takes into account multiple implementations is schematically illustrated in FIG. 12, where the object-oriented processor array 10 includes a pin 1000a, a bit and format processing ring 1000b, an elastic memory ring 1000c, and mathematical and Logical processing core 1
000d. Pin 1000a is the object-oriented processor array 1
Zero is the actual physical link to the surrounding real world. As described in more detail below, the bit and format processing ring 1000b, the elastic memory ring 1000c, and the math and logic processing core 1000d execute the object,
Most objects use bit and format operations, memory and math and logic operations, and some objects use memory bit and format operations or only memory math and logic operations I do.

The bit and format processing ring 1000 b performs the function of turning a very different collection of real interfaces into a canonical structure. The “standard structure”
It is determined by what best fits the need for high speed, low level control of the math and logic processing core 1000d and external devices. Typical functions performed in the bit and format processing ring 1000b include serial I / O, parallel I / O
O, specific low-level control of the analog-to-digital converter, and other processing of signals with high analog content. The implementation of the bit and format processing layers is highly variable. For example, a standard microcontroller port can be mapped into its functionality, although it consumes significant computing resources. Alternatively, field programmable gate array (FPGA) technology is well suited to perform these functions, although the use of FPGA technology is expensive in terms of circuit board area and cost. Many other implementations are possible. In particular, the bit processing portion of the bit and format processing ring can be conceptually viewed as a system that treats input pins as vectors sampled at a high frequency. The operation of sampling makes it possible to think of bit processing as a procedural algorithm that includes an operation that enables the detection of a change in state to be determined very efficiently. Similarly, the formatting portion of the bit and formatting process can conceptually be viewed as a procedural algorithm for reformatting data for delivery to an associated memory structure 1000c.

The elastic memory ring 1000 c can be implemented in a wide variety of ways. The implementation may include one or more buffers, FIFOs, LIFOs or stacks, circular buffers, mailboxes, RAM, ROM, etc. The elastic memory ring 1000c may include logic for calculations such as pointer position. Alternatively, this logic can be implemented on one side with a bit and format processing ring 1000.
b, on the other side, can be incorporated into the functionality of the math and logic processing core 1000d. If the code is stored for instantiation of an object, elastic memory ring 1000c contains that code.

The math and logical processor core 1000 d may include one or more standard processor cores (eg, Intel®) that process and convert I / O data to whatever external devices or applications require. x86, Motorola (registered trademark) 68xxx, Intel (registered trademark) 8051, PowerPC (registered trademark)
Or Analog Devices 21xx DSP). In other words, the mathematical and logical processing parts include the functional layers of the various processor objects. As with the elastic memory ring and the bit and format processing rings, the math and logical processor core 1000d is highly application dependent.

As suggested above, typically, the instantiated objects of an object-oriented processor array include one or more pins 1000a, a bit and format processing ring 1000b, an elastic memory ring 1000c, and a math And the logic processing core 1000d. For example, the voice recognition and voice message objects described above with reference to FIG. 9 typically utilize each of the above rings and two pins each. However, certain objects that are internal objects (eg, internal database objects) need not utilize the bit and format ring 1000b or pin 1000a. Similarly, other objects, such as an encoder object that receives input from a rotary encoder, buffers the input, and sends the input to a script server, do not require math and logic processing. These objects are pin 1
000a, a bit and format processing ring 1000b and an elastic memory ring 1000c.

Several embodiments of an object-oriented processor array have been described and illustrated herein. Although specific embodiments of the present invention have been described, the present invention is not intended to be limited thereto, as this invention is as broad as the technology allows and the specification is intended to be equally readable. Thus, while a particular microprocessor has been disclosed with reference to the preferred embodiment, it will be appreciated that other off-the-shelf or custom microprocessors can be utilized. Also, although particular software has been shown, it will be appreciated that other software code can be used to achieve similar results.

[Brief description of the drawings]

FIG. 1 is a schematic block diagram of the main hardware elements of an object-oriented processor array according to the present invention.

FIG. 2 is a schematic block diagram of the main functional elements of an object-oriented processor array according to the present invention.

FIG. 3 is a schematic memory map of a writable memory range in the object-oriented processor array of FIGS. 1 and 2;

FIG. 4 is a flowchart illustrating the basic steps in the initialization, setup and operation of the object-oriented processor array of FIGS. 1 and 2, and FIG. 4a is the basic function and operation of a system object. 4b is a flowchart illustrating the basic functions and operations of the memory manager, and FIG. 4c is a flowchart illustrating the basic functions and operations of the timing kernel, the active object and the system object regarding scheduling. FIG.

FIG. 5 is a schematic memory map of a writable memory range in an alternative embodiment of the object-oriented processor array.

FIG. 6 is a simplified flowchart illustrating steps in setup programming of an alternative embodiment.

FIG. 7 is a simplified flowchart illustrating an operation mode of an alternative embodiment.

FIG. 8 is a schematic block diagram of the object oriented processor array of the present invention coupled to a host processor and a power supply.

FIG. 9 is a schematic block diagram of an implementation of an object-oriented processor array for controlling a “smart phone”.

FIG. 10 is a schematic block diagram of the main functional elements of an object-oriented processor array according to a second embodiment of the present invention.

FIG. 11 is a schematic block diagram of an object-oriented processor array according to the present invention utilizing multiple microprocessors.

FIG. 12 is a schematic diagram generally illustrating the implementation of an object-oriented processor array on any hardware device (s).

[Procedure amendment]

[Submission date] March 7, 2001 (2001.3.7)

[Procedure amendment 1]

[Document name to be amended] Drawing

[Correction target item name] All figures

[Correction method] Change

[Contents of correction]

FIG.

FIG. 2

FIG. 3

FIG. 4

FIG. 5

FIG. 6

FIG. 7

FIG. 8

FIG. 9

FIG. 10

FIG. 11

FIG.

──────────────────────────────────────────────────続 き Continued on the front page (31) Priority claim number 09 / 003,993 (32) Priority date January 7, 1998 (1.7.1998) (33) Priority claim country United States (US) ( 81) Designated countries EP (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, IT, LU, MC, NL, PT, SE), OA (BF, BJ, CF, CG, CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG), AP (GH, GM, KE, LS, MW, SD, SZ, UG, ZW), EA (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), AL, AM, AT, AU, AZ, BA, BB, BG, BR, BY, CA, CH, CN, CU, CZ, DE, K, EE, ES, FI, GB, GE, GH, GM, HU, ID, IL, IS, JP, KE, KG, KP, KR, KZ, LC, LK, LR, LS, LT, LU, LV, MD, MG, MK, MN, MW, MX, NO, NZ, PL, PT, RO, RU, SD, SE, SG, SI, SK, SL, TJ, TM, TR, TT, UA, UG, UG , VN, YU, ZW. One script server may serve several object-oriented processor arrays to service, or an object-oriented processor array may have a local script server. A method and apparatus for scheduling when several virtual processors are embodied within the operation of a single microprocessor is also disclosed. According to the present invention, communication is based on an "event response" model, in which when a processor object has a message to send, the "event response" model is a data register registered by the target recipient (usually the host) of the message. Raise an event. The target responds to the data event by allowing a variable amount of I / O exchange between the processor object and the target before acknowledging the event. In one embodiment, no other data event is sent to the target until the data event is acknowledged. In another embodiment, a fixed number of data events may be pending at the same time.

Claims (45)

[Claims] 1. An object-oriented processor array configurable via a message-based communication link, comprising: a) processor means for executing a plurality of virtual processors; b) writable memory coupled to said processor means; c) a readable memory coupled to said processor means, comprising:
A readable memory comprising objects and a library of functional processor objects, each functional processor object having predefined functionality; d) transferring at least one of said functional processor objects to an external device. A plurality of physical pins for coupling; and e) communication interface means for coupling the object-oriented processor array to the message-based communication link, wherein the system object comprises a first functional library in the library. Calling the processor object and instructing the first functional processor object to instantiate itself as a virtual processor in the writable memory, thereby enabling the object-oriented communication via the message-based communication link. In response to the first configuration message sent to the processor array, said first functional processor objects, object oriented processor array that is coupled to at least one of said plurality of physical pins. 2. The system object of claim 1, wherein the system object is automatically instantiated when power is applied to the object-oriented processor array.
An object-oriented processor array as described. 3. The first functional processor object has a predefined functionality that is configurable, and the first functional processor object configures the predefined functionality. 2. The object-oriented processor array of claim 1, wherein the object-oriented processor array responds to a second configuration message sent to the object-oriented processor array via the message-based communication link. 4. The system object according to claim 2, wherein said system object is a second object in said library.
Via the message-based communication link by invoking the second functional processor object to call and instantiate itself as a virtual processor in the writable memory. The object-oriented processor array of claim 1 responsive to a second configuration message sent to the object-oriented processor array. 5. The second functional processor object has a predefined functionality that is configurable, and the second functional processor object configures the predefined functionality. 5. The object-oriented processor array of claim 4, wherein the response comprises responding to a third configuration message sent to the object-oriented processor array via the message-based communication link. 6. The system further comprising: f) active task list means for listing instantiated virtual processors, wherein the system object includes the first functional object as an instantiated virtual processor. The object-oriented processor array of claim 1 responsive to said first functional processor object instantiating itself by listing in a task list means. 7. The communication interface means, the active task list means, the system object and the instantiated first.
Further comprising input message processing means coupled to the functional processor object of the system object, wherein the input message processing means receives messages received by the object-oriented processor array via the message-based communication list. 7. An object-oriented processor array according to claim 6, wherein said array is directed to one of said functional processor objects. 8. The system further comprising: f) a memory manager coupled to the writable memory and responsive to calls from each of the functional objects, wherein the system object calls one of the functional processor objects. Then, when instantiating itself in writable memory, the functional processor object called by the system object calls the memory manager, and the memory manager stores a pointer to a starting address in the memory object. Finding in writable memory and providing the pointer to the functional object called by the system object, and the functional object called by the system object pre-allocates the pointer to it Object-oriented processor array of claim 1, wherein storing a portion of the writable memory that is. 9. The system further comprising: f) a memory manager coupled to the writable memory and responsive to calls from each of the functional objects, wherein the system object is a first one of the functional processor objects.
And instantiating itself in the writable memory using a first instantiation name; the first one of the functional processor objects calls the memory manager; The manager finds a first pointer to a portion of the writable memory and stores the first pointer in the first of the functional processor object;
The first of the functional processor objects provides the first pointer to the system object, the system object having the first pointer with a first index. Storing the first index in the name table with the instantiation name, and storing the first index with the functional name of the first one of the functional objects. The object-oriented processor array according to claim 1, wherein the object-oriented processor array is stored in a task list table. 10. The system object by invoking additional functional objects in the library and directing the additional functional objects to instantiate themselves as virtual processors in the writable memory. Responsive to an additional configuration message sent to the object-oriented processor array via the message-based communication link, wherein each of the first functional object and the additional functional object comprises:
Means for calculating a worst case time required to perform the function, wherein upon instantiation of each functional object, the system object collects a worst case time for each instantiated functional object. 2. The object-oriented processor array of claim 1, wherein the processor time schedules processor time for each instantiated functional object. 11. The object-oriented processor array of claim 10, wherein said system objects utilize processor time not used by instantiated functional objects to complete functions in less than worst case time. 12. The system object of claim 1, wherein the system object schedules processor time for each instantiated functional object by assigning an offset to each instantiated functional object.
0. An object-oriented processor array according to claim 0. 13. An object-oriented processor array configurable via a message-based communication link, comprising: a) a plurality of processor means, each processor means executing a functional processor; b) a plurality of processor means; A writable memory coupled to each; and c) a readable memory coupled to each of the plurality of processor means, the library comprising a system object and a library of functional processor objects. The object has predefined functionality,
Readable memory; and d) communication interface means for coupling the object-oriented processor array to the message-based communication link, wherein the system object is a first functional processor object in the library. Via a message-based communication link by invoking the first functional processor object to call itself and instantiate itself with one of the plurality of processor means in the writable memory. An object-oriented processor array responsive to a first configuration message sent to the object-oriented processor array. 14. The object-oriented processor array of claim 13, wherein said writable memory includes a separate writable memory coupled to each of said plurality of processor means. 15. The object-oriented processor array of claim 13, wherein said writable memory includes a shared writable memory coupled to each of said plurality of processor means. 16. An object-oriented processor array configurable via a message-based communication link for use with at least one external device, comprising: a) coupling the object-oriented processor array to the message-based communication link. Communication interface means; b) a plurality of functional objects, each functional object having a predefined functionality; c) a plurality of physical pins coupling at least one of said functional objects to said external device; An object-oriented processor selectively coupled to the at least one of the functional objects in response to a message being sent to the object-oriented processor array via the message-based communication link. array. 17. An object-oriented processor array configurable via a message-based communication link, comprising: a) a processor; b) writable memory coupled to the processor; c) a read coupled to the processor. A readable memory, comprising a system object and a library of functional processor objects, each functional processor object having predefined functionality; d) the functional processor object. And e) a communication interface coupling the object-oriented processor array to the message-based communication link, the system object comprising: The first functional in The object-oriented processor via the message-based communication link by invoking a processor object and instructing the first functional processor object to instantiate itself as a virtual processor in the writable memory An object-oriented processor array responsive to a first configuration message sent to the array, wherein the first functional processor object is coupled to at least one of the plurality of physical pins; 18. The system of claim 18 further comprising: f) an active task list listing instantiated virtual processors, wherein the system object includes the first functional object as the instantiated virtual processor. The first functional processor instantiating itself by listing in a list
The object-oriented processor array of claim 17 responsive to an object. G) the communication interface, the active task
Further comprising an input message processor coupled to the list, the system object and the instantiated first functional processor object, wherein the input message processor receives a message received by the object-oriented processor array 20. The object-oriented processor array of claim 18, wherein a message is directed to one of the system object and the functional processor object via the message-based communication list. 20. The system object by invoking additional functional objects in the library and instructing the additional functional objects to instantiate themselves as virtual processors in the writable memory. Responsive to an additional configuration message sent to the object-oriented processor array via the message-based communication link, wherein each of the first functional object and the additional functional object comprises:
A worst case time calculator that calculates the worst case time required to perform the function, wherein upon instantiation of each functional object, the system object generates the worst case time for each instantiated functional object. The object-oriented processor array of claim 17, wherein case time is collected and processor time is scheduled for each instantiated functional object. 21. A method for arbitrating communication between a plurality of message sources and a message target, comprising: a) establishing a maximum number of allowed pending messages; b) the maximum number for each of the sources. C) each source monitoring communications with the target to determine the current number of pending messages; and d) if the current number is not less than the maximum, the source sends a message to the target. Not sending; e) each source initiating a message to the target by sending a request to the target; f) the current number is incremented each time a request is sent to the target. G) responding to the request by the requesting source by instructing the requesting source to send a message. H) checking the receipt of each message sent to the goal by the previous goal; i) decrementing the current number each time the goal confirms receipt of the message. Method. 22. j) assigning a priority to at least a portion of said message source; k) signaling a priority assigned to said target; 1) said target is to send a message; 22. Responding to a plurality of pending requests by sources having different priorities by directing sources having higher priorities. 23. A system comprising: a) a host processor; and b) a plurality of object-oriented processors coupled to the host processor, at least some of the object-oriented processors generating data in response to events. And each of the object-oriented processors generating the data monitors request means for sending a request to the host processor, memory means for knowing a maximum allowable number of simultaneous pending requests, and communication with the host processor. Monitoring means for determining a current number of pending requests; i) each of the object-oriented processors generating the data sends a request to the host processor before data can be sent to the host processor. Ii) each of the object-oriented processors producing the data has a maximum allowed number of identical Iii) each of the object-oriented processors that generate the data monitor the communication with the host processor to determine the current number of pending messages; and iv) the object-oriented processor that generates the data. None of which sends a request to said host processor if the current number is not less than the maximum number. 24. Each of the object-oriented processors generating the data includes means for incrementing a current number; the host processor includes command means for commanding the object-oriented processor to send a message; 24. The object of claim 23, wherein a current number is incremented each time a request is sent to the host processor, and vi) the host processor responds to the request by instructing the requesting object-oriented processor to send a message. Oriented processor system. 25. The host processor further comprises: acknowledgment means for acknowledging receipt of a message sent to the host processor; and each of the data-oriented object-oriented processors comprises means for decrementing a current number. 26) viii) the host processor acknowledges receipt of each message sent to it; viii) the current number is decremented each time the host processor acknowledges receipt of a message. Object-oriented processor system. 26. The host processor includes priority memory means for associating at least a portion of the object-oriented processor generating the data with different priorities; ix) at least one of the object-oriented processors generating the data. Section has an assigned priority; x) said host processor is aware of said assigned priority; xi) said host processor is an object oriented processor which generates data having a higher priority. 26. The object oriented processor system of claim 25, wherein the system is responsive to a plurality of pending requests by an object oriented processor that generates data having different priorities by instructing the object to send a message. 27. A system comprising: a) a host processor; and b) a plurality of object-oriented processors coupled to the host processor, at least some of the object-oriented processors generating data in response to events. And each of the data-oriented object-oriented processors includes a request generator, a memory, and a communication monitor; and i) each of the data-generating object-oriented processors can send data to the host processor. Previously sending a request to said host processor via said request generator; ii) said memory of each of said object-oriented processors generating said data includes an indication of a maximum allowable number of concurrent pending requests; iii) Each of the object-oriented processors that generate the data is connected to the host Monitoring communication with the processor via the communication monitor to determine the current number of pending requests; and iv) if any of the object-oriented processors that generate the data determine that the current number is not less than the maximum number, An object-oriented processor system that does not send to the host processor. 28. Each of the object-oriented processors that generate the data includes a current number incrementer coupled to the memory and the communication monitor; the host processor includes a command message generator; Each of the current number incrementers increments the current number each time the communications monitor indicates that a request is being sent to the host processor; vi) the host processor generates a command message by generating the command message. 28. The object oriented processor system of claim 27, wherein the request is responsive to the request by sending the message to the requesting object oriented processor via a device. 29. The host processor includes an acknowledgment message generator, each of the object-oriented processors generating data includes a current decrementer coupled to the memory and the communication monitor, vii). The host processor acknowledges receipt of each message sent to the host processor by sending an acknowledgment message through the acknowledgment message generator; viii) each of the current number decrementers comprises 29. The object oriented processor system of claim 28, wherein a monitor decrements the current number each time the host processor acknowledges receipt of the message. 30. The host processor has a priority memory; ix) at least a portion of the object-oriented processor that generates the data has an assigned priority stored in the priority memory. X) the host processor instructs the object-oriented processor generating the data with higher priority to send a message to cause a plurality of pending requests by the object-oriented processor generating data having different priority. An object-oriented processor system according to claim 29, responsive to: 31. a) a plurality of object-oriented processors, each object-predefined processor having predefined functionality, and capable of generating at least one data event; A script server coupled to each one, the script server including a plurality of executable scripts, each script linked to an identification data event; and one of the object-oriented processors. The script server executes a script associated with the data event at the same time as the occurrence of the data event by the distributed processing system. 32. The distributed processing system according to claim 31, wherein said script server is a separate processor coupled to said plurality of object-oriented processors by said message-based communication link. 33. The distributed processing system according to claim 31, wherein at least two of said plurality of object-oriented processors execute as virtual processors in a single hardware microprocessor. 34. The distributed processing system of claim 32, wherein at least two of said plurality of object-oriented processors execute as virtual processors in a single hardware microprocessor. 35. The distributed processing system according to claim 33, wherein the script server is executed as a virtual processor in the single hardware microprocessor. 36. The distributed processing system according to claim 31, wherein said plurality of object-oriented processors are arranged in separate processor arrays. 37. The distributed processing system according to claim 36, wherein said script server comprises a plurality of script servers, each associated with one of said arrays. 38. The distributed processing system according to claim 37, wherein at least one of said arrays is a single hardware microprocessor. 39) a) each object-oriented processor has predefined functionality, and each object-oriented processor has at least one data processor;
A plurality of object-oriented processors capable of generating an event, each object-oriented processor having an address; and b) a script server coupled to each of the object-oriented processors, the plurality of executable scripts. Wherein each script comprises: a script server linked to one of the addresses; and upon the occurrence of a data event by one of the object-oriented processors, the script server A distributed processing system that executes a script associated with the address of the object-oriented processor that generated the event 40. The distributed processing system of claim 39, wherein at least one of the scripts, when executed, causes the script server to send a command to one of the object-oriented processors. 41. The distributed processing system of claim 39, wherein at least one of the scripts, when executed, causes the script server to send data to one of the object-oriented processors. 42. A method for processing data in a distributed processing system having a plurality of object-oriented processors, wherein at least one of the plurality of object-oriented processors is a processor that generates the data, comprising: Coupling to a plurality of object-oriented processors; b) providing to the script server at least one script including instructions for processing data generated by the at least one data-generating processor; c). Providing instructions to a processor that generates the data and sending the data to the script server for processing according to at least one script. 43. The processor for generating the at least one data is a processor for generating a first plurality of data, wherein the step of providing the script server with an instruction including at least one script includes the step of: Providing a first plurality of scripts corresponding in number to a plurality of data-generating processors, each script including instructions for processing data from a respective one of said data-generating processors. 43. The method of claim 42. 44. The method of claim 43, wherein at least one of said first plurality of scripts includes instructions for sending data to one of said object-oriented processors. 45. The method of claim 45, further comprising: d) coupling another processing system to the script server, wherein at least one of the first plurality of scripts includes instructions for sending data to another processing system. 43. The method of claim 43.