GB2227583A - Data processing system - Google Patents

Abstract

A data processing system is described in which a program is compiled as a collection of packets arranged in a directed graph structure. These include application packets which represent the application of a function to one or more arguments. The case where the function to be applied is unknown at compilation time is handled by using special incomplete packet types IPAP, IXAP and BILD. These are processed so as to assemble a complete packet, containing a direct reference to a function and containing all the required arguments for that function. <IMAGE>

Description

DATA PROCESSING SYSTEM.

Background to the invention This invention relates to data processing systems.

"Flagship Computational Models and Machine Architecture", I. Watson, J. Sargeant, P. Watson and V.

Woods, ICL Technical Journal Vol 5, Issue 3, May 1987, published by the Oxford University Press, England, describes a data processing system for executing programs written in a high-level declarative language.

In this system, declarative language programs are compiled into a collection of packets, including application packets and code packets. An application packet comprises a function item, specifying a function to be performed, and one or more argument items, specifying the arguments to which the function is to be applied. The function item may be a pointer to a code packet containing instructions defining the function. An argument item may be a data value, or may be a pointer to another packet.

A problem that arises in a system of this kind is how to handle the case where the function to be applied is unknown at the time the application packet is created. The object of the invention is to provide a way of dealing with this case.

Summary of the Invention.

According to the invention there is provided data processing apparatus comprising a memory holding packets arranged in a directed graph structure, the packets including application packets each of which comprises a function item and one or more argument items, wherein each function item either specifies a function directly or else is a pointer that specifies a function indirectly by way of one or more other application packets in the graph structure, the apparatus also including processing means for processing the packets, wherein an application packet whose function item does not directly specify a function is processed by:: (a) tracing a path through the graph structure from that application packet to an application packet whose function item directly specifies a function, and (b) retracing the path through the graph structure, incorporating the items of each packet in the path into its parent packet in the graph structure.

It can be seen that the invention allows an application packet to be created which does not directly specify the function to be performed. Such a packet can be used when the function is not known at the time the packet is created. When the packet is processed, it will be re-written so as to form a packet which directly specifies the required function, and this can then be processed in the normal way by applying the function to its arguments.

One data processing system in accordance with the invention will now be described by way of example.

Brief description of the drawings.

Figure 1 is an overall view of a data processing system, comprising a number of processing nodes.

Figure 2 is a block diagram showing one of the nodes, including an active packet scheduler and a packet processing unit.

Figure 3 is a flow chart showing the operation of the active packet scheduler.

Figure 4 shows the formats of packets.

Figure 5 shows the overall operation of each node.

Figures 6-8 respectively show the processing of PAPP, XAPP, IPAP and BILD packets.

Figure 9 shows an example of the operation of the system.

Description of an embodiment of the invention Referring to Figure 1, the data processing system comprises a plurality of processing nodes 10.

Each node comprises a processor 11 and a local store 12.

The workload of the system is divided into units referred to as packets, which will be described in detail below. A packet can reside in any of the local stores 12. Conceptually, all the local stores form a single packet memory for the system, and each packet has a 32-bit address indicating its location within this packet memory. Bits 31-24 of this address indicate which of the individual local stores the packet is resident in while the bits 23-0 indicate the address of the packet within that store.

Each processor 11 accesses active packets held in its own local store 12 and processes them according to the type of packet, as will be described. The processing nodes operate simultaneously , in parallel, resulting in a high overall rate of processing, proportional to the number of processing nodes in the system.

The processing nodes are interconnected by an inter-processor network 13, which allows any processor to send a message to any other one of the processors.

The network 13 may, for example, be a delta network.

If required, a processing node can read a packet from its own local store and export it over the network 13 to another node, so that it will now reside in the local store of that other node. For example, when a processing node detects that it is becoming overloaded, it may export packets to other nodes so as to even out the workload between the nodes. The processing nodes can also send messages to each other over the network, as will be described.

Referring now to Figure 2, this shows one of the processing nodes in greater detail.

The local store 12 within the node comprises a main store 20, a cache store 21, and a store access manager 22. The main store is a random access memory which holds all the packets resident in this node. The cache store is a smaller, faster, associatively address memory, which holds copies of data from the main store currently in use. The store access manager controls access to the cache and main store, and controls the copying of data from the main store into the cache.

