Processing of data graphs for efficient interpretation

Abstract

Described is a data processing device (1400) for encoding a data graph (500, 700, 800) comprising multiple nodes for interpretation, the device comprising one or more processors (1401) configured to: form (1301) a node representation for each node (501, 502, 503, 504, 505, 701, 704, 802, 803, 804, 805) of the graph; store (1302) at least part of the node representation for each node of the graph as one or more integer values in an array (401, 600, 900, 1000); and perform (1303) an interpretation operation on the array. The encoding of data graphs as an array can advantageously allow for more efficient interpretation, shorter compilation workflow before efficient interpretation and efficient graph serialization into permanent storage.

Description

[0001] PROCESSING OF DATA GRAPHS FOR EFFICIENT INTERPRETATION

[0002] TECHNICAL FIELD

[0003] The present disclosure relates to a method of processing an intermediate representation of a data structure, such as an abstract syntax graph.

[0004] BACKGROUND

[0005] Compilation of computer code refers to the process of taking as input a program written in a high-level programming language and generating code in a lower level language. The ultimate goal is to produce code that can be executed, either in a native platform or by an interpreter. The whole compilation process, i.e. the process of producing code that can be evaluated, may be composed of multiple steps and thus can rely on intermediate languages representations before producing a final form that can be evaluated. Each of these intermediate representations may have a specific purpose: for instance, the Abstract Syntax Tree (AST) is normally generated by a parser and is normally seen as the first intermediate representation. Other intermediate representations can follow and these can be used to implement operations such as type-checking, static analysis and / or optimizations.

[0006] For efficient interpretation of programs, interpreters usually rely on the compilation of source code all the way to a dedicated bytecode representation. This is usually a compact representation with as little indirection as possible. Operators are preferably close to their operands in memory, thus allowing interpreters to benefit from caching mechanisms. More precisely, the bytecode in an efficient interpreter consists typically in low level operations to perform primitive operations and to manipulate the interpreter structures such as the stack, the registers, the environment and others.

[0007] Abstract Syntax Graphs (ASGs) are extensively used as intermediate representations in compiler construction. They provide an easy abstraction to implement compiler optimizations by graph rewriting and support code generation as the next compilation stage.

[0008] However, for this process to be efficient the graphs should be easy to modify, which implies that the implementation of these structures results in nodes of the graph being scattered all over the memory, and on pointers being used to represent the edges of the graph. Although this representation is ideal for graph rewriting, since it allows one to plug / unplug subgraphs on the fly without copying or moving memory around, it is not efficient for traversal, which is an important part of interpretation. The inefficiency is due to indirection, requiring pointer chasing, and the unavoidable cache misses induced by nodes being dispersed all over the memory. Thus, ASGs are not typically interpreted and instead they are compiled into lower-level intermediate representations if the purpose is evaluation of the program.

[0009] A typical compiler workflow is depicted in Fig. 1. Source code is parsed into an AST 101 where some transformations can be applied, and then the AST can be further compiled into one or more other intermediate representation. These intermediate representations are commonly graph based. Fig. 1 depicts a compilation workflow with an intermediate ASG representation 102, which is convenient for implementing compiler optimizations. However, due to the typical representation of ASGs in memory, it is inefficient to interpret them and thus they are instead generally compiled into a dedicated bytecode representation 103 if interpretation is the target of the compilation.

[0010] Generally, efficient interpreters rely on the compilation of programs into a dedicated bytecode representation (including those that are based on graph-based intermediate representation). This does not only require a longer compilation workflow (requiring more compilation steps) but also a new (bytecode) language with possibly a totally different semantics.

[0011] One of the most successful interpreters is the OCaml interpreter, as described in Yaron Minsky, Anil Madhavapeddy, Jason Hickey: “Real World OCaml - Functional Programming for the Masses (2nd ed.)”, O'Reilly 2013, Cambridge: Cambridge University Press, doi: 10.1017 / 9781009129220, https: / / dev.realworldocaml.org / compiler-backend.html and Xavier Leroy, “The ZINC experiment: an economical implementation of the ML language”, RT- 0117, INRIA. 1990, pp.100, https: / / xavierleroy.org / publi / ZINC.pdf. The slowdown of the interpreter with respect to compiled code is said to be between 2 and 15 times.