The node also includes an active packet queue (APQ) 23. This is a first-in-first-out memory, and is used to hold the addresses of active packets in the local store 12, i.e. packets which are waiting to be executed in this node. Overflow from the APQ is held in a holding stack (HS) 24, which is organised as a last-in-first-out memory. The APQ and HS are controlled by an active packet scheduler (APS) 25 as will be described.

The APS passes packet addresses to a packet processing unit (PPU) 26, which accesses the packets from the local store 12 and processes them. This processing generally involves re-writing the packet and changing its type and state. The processing may also involve re-writing or changing the state of other packets, the creation of new packets, or the deletion of existing packets.

The processing node also includes a free packet address store (FPA) 27, which holds addresses of free packet locations in the local store 12. Whenever the PPU deletes a packet, it returns the address of the packet to the FPA. Conversely, when a new packet is created, a free packet address is removed from the FPA and the new packet is placed in this location.

The APS and PPU interface with the inter-processor network by way of a network interface (NIF) 28. This contains an input message queue for holding messages received from other processing nodes, and an output message queue for holding messages waiting to be transmitted to other processing nodes.

In operation the APS in each node generates a local activity level signal (LAL) indicating the current workload of this node, i.e. the number of active packets waiting to be executed. This signal is applied to the network 13 by way of the NIF. The network receives these signals from all the nodes, and generates a global activity level signal (GAL), which is returned to all the nodes.

Packet scheduling Referring now to Figure 3, this shows the operational algorithm of the active packet scheduler APS. This algorithm may be implemented either in hardware, microcode, software, or a mixture of these.

The exact nature of the implementation forms no part of the present invention and so will not be described in detail.

Whenever the APS receives a packet address, either from the associated PPU in the same node, or from another node via the NIF, it first checks whether the active packet queue APQ is full. If not, then the packet address is placed in the APQ. If, on the other hand, the APQ is full, the APS checks whether the local activity level LAL of this node is greater than the global activity level GAL. If so, the packet is read out of the local memory and exported over the network to one of the other nodes that has a lower activity level.

If the local activity level LAL is less than the global level GAL, then the packet is not exported.

Instead, its address is placed in the holding stack HS.

Whenever the APS receives a request for a packet from the associated PPU in the same node, it first checks whether the APQ is empty. If it is not empty, it removes a packet address from the APQ and returns it to the PPU. The APS then checks whether the HS is empty. If it is not empty, the APS removes the last address held in the HS and puts it into the APQ.

The packet format will now be described. Each packet consists of a header, followed by one or more packet items.

Packet header format The header includes the following fields: TYPE, PSTATE, ITEMCNT, SUSCNT, LOCCNT, STR, ARI and REFCNT.

The TYPE field indicates the packet type.

Possible packet types include the following: XAPP executable application PAPP processable application UNCO unevaluated constructor EACO, ENCO, evaluated constructors CODE code IPAP incomplete processable application IXAP incomplete executable application BILD build.

The PSTATE field indicates the state of the packet, as follows: ACT active DOR dormant SUS suspended REL relay The ITEMCNT field indicates the number of items in the packet.

The SUSCNT field indicates the number of items that must be evaluated or the number of items for which local copies are awaited, before a suspended packet can be activated.

The LOCCNT field indicates the number of items of the packet that must be local (i.e. in the local store of the processing node) before the packet can be executed.

The STR field indicates the number of strict arguments in the packet. A strict argument of a function is one which must be in evaluated form before the function can be executed.

The ARI field indicates the "arity" of the packet function i.e. the total number of arguments (strict or non-strict) required by the function.

The REFCNT field is a reference count which is used for garbage collection: any packet that has REFCNT equal to zero can be deleted and its address returned to the FPA.

The header also includes control bits MKLOC and EXPINH.

MKLOC indicates that one or more items (as specified by the LOCCNT field) must be made local before the packet can be executed.

EXPINH indicates that this packet is not to be exported to another processing node.

Packet item format The first byte in each packet item holds a two-bit type code ITYPE, and a six-bit qualifier QUAL.