[0012] Nonetheless, the burden of the extra compilation step(s) together with having a dedicated bytecode language generally pays off in terms of interpreter performance. However, interpreting the typical ASG representations may be prohibited due to indirection, pointer chasing and the unavoidable cache misses induced by the fact that nodes are dispersed all over the memory.

[0013] It is desirable to develop a method that overcomes at least some of the above problems.

[0014] SUMMARY

[0015] According to a first aspect, there is provided a data processing device for encoding a data graph comprising multiple nodes for interpretation, the device comprising one or more processors configured to: form a node representation for each node of the graph; store at least part of the node representation for each node of the graph as one or more integer values in an array; and perform an interpretation operation on the array.

[0016] The encoding of a data graph as an integer array can advantageously allow for more efficient interpretation compared with regular ASG interpretation, shorter compilation workflow before efficient interpretation compared with state-of-the-art efficient interpreters, and the additional benefit of allowing efficient graph serialization into permanent storage.

[0017] One of the one or more integer values for each node of the graph may comprise an operation code. The operation codes for the nodes may be used in the interpretation operation. Storing each operation code as an integer in the array may allow the interpretation operation to be performed more efficiently.

[0018] The array may comprise one or more indices indicating a location in an additional array for one or more nodes of the graph. The array may comprise, for one or more nodes of the graph, a respective index indicating a respective location in the additional array. Each index may be an integer value. This may allow data corresponding to a node to be stored separately to the main array. This may be an efficient representation for interpretation.

[0019] The one or more processors may be configured to cause metadata for one or more of the nodes to be stored in the additional array. This can make the interpretation process more efficient by not storing the metadata in the main array, whilst at the same time keeping the metadata accessible for other processes in which it is used.

[0020] The interpretation operation may not use the metadata. As a result, the metadata can be stored in an additional array and the main array can instead include integer values that are respective indices indicating a location of the metadata for a node in the additional array. This can make the interpretation process more efficient.

[0021] The one or more processors may be configured to cause the additional array to be stored separately to the array. This can keep the metadata accessible for other processes in which it is used.

[0022] The one or more processors may be configured to cause the array to be stored at a contiguous block of memory. The memory may be a memory of the data processing device. The memory may be a memory of another device or a cloud device. This can improve the speed of the interpretation operation.

[0023] The array may further comprise additional information for one or more of the nodes. The additional information may comprise a number of arguments for a respective node. The additional information may comprise other information for the node. There may be n integers representing additional information, n may be inferred from the operation code of a respective node (i.e. for each operation code there is a fixed number n). In other words, for each operation code there may be a fixed number of cells in the array to capture additional information about that node.

[0024] The node representation may comprise the one or more integer values that are stored in the array. The node representation may comprise the metadata for a respective node (where present) that is to be stored in an additional array. The node representation may comprise the index indicating the location for the metadata for a respective node in the additional array. The node representation may comprise the additional information that is stored in the array for a respective node (where present). The data processing system may not need access to all of the data comprised in the node representation for the interpretation operation. The at least part of the node representation that is stored in the array may be the data that is used in the interpretation operation. Part of the node representation that is not used in the interpretation operation can be stored in one or more additional arrays. For some nodes of the graph, all of the node representations for those nodes may be stored in the array (for example, nodes without any metadata).

[0025] The one or more processors may be configured to form the node representation for each node by applying a first traversal algorithm to the graph and extracting data from each node of the graph. The processing device may be configured to traverse the graph to extract data for the array from each node. The node representation can be stored as one or more of: one or more integer values for each node, additional information in the array for some nodes and optionally the metadata array / further information from each node. This may allow data to be efficiently extracted from each node for encoding.

[0026] The one or more processors may be configured to perform the interpretation operation by applying a second traversal algorithm to the array to traverse the nodes in the same order in which the nodes of the graph were traversed using the first traversal algorithm. This may allow the interpretation operation to be performed efficiently.

[0027] The array may be a compacted representation of the graph. This may be more efficient for the interpretation of data contained in the graph.

[0028] The graph may be an intermediate representation of a data structure. The graph may comprise a plurality of nodes and a plurality of edges between nodes. The data structure may comprise an abstract syntax tree. The graph may be an abstract syntax graph. An abstract syntax graph is an intermediate representation of the compilation workflow that can be useful for a variety of tasks, such as compiler optimizations by graph rewriting and support code generation as the next compilation stage.

[0029] According to another aspect, there is provided a method for encoding a data graph comprising multiple nodes for interpretation, the method comprising: forming a node representation for each node of the graph; storing at least part of the node representation for each node of the graph as one or more integer values in an array; and performing an interpretation operation on the array.

[0030] This method of encoding of a data graph as an integer array can advantageously allow for more efficient interpretation compared with regular ASG interpretation, shorter compilation workflow before efficient interpretation compared with state-of-the-art efficient interpreters, and the additional benefit of allowing efficient graph serialization into permanent storage.

[0031] According to a further aspect there is provided a computer program which, when executed by a computer, causes the computer to perform the method described above. The computer program may be provided on a non-transitory computer readable storage medium.

[0032] BRIEF DESCRIPTION OF THE FIGURES

[0033] The present disclosure will now be described by way of example with reference to the accompanying drawings. In the drawings:

[0034] Fig. 1 schematically illustrates the workflow of a typical compiler.

[0035] Fig. 2 schematically illustrates an example of a node in a typical graph representation.

[0036] Fig. 3 schematically illustrates graph flattening to form a compressed representation and unflattening to revert to the original graph.

[0037] Fig. 4 schematically illustrates exemplary structures of a bytecode array and a metadata array.

[0038] Fig. 5 schematically illustrates a generic example of an abstract syntax graph.

[0039] Fig. 6 schematically illustrates bytecode encoding for the graph shown in Fig. 5.

[0040] Fig. 7 schematically illustrates an example of a graph for a generic conditional branch.

[0041] Fig. 8 schematically illustrates an example of a graph representing a shared function declaration. Fig. 9 schematically illustrates bytecode for an exemplary function declaration.

[0042] Fig. 10 shows the encoding of the graph in Fig. 5 without a metadata array.

[0043] Figs. 11 (a)-(i) schematically illustrate the traversal of a stack-based interpreter on the graph of Fig. 5.

[0044] Figs. 12(a)-(e) schematically illustrate the interpretation process of the same stack-based interpreter on the bytecode array of Fig. 10.

[0045] Fig. 13 shows the steps of an exemplary method for processing a data graph.

[0046] Fig. 14 schematically illustrates an example of an apparatus for implementing the method described herein and some of its associated components.

[0047] DETAILED DESCRIPTION

[0048] Embodiments of the present disclosure relate to approaches that allow efficient interpretation of intermediate representations of data structures, such as ASGs, without having to compile them into a dedicated bytecode representation.

[0049] Instead of compiling the graph-based intermediate representation into a dedicated bytecode representation, the present approach changes the structure and memory representation of a graph in such a way that it can be efficiently traversed for program interpretation purposes.

[0050] In compilation processes, ASGs are commonly used as an intermediate representation. Such graphs generally comprise multiple nodes and edges connecting at least some of the nodes. It may be assumed that in such graphs, nodes are dispersed in memory and are connected through memory pointers.

[0051] Incoming and outgoing edges of a node may be ordered, so that they can be represented as lists of incoming and outgoing edges. In the following description, nodes and edges may be represented as in Fig. 2. For node 201 shown in Fig. 2, edges i1 (202), i2 (203) and i3 (204) represent incoming edges while edges o1 (204) and o2 (205) represent outgoing edges. They are ordered from left to right, so the list of incoming edges is [i1 , i2, i3] and the list out outgoing edges is [o1 , o2].