ITYPE indicates the item type as follows: ITYPE item type 0 null 1 value 2 return address 3 pointer.

In the case of a value item (ITYPE=1), QUAL indicates the type of value represented by the item. For example, a value item may represent an integer, a real number, a character, a boolean value or a built-in function code. A built-in function code represents one of a set of functions that can be executed by a processing node, such as ADD, SUBTRACT, MULTIPLY, DIVIDE and so on.

A return address item (ITYPE=2) contains a return address RTN which is used, as will be described, as a pointer from the packet to a parent packet in a graph structure. It also contains an item number which indicates the particular item within the parent packet in which a result value is to be placed.

- A pointer item (ITYPE=3) contains a pointer PTR which points to an child packet in the graph structure.

It also contains a weight value GW which is used in a garbage collection scheme.

The QUAL field of this item includes an evaluated flag EVAL, indicating whether the child packet has been evaluated, and a pointer qualifier PQUAL which indicates the type of the child packet.

In the case of a CODE packet, the packet items do not have a normal item format described above.

Instead, the items contain a sequence of microcode instructions, for executing a user-defined function.

Packet formats Referring to Figure 4, this illustrates some possible packet layouts, and the way in which the packets can be organised in a directed graph structure by means of the pointer and return addresses.

A executable application packet XAPP comprises a header, followed by an item representing a function to be performed, followed by one or more items representing the arguments of that function (with the strict arguments first, followed by the non-strict arguments, if any), and finally a notification list, comprising one or more return address items. The item representing the function may either be a built-in function, or a pointer to a code packet representing a user-defined function.

For example, in Figure 4, the packet at address 40 is an XAPP packet having four items. The first item is a built-in function ADD. The next two items are literal integer values 4 and 5. The final item is a return address 10 indicating that the result of evaluating this packet is to be returned to the packet at address 10. It should be noted that both the arguments for the XAPP packet are in evaluated form, so that the packet can be evaluated as soon as it is activated.

Packets of type PAPP, IPAP, IXAP and BILD have similar layout to an XAPP packet, the difference being in the way in which the packets are processed, as will be described.

A PAPP packet is used when one or more of the arguments of the packet have not yet been evaluated, although they must be evaluated before the function application can be reduced. It is processed, as will be described, by activating the packets which are pointed to by the argument items of the PAPP packet.

IPAP packets are used to represent the application of a function which is unknown at the time the packets are compiled. For example, in Figure 4, the IPAP packet at address 10 represents the application of such a function. The packet points to another IPAP packet at address 20, which in turn points to a CODE packet at address 30. The code packet contains instructions for executing a user-defined function; in this example, this is a function "add 3" which adds together three integers. It should be noted that the IPAP packet at address 10 points indirectly to the CODE packet, by way of the intermediate IPAP packet. It should also be noted that the required three arguments for the "add 3" function are distributed between the two IPAP packets, rather than all being held in one packet.

An IXAP packet is used to represent the application of a function to fewer than the arity of its arguments.

BILD packets are used for assembling items from IXAP packets so as to build up a complete packet (XAPP) containing a direct pointer to a CODE packet and containing all the required arguments. However, if there are insufficient arguments an IXAP packet will be built.

Operation of processing node Referring to Figure 5, this shows the main operational loop performed by each of the processing nodes.

(5-1) The node processes any messages held in the input message queue of the network interface 28.

(5-2) The PPU then requests the active packet scheduler APS to send it a packet address from the APQ, and then uses the packet address to access the packet from the local store.

(5-3) The PPU examines the packet type field in the header of the packet, and branches according to whether the packet is a PAPP, XAPP IPAP, BILD, or some other type of packet.

(5-4) The packet is then processed according to its packet type. The processing of the different packet types is described in more detail below with reference to Figures 6-9.

(5-5) When all the packets in the APQ have been processed, the node deals with any messages in the output message queue, by sending them to their specified destinations.

PAPP packets The processing of a PAPP packet is shown in Figure 6.