[0052] In the approach described herein, an ASG is encoded into an array of integer values for the purpose of efficient program interpretation. Fig. 3 shows the basic workflow of an exemplary implementation of the present approach. An AST 301 is compiled into an ASG 302, which is an intermediate representation of the compilation workflow. The ASG 302 comprises multiple nodes and multiple edges, each edge connecting a node to another node of the graph.

[0053] If the program is to be interpreted, the graph can be ‘flattened’ in memory and the ASG 302 can be encoded into a data structure which is referred to herein as a Sequential Abstract Syntax Graph (SASG) 303. The SASG is in the form of an array, where the array comprises multiple cells each storing an integer value. This representation is not optimal for applying optimizations, since changing a node in the graph can required shifting all the subsequent nodes in memory, but it is very efficient for interpretation since data associated with all the nodes are compacted together in memory.

[0054] Furthermore, the SASG 303 can also be efficiently and effectively serialized into permanent storage, since it has no pointers to the volatile memory. It can also be efficiently and effectively un-flattened back into an ASG. This allows the following workflow: (i) encode different compilation units into SASGs and serialize them into permanent storage; (ii) link the SASGs together and unflatten the resulting SASG into an ASG for further optimizations to be applied.

[0055] As shown in Fig. 3, program optimizations can still be performed on the typical ASG memory representation. This ASG representation is more suitable for graph rewriting, since the graph can be easily changed by changing memory pointers.

[0056] In the approach described herein, a typical graph representation is encoded by allocating nodes on the memory heap and connecting them by pointers (the ASG) into a sequential memory representation (the SASG) that is efficient for interpretation. The approach uses one or more array-like structures to represent the SASG, one example of which are depicted in Fig. 4.

[0057] The primary array structure can be referred to as the bytecode array. The bytecode array contains the information from the graph used for interpretation in the form of integer values. The integer values in the array comprise optional indexes to the metadata array. The elements of the bytecode array are all integer values. This is optimal for performance reasons.

[0058] Another array structure is a metadata array that contains extra information that is not used for interpretation, but that might be required for other processes such as error reporting, debugging purposes, or compilation options that should be passed to the next compilation staged. Therefore, this information can be stored such that it can be easily accessed if required. Program locations, to be used for error reporting and program debugging, and mangle names, to be used by the linker, are examples of metadata that can be stored in the metadata array. The elements of this structure can be arbitrarily complex, since the interpreter does not need to resort to it during the interpretation operation. The elements of the metadata array need not be integers. In some examples, there may not be a metadata array.

[0059] The main goal is that all the information to be used for interpretation is compacted together in the first array structure (the bytecode array), while the information that is less frequently accessed than the information in the first array structure (which may be outside of the interpretation loop of the interpretation operation) can be stored in an additional array. The first array may comprise pointers to memory locations in which the metadata corresponding to particular nodes is stored.

[0060] The bytecode array may comprise integer values representing operation codes (opcodes) for each of the nodes of the graph. The operations in the array can assume varied forms, but for uniformity reasons they preferably all have a similar head. The operations may have additional information depending on the opcode (the opcode is stored as an integer in the first array).

[0061] In Fig. 4, the first array (the primary bytecode array) is shown at 401 and the additional array (containing metadata for some nodes of the graph) at 402. For the example shown in Fig. 4, the structure comprises the following components for a particular node of the graph:

[0062] 1 . An opcode represented by an integer flag, shown at 403. This identifies the operation kind. From this opcode, it may be inferred whether there is any additional information to be stored in the array for that node.

[0063] 2. An index i to the metadata array shown at 404 (which may not be present for all nodes) with extra information about the node.

[0064] 3. Additional information (‘extra info’) depending on the node operation, shown at 405. The additional information may be, for example, the number of arguments of the operation. For some nodes, the additional information might not exist (for example, for a binary operation) or can occupy more than one cell in the array 401 .