(6-1) First, an ACTIVATE function is performed, in order to activate all the strict arguments of the packet. The ACTIVATE function examines all the packet items up to that indicated by the STR field of the packet header. If the item is an unevaluated pointer (ITYPE=3, EVAL = FALSE), the packet to which it points is activated. The SUSCNT field of the PAPP packet is set equal to the number of packets that are activated, and the packet is converted to an XAPP packet, with MKLOC set true.

If a packet to be activated is resident in the local packet store of the node, then it can be activated directly. If, on the other hand, the packet resides in a remote node, the ACTIVATE function creates a REMOTE FIRE message, and places it in the output message queue. This will then be transmitted to the remote node in which the packet resides, and will cause it to be activated in that node.

(6-2) The SUSCNT field of the packet is tested.

If SUSCNT is non-zero, the packet is suspended, since the packet is now waiting for results to be returned from other packets.

(6-4) If, on the other hand, SUSCNT is zero, then the packet is processed as an active XAPP packet, as described below.

XAPP packets.

XAPP packets are processed as shown in Figure 7.

(7-1) First, the MKLOC bit of the packet is checked.

(7-2) If MKLOC is true,then a COPY function is performed. The COPY function sends messages to remote nodes, requesting them to supply copies of argument packets which are required by the packet currently being processed. For each such message the SUSCNT field of the packet is incremented by one, so as to keep a record of the number of copies that the packet is awaiting. When the remote nodes receive the messages, they will return copies of the required argument packets. As each copy is received, the SUSCNT field of the requesting packet will be decremented.

(7-3) The SUSCNT field of the packet is now examined.

(7-4) If SUSCNT is non-zero, the EXPINH flag of the packet is set. This is to prevent the packet from being exported before the awaited argument packets are returned. The MKLOC bit is set false and the packet is suspended, awaiting the return of the requested argument packets. It will be activated again when SUSCNT reaches zero, indicating that all the arguments have been returned.

(7-5) If SUSCNT is zero at step (7-3), or if MKLOC is false at step (7-1), then the packet being processed must have all its argument packets, or copies of them, present in the local packet store. The packet can therefore be re-written in the manner specified by the first packet item (i.e. a built-in function, or a pointer to a CODE packet). The nature of the packet re-writing operation forms no part of the present invention and so will not be described in detail herein.

IPAP packets.

The way in which an IPAP packet is processed is as follows.

All the strict arguments of the packet are activated. The packet type is changed to BILD, with MKLOC set true and LOCNT set, so as to ensure that the code will be made local. The SUSCNT field is set equal to the number of activations, and the packet state is suspended. If on the other hand, no activations were necessary, the state of the BILD packet is set active.

BILD packets.

A BILD packet is processed as shown in Figure 8.

(8-1) First, a check is made to determine whether the first item of the BILD packet points to a CODE packet or an IXAP packet..

(8-2) If it points to a CODE packet, then the arity field (ARI) in the header of the code packet is compared with the number (NFA) of argument items in the BILD packet.

(8-3) If ARI=NFA, this means that there is exactly the right number of arguments in the BILD packet to allow execution of the function specified by the CODE packet. The BILD packet is therefore now processed in exactly the same way as a PAPP packet, except that the strictness (STR) and locality (LOCCNT) information are read from the header of the CODE packet, rather than from that of the BILD.

^ (8-4) If ARI is greater than NFA, this means that there are not enough arguments available for execution of the function. The packet being processed is therefore changed to an IXAP packet. The arity field in the header of the IXAP is set equal to ARI-NFA i.e. to the number of arguments still required.

(8-5) If ARI is less than NFA, this means that there are too many arguments in the BILD packet. In this case, the function is applied to the first ARI arguments, The result is then applied to the remaining NFA-ARI arguments.

(8-6) If it is found at step (8-1) that the first item of the BILD packet points to an IXAP packet, the action is as follows. First, the arity field (ARI) of the IXAP packet is compared with the number (NFA) of arguments in the BILD packet.

(8-7) If ARI = NFA, this means that there are exactly enough arguments in the BILD and IXAP packets to allow the function specified by the first item of the IXAP packet to be executed. The BILD packet is extended to hold the argument items from the IXAP packet, followed by its own argument items, and the first item of the BILD is overwritten by the first item of the IXAP packet (which points to a CODE packet). The BILD packet is made active.