[0065] These integer values are each stored in a cell of the array (cells k, k+1 , k+2 in this example).

[0066] The translation of an ASG into an SASG may be referred to as the flattening process of a graph. The basic translation comprises conducting a post-order graph traversal, adding a representation for one node at a time to the bytecode array with an optional pointer to the metadata array containing metadata of the node. Due to the nature of the post-order traversal, at the point of encoding a node, all its arguments are already encoded in the bytecode array. The post-order traversal is justified by the fact that it is assumed that the evaluation of ASGs follows the same traversal order. That is, for each node:(1) visit each incoming edge from left to right; (2) evaluate the current node.

[0067] Fig. 5 shows an example of an ASG 500 comprising nodes 501 , 52, 503, 504 and 505 where the data flows downwards. The ASG 500 represents a tuple constructor of the form tuple (43 + 55, ‘a’).

[0068] The flattening of the graph 500 into an array is illustrated in Fig. 6. For simplification purposes, the metadata array is omitted in Fig. 6. In the bytecode array:

[0069] - INT64, INT64 / +, CHAR, TUPLE are the opcodes for the nodes and are stored as integers representing the respective operation at cells 601 , 604, 607, 609 and 612 for nodes 501 , 502, 503, 504 and 505 respectively.

[0070] - he cells 602, 605, 608, 610 and 613 contain indices for the metadata array for nodes 501 , 502, 503, 504 and 505 respectively.

[0071] - For the nodes 501 , 502 and 504 an extra cell is used to store the integer and char values 43, 55 and ‘a’ respectively as additional information in cells 603, 606 and 611 respectively.

[0072] - Node 503, which is an integer-64 binary operation, does not require any extra information. Therefore, the node representation for this node comprises one integer value representing the opcode for the node.

[0073] - To encode node 505 (the tuple construct) the size of the tuple (2) is stored at cell 614, so that the interpreter knows how many arguments this operation expects.

[0074] Sections 615, 616, 617, 618 and 619 the array therefore correspond to the node representations for nodes 501 , 502, 503, 504 and 505 respectively.

[0075] For some operations, such as conditional branches, indirection is unavoidable. For instance, imagine an if-then-else operation as depicted in graph 700 in Fig. 7. Node 701 should be evaluated first and then, depending on the result, the evaluation of the content of thunk 702 or thunk 703 should proceed. In terms of bytecode, the encoding of node 701 will still precede the encoding of node 704, since this is indeed the result of a post-order traversal and also the evaluation order, but then the encoding of the thunks will be sequentialized and the index of at least one of the thunks stored in the extra info of node 701 . For example, it may be assumed that thunk 702, the then thunk, is encoded just after the encoding of node 701 and thunk 703, the else thunk, is encoded immediately after - in this case the index of the else thunk can be stored in the extra info of node 701 at the bytecode array.

[0076] Another point where indirection is unavoidable is with function declarations. They can be shared (e.g. multiple function applications to the same function declaration) but it is desirable not to copy them multiple times in the bytecode (in case of recursive functions this would even be impossible). Therefore, in the bytecode array there can be an operation to represent the function node that contains the index of the function body as additional information. Fig. 8 depicts a graph 800 with a generic function declaration 802 that has multiple output edges. 801 is a thunk containing the function body. The features shown at 806 and 807 in the thunk 801 are the arguments of the functions. 803, 804 and 805 are further nodes of the graph 800. Node 805 is a node representing the function application. Nodes 803 and 804 represent the first and last arguments of the function application.

[0077] Fig. 9 depicts how the function is encoded in the bytecode array 900.

[0078] In this example, the function body 801 lives separated from the function node 802. Function declaration 801 is encoded at 901. An example of the encoding of the function node is shown at 902. The function body is declared once and for all at 901. At cell 909 is an index to the metadata array and the extra information at cell 910 comprises an index of the function body. The function node 802 is encoded as many times as the number of output edges in the original graph. Cell 904 is an opcode. To capture the arguments 806, 807 of the function, the location of the first operation is in cell 905 and everything that goes in between are bound variables, for example at cell 906 corresponding to the function first argument.

[0079] The arguments of the function application, 803 and 804, and the apply node 805 can be encoded in further cells at 903, as explained previously.

[0080] Assuming an ASG in which the input edges are ordered and dictate the evaluation order, the order in which the graph is encoded is in most of the cases the same as the interpretation order. In terms of the interpreter, the only change is related to the traversal algorithm which will now traverse an array-like structure instead of a typical graph representation.

[0081] In the examples described above, the metadata array is an additional array with indexes in the bytecode array representing locations of the metadata array. The use of the metadata array structure is not essential for the efficient interpretation of abstract syntax graphs, since it is not used during the interpretation process. One alternative is to simply omit the indexes from the primary bytecode array corresponding to locations of the metadata array and to instead use map structure to store the metadata. The map structure can associate op code indexes with metadata content.

[0082] The flattening of the graph 500 according to this alternative implementation is illustrated in Fig. 10. In the bytecode array 1000:

[0083] - INT64, INT64 / +, CHAR, TUPLE are the opcodes for the nodes and are stored as integers representing the respective operation at cells 1001 , 1003, 1005, 1006 and 1008 for nodes 501 , 502, 503, 504 and 505 respectively.

[0084] - For the nodes 501 , 502 and 504 an extra cell is used to store the integer and char values 43, 55 and ‘a’ respectively as additional information in cells 1002, 1004 and 1007 of the array 1000 respectively.

[0085] - Node 503, which is an integer-64 binary operation, does not require any additional information.

[0086] - To encode node 505 (the tuple construct) the size of the tuple (2) is stored at cell 1009, so that the interpreter knows how many arguments this operation expects.

[0087] Sections 1010, 1011 , 1012, 1013 and 1014 of the array therefore store node representations that correspond to nodes 501 , 502, 503, 504 and 505 respectively.

[0088] Comparing Fig. 10 with Fig. 6, note that the op code is not proceeded by an index indicating a location in the metadata array. Instead with this representation the metadata information can be captured in a metadata map. For the bytecode of Fig. 10, the metadata map will be of the form {0 Ml, 2 M2, 4 M3, 5 M4, 7 MS], where 0, 2, 4, 5, 7 correspond to the opcodes indexes and Ml, M2, M3, M4, MS correspond to the metadata information for nodes 501 , 502, 503, 504, 505 respectively. Note that this representation results in a more compact bytecode array (which is visible just by comparing Fig. 6 and Fig. 10) at the cost of a slower access to the metadata information incurred by the access to the map.

[0089] In the examples described above, one (and only one) integer value in the bytecode array is the operation code for the node. Specifically, only the first integer value is the operation code. The subsequent integer values, if they exist for a particular node, can be an index indicating a location in an additional array (for example, the metadata array), and / or additional information for that operation code. There may be n integers representing additional information, n can be inferred from the operation code (i.e. for each operation code there is a fixed number n). In other words, for each operation code there may be a fixed number of cells to capture additional information about that node. The content of each additional cell is also clear from the operation code.

[0090] By encoding each node to form a node representation comprising one or more integer values to be stored in an array, the representation of the nodes of the graph is more compact and efficient for interpretation of the graph.

[0091] The node representation for each node of the graph can be formed by applying traversal algorithm to the graph and extracting data from each node of the graph. The node representation can be stored as one or more of: one or more integer values for each node (in the array), additional information in the array for some nodes (in the array) and optionally the metadata from each node (stored in one or more additional arrays). The node representation may comprise the index indicating the location for the metadata for a respective node in the additional array.

[0092] Once each node of the graph has been encoded into the array, an interpretation operation can be performed on the array to interpret the graph.

[0093] Any interpreter that is able to interpret ASGs, can now be used to interpret SASGs, by simply changing the traversal part of the interpreter, instead traversing the ASG the interpreter will traverse the bytecode array.