(8-8) If ARI is greater than NFA, this means that there are not enough arguments to allow the function to be executed. The BILD packet i-s extended to hold the arguments of the IXAP followed by its own arguments, and its first item is overwritten with the first item (i.e. the CODE pointer) from the IXAP. The arity field is set equal to ARI-NFA i.e. to the number of arguments still required. The BILD packet is converted into an IXAP packet.

(8-9) If ARI is less than NFA, the action is the same as at step (8-5) above.

Example.

An example of the processing packets will now be described, with reference to Figures 4 and 9. In this example, an asterisk (*) is used to denote an active packet, while a hash symbol (t) is used to denote a suspended packet. Other packets are assumed to be dormant.

Figure 4 shows the initial states of the packets in this example. The IPAP packet at address 10 is active, while the other packets are all dormant.

When the active IPAP packet is processed, it is rewritten as a suspended BILD, while its child packet at 20 is activated, The states of the packets are now as shown in Figure 9(a).

The active IPAP at address 20 is now processed.

It is rewritten as an active BILD, since there were no packet activations necessary. The packet states are now as shown in Figure 9(b).

The active BILD is now processed. Since it points to a CODE packet, and the arity of the CODE packet (3) is greater than the number of arguments in the BILD (1), the BILD is rewritten as an IXAP packet.

The arity of the IXAP is set equal to the arity of the code packet minus the number of arguments, i.e. equal to 2. When this IXAP packet is processed it activates its parent BILD at address 10, and becomes dormant. The result is shown in Figure 9(c).

The active BILD at address 10 is now processed.

In this case, the number of arguments in the BILD is equal to the arity (2) of the IXAP packet to which it points. The BILD packet is therefore extended to hold the argument items of the IXAP packet, and its first item is replaced by the pointer to the CODE packet. The BILD packet remains active. The result is as shown in Figure 9(d).

The BILD packet is processed again. It now points directly to a CODE packet, and the number of arguments is equal to the arity of the CODE packet.

Hence the packet can now be processed in the same way as a PAPP packet. This involves activating the XAPP packet at address 40. When the XAPP is processed it evaluates its built in function to calculate the result 4 + 5 = 9.

This result is then returned to its parent packet at address 10, overwriting the pointer.

The BILD packet now contains a direct pointer to the code packet, and three evaluated arguments. It can therefore now be processed, to form the final result 7 + 8 + 9 = 24.

In summary, it can be seen that when the original IPAP packet at address 10 is processed, a path is traced through the graph structure for this IPAP to the CODE packet, by converting the intermediate packet in the path to a BILD. A path is then traced back from the CODE to the original packet, the items in the intermediate packet being incorporated into the parent packet. The effect is to construct a complete packet, with a direct pointer to the required CODE packet, and with the required number of argument items.

Claims (5)

CLAIMS.

1. Data processing apparatus comprising a memory holding packets arranged in a directed graph structure, the packets including application packets each of which comprises a function item and one or more argument items, wherein each function item either specifies a function directly or else is a pointer that specifies a function indirectly by way of one or more other application packets in the graph structure, the apparatus also including processing means for processing the packets, wherein an application packet whose function item does not directly specify a function is processed by:: (a) tracing a path through the graph structure from that application packet to an application packet whose function item directly specifies a function, and (b) retracing the path through the graph structure, incorporating the items of each packet in the path into its parent packet in the graph structure.

2. Apparatus according to claim 1 wherein each application packet has a type indentifier, indicating one of a plurality of different packet types, and wherein an application packet whose function item directly specifies a function, and which contains sufficient argument items for the function to be applied to, is created as a packet of a first type (PAPP, XAPP) whereas an application packet whose function item does not directly specify a function, or which does not contain sufficient argument items, is created as a packet of a second type (IPAP).

3. Apparatus according to claim 2 wherein said path through the graph structure is traced by converting each packet of said second type (IPAP) into a packet of a third type (BILD), and activating its child packet within the graph structure.

4. Apparatus according to any preceding claim wherein a function item directly specifies a function by pointing to a code packet containing instruction for executing that function.

5. Apparatus substantially as hereinbefore described with reference to the accompanying drawings.