[0094] Figs. 11 (a)-11 (i) schematically illustrates the traversal of a stack-based interpreter on the graph 500 of Fig. 5.

[0095] Fig. 11 (a) shows the initial state of the interpretation of the graph. In this example, it is assumed that the graph depicted is a subgraph of a bigger graph, and thus the stack 550 might already contain some values (depicted by “...”). The arrow on the right of the stack 550 shows the direction in which the stack grows. The arrow under the node 505 depicts the current node. Since the arguments of the “tuple” operation haven’t been interpreted, the interpretation moves into the first argument in Fig. 11 (b), and then into the node 501 containing the value “43” in Fig. 11 (c). At this point, since the operation has no arguments, the interpretation of an integer value involves simply adding it to the stack. Moving now down the graph, the “+” node 503 is reached in Fig. 11 (d). Since the first argument has been evaluated, the process moves into the next node 502 in Fig. 11 (e). The interpretation continues until all the arguments are traversed and at the end, in Fig. 11 (i), the process is back at the tuple node 505 with all the arguments being evaluated. At this point, a tuple can be built (showing on the stack in Figurel 1 (i)) using the two arguments shown on the stack in Fig. 11(h).

[0096] 12

[0097] RECTIFIED SHEET (RULE 91) ISA / EP Figs. 12(a)-12(e) schematically illustrate the interpretation process of the same stack-based interpreter on the bytecode array 1000 of Fig. 10.

[0098] Fig. 12(a) shows the initial state of the interpretation of the bytecode array. The interpretation starts on the first cell 1001 and moves from operation to operation. Interpreting “INT64” operation results in adding the integer value “43” to the stack. Moving to the next operation in Fig. 12(b), this adds “55” to the stack 550. In Fig. 12(c), the interpretation of the binary operation “+” takes places which results in popping two elements from the argument stack (shown on the stack in Fig. 12(b)) and pushing the result into the stack (showing on the stack in Fig. 12(c)). The result of interpreting a “CHAR” operation is shown in Fig. 12(d). Fig. 12(e) shows the final result of evaluating the “TUPLE” operation.

[0099] Fig. 13 shows the steps of an exemplary computer-implemented method of processing a data graph. At step 1301 , the method comprises forming a node representation for each node of the graph. At step 1302, the method comprises storing at least part of the node representation for each node of the graph as one or more integer values in an array. At step 1303, the method comprises performing an interpretation operation on the array.

[0100] The device 1400 shown in Fig. 14 may be configured to operate as a data processing device configured to perform the method described herein. The device 1400 comprises a processor 1401 and a memory 1402. The processor may be implemented as dedicated hardware in the device, such as a processing chip. The memory is arranged to communicate with the respective processor. The memory may be a non-volatile memory. The device may comprise more than one processor and more than one memory. The memory may store data that is executable by the processor. By executing program code contained in such data, the one or more processors may perform functions as described herein. The memory may store such program code in a non-transitory manner. The processor may be configured to operate in accordance with a computer program stored in non-transitory form on a machine readable storage medium. The computer program may store instructions for causing the processor to perform its methods in the manner described herein. The device may also comprise a power source, such as a battery, or is connectable to mains power.

[0101] Using traditional techniques, some information from the ASG nodes can be particularly difficult to store in the bytecode array, because the ASG may contain a large amount of additional information for some nodes. For example, for string literals, the value of the string is stored which might require a rather large amount of bytecode cells. Moreover, that information can be required during interpretation, so storing it in the metadata array can affect interpretation performance. Therefore, the present approach also allows for node metadata to be stored in other array-like structures which can be indexed in the bytecode array. These other array-like structures may be referred to as sections (e.g. the SASG can contain a section for strings represented as an array of strings). In the bytecode array, to refer to values stored in one of the sections, the index of the respective section may be used (e.g. a string operation can then comprise a “string” opcode and an index for the strings’ section as additional information).

[0102] Performing an interpretation operation using the original ASG representation is slow, mainly because the nodes are scattered all over the memory. Conversely, performing the interpretation operation on the array representation is faster, because nodes are stored in a contiguous and compacted chunk of memory.

[0103] The encoding of intermediate representations of data structures such as ASGs as described herein can advantageously allow for more efficient interpretation, shorter compilation workflow before efficient interpretation and efficient graph serialization into permanent storage.

[0104] This approach can be applied to compilers that perform the compilation of computing source code into any graph-based intermediate representation for the purpose of efficient interpretation.

[0105] The applicant hereby discloses in isolation each individual feature described herein and any combination of two or more such features, to the extent that such features or combinations are capable of being carried out based on the present specification as a whole in the light of the common general knowledge of a person skilled in the art, irrespective of whether such features or combinations of features solve any problems disclosed herein, and without limitation to the scope of the claims. The applicant indicates that aspects of the present disclosure may consist of any such individual feature or combination of features. In view of the foregoing description it will be evident to a person skilled in the art that various modifications may be made within the scope of the disclosure.

Claims

CLAIMS1. A data processing device (1400) for encoding a data graph (500, 700, 800) comprising multiple nodes for interpretation, the device comprising one or more processors (1401) configured to: form (1301) a node representation for each node (501 , 502, 503, 504, 505, 701 , 704, 802, 803, 804, 805) of the graph; store (1302) at least part of the node representation for each node of the graph as one or more integer values in an array (401 , 600, 900, 1000); and perform (1303) an interpretation operation on the array.

2. The data processing device (1400) as claimed in claim 1 , wherein one of the one or more integer values for each node of the graph comprises an operation code.

3. The data processing device (1400) as claimed in claim 1 or claim 2, wherein the array comprises one or more indices indicating a location in an additional array for one or more nodes of the graph.

4. The data processing device (1400) as claimed in claim 3, wherein the one or more processors are configured to cause metadata for one or more of the nodes to be stored in the additional array (402).

5. The data processing device (1400) as claimed in claim 4, wherein the interpretation operation does not use the metadata.

6. The data processing device (1400) as claimed in any of claims 3 to 5, wherein the one or more processors are configured to cause the additional array to be stored separately to the array.

7. The data processing device (1400) as claimed in any preceding claim, wherein the one or more processors are configured to cause the array to be stored at a contiguous block of memory.

8. The data processing device (1400) as claimed in any preceding claim, wherein the array further comprises additional information for one or more of the nodes.

9. The data processing device (1400) as claimed in claim 8, wherein the additional information comprises a number of arguments for a respective node.

10. The data processing device (1400) as claimed in any preceding claim, wherein the one or more processors are configured to form the node representation for each node by applying a first traversal algorithm to the graph and extracting data from each node of the graph.

11. The data processing device (1400) as claimed in claim 10, wherein the one or more processors are configured to perform the interpretation operation by applying a second traversal algorithm to the array to traverse the nodes in the same order in which the nodes of the graph were traversed using the first traversal algorithm.

12. The data processing device (1400) as claimed in any preceding claim, wherein the array is a compacted representation of the graph.

13. The data processing device (1400) as claimed in any preceding claim, wherein the graph is an intermediate representation of a data structure.

14. The data processing device (1400) as claimed in claim 13, wherein the data structure comprises an abstract syntax tree.

15. The data processing device (1400) as claimed in any preceding claim, wherein the graph is an abstract syntax graph.

16. A method (1300) for encoding a data graph (500, 700, 800) comprising multiple nodes for interpretation, the method comprising: forming (1301) a node representation for each node (501, 502, 503, 504, 505, 701, 704, 802, 803, 804, 805) of the graph; storing (1302) at least part of the node representation for each node of the graph as one or more integer values in an array (401 , 600, 900, 1000); and performing (1303) an interpretation operation on the array.

17. A computer program which, when executed by a computer (1400), causes the computer to perform the method (1300) of claim 16.

Images