Combination Reduction Processing Method and Apparatus

1. Field of the Invention

The present invention relates to a processing method and processing apparatus for functional languages etc., and, more particularly, to a computation processing method and apparatus constructed of a plurality of element processing functions according to which reduction computations for realizing the evaluation of a normal order, etc. attended with lazy evaluations are executed efficiently in parallel.

2. Description of the Prior Art

Heretofore, as the fundamental models of computations, one conforming to the principle of the Turing machine and one based on Church's .lambda.-calculus have been well known. Computers based on the principle of the Turing machine type are also called the `von Neumann type`, and hold the mainstream of present-day computer architectures. On the other hand, the process of the computation based on the .lambda.-calculus is also called the `reduction type`. Since, in general, programming languages founded on this calculus do not involve side effects, they are termed `functional or applicative languages`, a typical one of which is Lisp.

In the .lambda.-calculus, the .lambda.-notation is employed in order to clearly distinguish variables for the definition of a function and the value of the function. In, for example, an equation x+y, the definition of a function whose variable is x is expressed as .lambda.x.multidot.x+y, and the definition of a function whose variables are both x and y is expressed as .lambda.x.multidot..lambda.y.multidot.x+y. The operation of obtaining the function .lambda.x.revreaction.E(x, y) by placing .lambda.x before the equation E(x, y) in this manner is called the .lambda.-abstraction, and x is called a bounded variable when the variable x is included in the .lambda. terms. In case of applying 2 to x and 3 to y in the following equation, the computative process in the .lambda.-calculus is executed through transforms: ##EQU1## This computative process is called the reduction.

In the .lambda.-calculus, such reductions are repeatedly executed until an equation at which no more reduction is possible, namely, a normal form is reached. Regarding equations which can reach the normal form, an order in which the reductions are performed from the leftmost and outermost equation is called the normal order, and an order in which the reductions are performed contrariwise from the leftmost and innermost equation is called the applicative order. It is known that some of computative equations which stop in the normal order do not stop in the applicative order.

As a processing system for various functional or applicative programming languages based on the .lambda.-calculus, there has been proposed the Turner system which utilizes combinatory logics.

D. A. Turner: A New Implementation Technique for Applicative Languages; Software--Practice and Experience, vol 9, No 1, pp 31-49, 1979

Other known examples closest to the present invention are:

Official Gazettes of Japanese Laid-Open Patent Application Nos. 58-8358 and 58-8359.

Combinators were discovered by Schonfinkel and Curry in about 1930, and the combinators S, K, I, B, C and W are given by the following equations. Here, f and g denote functions each having one argument, and x and y variables. ##EQU2##

It is known that, among these combinators, the relations of I.tbd.SKK, B.tbd.S (KS) K, C.tbd.S (BBS) (KK) and W.tbd.SS (SK) hold.

The Turner system subjects a program described in functional forms, to the abstraction of eliminating variables by the use of combinators, so as to transform the program into the binary graph expression of the combinators, and regards the graph as machine instructions, which are construed and executed. Assuming that [x] be written instead of .lambda.x in the abstraction with the combinators, the following holds: ##EQU3## where I, K and S denote the combinators, and P and Q the functional equations.

In the Turner system, a multi-argument function f is transformed into a higher order function f' of one argument. This transform is called currying, which is defined as follows: ##EQU4##

As an example of the abstraction, SUC (x)=1+x is: ##EQU5##

The resulting binary graph is shown in FIG. 12. This graph corresponds to machine instructions in an ordinary computer, and actual computations are performed by reductions indicated below. ##EQU6## It is stated by Turner that the system can be realized with a stack mechanism by storing graphs in a computer.

The Turner system is characterized in that a function having a plurality of arguments is curried and transformed into a higher order function of one argument. Therefore, a combinator graph obtained by abstraction becomes redundant, and the number of steps in the process of reductions for evaluation increases. Another disadvantage is that, even when the arguments can be processed in parallel, they are processed one by one, so the parallel processing is difficult. Moreover, since the abstraction of removing variables from a program results in performing the abstraction of each variable over the entire program, the efficiency of compile is not favorable.

A first object of the present invention is to provide a data processing method and apparatus which are capable of realizing parallel reduction computations in, for example, the normal order attended with lazy evaluations, and so forth, as an efficient processing method and processing apparatus for solving the problem that the efficient execution of principally functional or applicative programming languages has been difficult with the architectures of conventional computers.

A second object of the present invention is to provide a data processing method and apparatus in which, in order to cope with the problems mentioned above, combinator graphs with product structures introduced and an evaluation system based on reductions thereof are employed for functional or applicative programming languages, thereby to realize the concise expression and efficient run of a program.

FIG. 1 is a flow chart showing the steps of a process in a first embodiment of the present invention;

FIG. 2 is a block diagram showing an example of a computative apparatus in the present invention;

FIG. 3 is an arrangement diagram of a reduction processor unit which is the first embodiment of the present invention;

FIG. 4 is an explanatory diagram showing an example in which combinator graphs in the present invention are assigned to FIG. 3;

FIG. 5 is a flow diagram showing the processes of an elementary processor in the present invention;

FIG. 6 is a flow diagram showing the processes of general function callings in the present invention;

FIG. 7 is a block diagram showing the arrangement of the elementary processor in the present invention;

FIG. 8 is a diagram showing the contents of a combinator word in the present invention;

FIG. 9 is an explanatory diagram showing the contents of a packet in the present invention;

FIG. 10 is an explanatory diagram showing the relationship between a stack management descriptor and a stack area in the present invention;

FIG. 11 is an explanatory diagram showing a system of stack management for a combinator T indicative of a tuple in the present invention;

FIG. 12 is a diagram showing a Turner graph which is a known example;

FIG. 13 is an explanatory diagram showing an example in which FIG. 12 is depicted using the tuples;

FIG. 14 is an explanatory diagram showing an example which uses the tuples in the present invention; and

FIG. 15 is an explanatory diagram showing the way of assignment to process units in the present invention.

FIG. 16 is a diagram showing a combinator graph based on the Turner system;

FIG. 17 is a flow chart of program processes according to the present invention;

FIG. 18 is a diagram showing a combinator graph which uses products;

FIGS. 19(a)-19(e) are diagrams showing the course of the reductions of suc 3 according to the system of the present invention;

FIG. 20 is an arrangement diagram showing the node of a variable-length cell with a header;

FIG. 21 is a diagram showing the format of a header field;

FIG. 22 is an explanatory diagram showing the internal form of a V-graph which corresponds to max <3, 5>;

FIG. 23 is a flow chart showing a reduction operation;

FIGS. 24(a)-24(j) are explanatory diagrams showing the operations of stack at the time at which reductions for evaluating max <3, 5> are performed;

FIG. 25 is a diagram of the arrangement of hardware which has a register array for pointer caching according to the present invention; and

FIG. 26 is a block diagram showing the arrangement of a memory device which is especially suited to the present invention.

[First Embodiment]

The principle of a first embodiment will be described.

The system of the present invention for processing functional or applicative programming languages uses combinators likewise to the Turner system, but it is realized without currying a function which has a plurality of arguments. A tuple structure which allows the arrayal of arguments is introduced into a combinator expression as follows.

Letting the tuple of a formula x.sub.1, x.sub.2, . . . , x.sub.n be denoted by <x.sub.1, x.sub.2, . . . , x.sub.n > (also called the T combinator), a function having n arguments can be expressed as f: <x.sub.1, x.sub.2, . . . , x.sub.n >. That is, the basic principle of the present invention consists in that any multi-argument function having a plurality of arguments is handled as a function of one argument which is applicative to the arguments of the tuple.

Further, this can be applied to the tuple of functions f.sub.1, f.sub.2, . . . , f.sub.n. ##EQU7##

Now, combinators need to be defined for the tuple x.tbd.<x.sub.1, x.sub.2, . . . , x.sub.n >, and the combinators K, S, I, C, B and W mentioned before can be used as they are when the tuple is regarded as one variable. A combinator J.sub.i for selecting any element from the tuple is defined anew as follows: ##EQU8##

Abstractions become as follows: ##EQU9##

A graph which is obtained through such abstractions employing tuples shall be called the V-graph.

The following V-graph (FIG. 13) is obtained for Suc (x)=1+x mentioned before. ##EQU10##

Next, the superiority of the present system employing tuples will be explained over the Turner system.

As an example,

will be taken.

This function curried is put:

The combinator expression for (1) becomes:

Further, when the combinators B and C are applied, the expression becomes:

When the two variables x and y are included as in this example, they are abstracted in the order of y and x, and hence, two times of text traverse are required in principle. Besides, the length of the combinator expression to be obtained becomes the order of n.sup.2 in the worst case, n denoting the length of a source program.

When tuples are used, the result of the aforementioned example (1) becomes: ##EQU11## and the abstractions are possible with one time of text traverse in principle.

The combinator expression based on the Turner system is given by a binary tree called the Turner graph. It is known that calculations can be carried forward by evaluating the Turner graph successively in the normal order by the use of a reduction stack.

The present invention proposes a parallel evaluation system in the normal order based on the V-code expression founded on the tuples.

The graphical expression in V-codes, of the function f mentioned at (2) becomes as shown in FIG. 14. Assuming that . . . f: <3, 4>. . . be applied to the function f, the reduction course at this time becomes: ##EQU12## When this course is illustrated, a network of process units as shown in FIG. 15 is formed.

It is not easy to subject this example to the evaluations of add and sub in parallel by the use of the Turner graph. That is, the Turner system curries the arguments of a function, transforms a multi-argument function into a higher order function of one argument and evaluates the higher order function, whereas the present system evaluates a multi-argument function by the use of tuples, and in principle, it readily realizes a parallel evaluation in the same number as that of the degrees of multiplicity of arguments.

The first embodiment of the present invention will be described in the order of the hardware arrangement and operation thereof. Processes from a source program to execution are as shown in FIG. 1. These steps are actualized by an apparatus shown in FIG. 2. The apparatus is so constructed that a main processor unit 22 (MPU), a main memory device 23 (MMD), a peripheral device 24 (PD) and a reduction processor unit 25 (RPU) are coupled by a bus 21.

As shown in FIG. 3, the reduction processor unit is such that elementary processors (EPs) 31 are coupled in the shape of a matrix. It is connected to the external bus via horizontal and vertical bus controllers 34, 35.

As indicated at numeral 11 in FIG. 1, the program described in a functional language is decomposed into tuples, functions and variables and is transformed into combinator forms having the tuple structure. For example, the source program mentioned before:

is transformed into combinator forms: ##EQU13## The corresponding graphical expression is shown in FIG. 13. A method of assigning FIG. 13 to the EPs is realized by supposing the assignment to the respective process units as shown in FIGS. 14 and 15. The V-codes transformed into the combinator forms are stored in the main memory device, and are assigned to the EPs at a stage preceding the execution. An example of results obtained by assigning the graphical expression of FIG. 13 to the EPs is shown in FIG. 4.

The exchange of information among the EPs is performed with packets to be described later, which are transmitted through the horizontal or vertical bus controller 34 or 35 in FIG. 3.

FIG. 7 shows a detailed block diagram of the EP 31. The EP is composed of an arithmetic/logic unit 31-1 (ALU), a control register 31-2 (CRG), a stack area 31-3 (STM) and a read only memory 31-4 (ROM).

The basic operation instructions of the EP are stored in the ROM. The basic operation instructions include arithmetic instructions add, sub, mul, div etc., and besides, combinator instructions which are the instructions of operations corresponding to S, B, I, K, T etc. In addition, as a result of the assignment of the nodes of the V-codes to the processors, a combinator word 81 (COW) shown in FIG. 8 is created in each processor. Addresses in FIG. 8 signify the identifiers of the processors, and are expressive of the arrangement <i, j> of the reduction processor unit (RPU).

Before stating an operating example, the organization of the packet as well as the stack area will be described.

The packet 91 has a format in FIG. 9. Here,

(1) length. . . length of the packet

(2) receiver. . . receiving address

"Addresses" are the identifiers <i, j> of the processors and the indexes of stack management descriptors (ISMDTs) [to be described later].

(3) sender. . . sending address

(4) operation. . . force evaluation, lazy evaluation, demand evaluation, results

(5) data kind

direct value. . . value itself

indirect value. . . value stored in a location indicated by an address (92)

The relationship of a stack and the management descriptor thereof in the stack area (STM) is shown in FIG. 10. The stack management descriptor 101 (SMD) is provided with status information and a stack frame pointer.

The status information contains:

(1) "used" flag. . . Under use of the descriptor.

(2) number of reference times. . . Number by which the stack referred to data.

(3) "evaluated" flag. . . Value is stored in the stack.

(4) "under evaluation" flag. . . At present, the force or lazy evaluation is proceeding.

(5) others.

When the stack has been filled up, a garbage collector operates to compact frames within the stack, and the stack frame pointers are updated on the basis of the results.

A stack frame descriptor is created in the corresponding frame each time the stack frame is secured. In the stack frame descriptor, there are set the size of the stack frame, received data, and a "results received" flag in the case of receiving a plurality of results. The area of the frame other than the descriptor is used for result data and a job area.

Processes in the EP 31 in FIG. 7 are shown in FIG. 5. First, a function calling system will be explained in detail. Function callings are classified into the case of primitive functions which can be directly executed by hardware, such as addition and subtraction, and the case of general functions which have been defined by a programmer.

In general, the function callings need to be previously put into a structure which is recursive and which can be executed in parallel. The combinator word (COW) which is set in the processor for the function calling is as shown in FIG. 8.

As illustrated in FIG. 10, the relation of correspondence with applicative data is indicated with the index of the stack management descriptor (ISMDT) 104. In sending data, the ISMDT of the corresponding processor is always sent, and data returned as a result is checked on the basis of the ISMDT.

Processes in the case of the primitive function are as follows:

(1) Demand Process

A received packet is saved in a stack, and the packet with the corresponding ISMDT affixed thereto is sent to a processor which is indicated by the argument address of a combinator word. Status information at this time is force evaluation.

(2) Result Process

When a result argument value has been received from the processor of the argument address, the ISMDT of the packet is checked, and the value is piled on the stack. At this time, the contents of an old stack frame descriptor are copied, and a frame pointer is updated.

Thereafter, the primitive function is applied to the argument value, to create a packet in which the value of the executed result is put and which is sent to the return address of the combinator word. Next, an SMDT 102 is set free.

The case of the general function calling is carried forward in accordance with a flow chart in FIG. 6:

(1) Demand Process

A received packet is saved in a stack, and the packet with the corresponding ISMDT affixed thereto is sent to a processor indicated by the link address of a combinator word. A status here is lazy evaluation.

(2) Force Evaluation Process

When the indication of force evaluation for an argument has been received, the sender of the packet is put in a stack frame descriptor corresponding to the ISMDT, and the data of a stack frame has argument No. affixed thereto and is sent to an argument-address processor.

(3) Process to Return Results of Force Evaluation

Results returned from the argument-address processor are delivered to a requester for the force evaluation.

(4) Result Process

The evaluated results of the function body are received, and are sent to a demander indicated by a result address. Besides, in order to eliminate the remainder of the lazy evaluation based on the same ISMDT, a packet which erases ISMDT information within the T processor corresponding to the ISMDT is sent to the T processor indicated by the argument address.

Lastly, the system of the T processor for processing tuples will be explained. In order to allow a recursive program, a stack as shown in FIG. 11 is exploited. In general, when there are n arguments, the parallel processes of the arguments are carried out in compliance with the individual evaluation demands for the respective arguments.

(1) Process to Demand Argument Evaluation

Since argument evaluation realizes the system of lazy evaluation, if the evaluation has been made is checked. If not made, the argument evaluation is performed.

(2) Process of Result of Argument Evaluation

The result of the argument evaluation is saved in the stack, an "evaluated" flag is set in status information, and a packet for a result value is created and sent to a demander for the argument evaluation.

(3) Elimination of Argument Evaluation Results

At the time at which the evaluation of a function body has ended, the argument evaluation results corresponding to the demand for the evaluation of the function are removed from the stack.

The embodiment thus far described provides a processing apparatus for functional languages etc. which permits the efficient execution of the functional or applicative programming languages that could not be expected with conventional von Neumann type machines.

That is, unlike procedural languages presently forming the mainstream, functional or applicative programming languages capable of readily developing programs of higher productivity and reliability can be utilized, and the invention is effective to increase the data processing efficiency in this field.

[Second Embodiment]

The principle of the second embodiment of the present invention will be described.

The system of the present invention for processing functional or applicative programming languages uses combinators likewise to the Turner system, but it is characterized in that a product structure which treats the arrayal of parameters as one object is introduced into a combinator graph, whereby a multi-parameter function can be handled as it is without being curried.

The combinator graphs having the product structures are defined as follows, and shall hereinbelow be called V-codes:

(i) Constants are V-codes.

(ii) Variables and functions are V-codes.

(iii) A product <V.sub.1, . . . , V.sub.n > (V.sub.i : V-codes) is a code.

(iv) An application fV (f: function or combinator, V: V-code) is a V-code.

(v) combinators S, K, B, C, W, I and J.sub.i are V-codes. Here, J.sub.i is defined by the following formula:

The other combinators shall be defined in V-codes by the same definition formulas as in the Turner system.

Since, with the V-codes, the product of any order can be handled as one object, the V-code expression can be regarded as having an n-ary tree structure. The V-codes expressed as a graph like an n-ary tree shall be called the V-graph.

As shown in FIG. 17, the program processing method of the present invention consists of three principal steps. The first step 221 inputs the source code of a program, and transforms the denoted applicative structure into a corresponding V-code expression. The second step 222 inputs the V-code expression containing variables, obtained as the result of the step 221 and subjects it to abstraction, thereby to eliminate all the variables and to transform the above V-code expression into a V-code expression containing no combinator (containing no variable). The third step 223 inputs the V-code expression obtained as the result of the step 222 (a combinator graph containing no variable), and evaluates it through reductions thereof.

At the first step 221, a multi-parameter function f assuming n parameters is handled as a function of one parameter which is applicative to a product consisting of n parameters. That is, the V-code expression of a program denoted by f (x.sub.1, . . . , x.sub.n) becomes f<x.sub.1, . . . x.sub.n >.

The second step 222 is effected in such a way that the V-code expression corresponding to the body of the function (the output of the step 221) is abstracted with the formal parameter of the single-parameter function (one variable) or the product of the formal parameters of the multi-parameter function (the product of n variables). The abstraction is performed by applying abstraction rules listed below. Hereunder, a V-code E abstracted with V shall be written [V] E.

For x, x.sub.i, y: variables, x=<x.sub.1, . . . , x.sub.n >, and E.sub.i : V-code, ##EQU14##

The third step 223 inputs the V-code expression of the program obtained as the result of the step 222 (consisting of combinators, a primitive function and a product) and subjects it to reductions in the normal order, thereby to run the program. The definition formulas of the respective combinators determine the corresponding graph reductions. The application of the product of a function is defined by <f.sub.1, . . . f.sub.n >X=<f.sub.1 X, . . . f.sub.n X>.

For example, the function suc (X)=1+X mentioned before becomes:

owing to the first step 221. Further, this is transformed into: ##EQU15## by the second step 222. The V-graph corresponding to .circle.1 is shown in FIG. 18. T.sub.2 node 231 in the figure is a node which denotes a product structure of order 2. Similarly, a product of order n is denoted by T.sub.n node. With the aforementioned suc, when the program is suc 3, the V-code expression of the program which is obtained as the result of the second step 222 is:

The V-graph corresponding to .circle.2 is shown in FIG. 19(a). Apply node 241 in the figure is used when it is desired to clearly write the applier of a V-code. The third step 223 receives the V-code expression as indicated by .circle.2 (namely, the V-graph in FIG. 19(a), performs reductions as: ##EQU16## and produces a result 4 (numeral 247 in FIG. 19(e)). The V-graphs corresponding to .circle.3 , .circle.4 , .circle.5 and .circleincircle.6 are respectively shown in FIGS. 19(b), 19(c), 19(d) and 19(e). Nodes having been the objects of the reductions are one 242 in .circle.2 .fwdarw. .circle.3 , one 243 in .circle.3 .fwdarw. .circle.4 , ones 244 and 245 in .circle.4 .fwdarw. .circle.5 and one 246 in .circle.5 .fwdarw. .circle.6 , respectively.

Next, the superiority of the present system employing products will be explained over the Turner system.

As an example, a function:

will be taken. With the Turner system, the curried expression of the function body:

is successively abstracted with parameters y and x as follows: ##EQU17## In this manner, it is in principle required to traverse a text that number of times which is equal to the number of the parameters. Besides, the length of the combinator graph to be obtained becomes the order of n.sup.2 in the worst case, n denoting the length of the source program.

When this example is processed with the present system employing products, it becomes:

owing to the first step 221, and ##EQU18## is obtained owing to the second step 222. With the present system, the combinator graph is obtained with one time of text traverse in principle irrespective of the number of parameters. It is also understood that the expression .circle.8 obtained is more concise than the result .circle.7 of the Turner system.

Now, the second embodiment of the present invention will be described in the order of the internal form of the V-graph, the reduction procedure of the V-graph in the normal order and the hardware arrangement.

An n-ary tree structure, in which each node can have a variable number of sub nodes, is employed as the internal form of the V-code in the present embodiment. As shown in FIG. 20, each node is denoted by a variable length cell with a header which consists of a header field 251 of one word length and source fields 252 of n word lengths (n.gtoreq.0). The header field 251 denotes the kind of the node. The internal form of the header field 251 is as shown in FIG. 21. It is composed of a mark bit 261 for garbage compaction, a tag 262 which denotes the sort of the node, and a field value portion 263 whose significance is determined according to a tag value (the value of the tag 262). Depending upon the tage values (the values of the tags 262), the nodes are classified into constants (real number, integer, character, logic value), system constants (combinator, incorporated function), a product (column) and a selector (J.sub.i). Field values (the values of the portions 263) are respectively construed as a constant value, system constant No., the order of the product, and the value of the index of the selector (which selector is to be selected) in accordance with the tag values (the values of the tags 262). While the form of the source field is similar, tag values allowed correspond to a character constant, a logic constant, a system constant, a selector and a pointer. For adopting an efficient garbage compaction system, it is necessary that the size of each node (namely, the number of the source fields) can be determined from only the contents of the header field 251. Therefore, a pointer value is not accepted as the header field 251. Instead, the combinator `apply` which clearly denotes the application of a function is employed. This combinator is defined by:

By way of example, let's consider the internal form of a function for finding a greater one of two numbers: ##EQU19## The first step 221 provides the V-code of max <x, y>=cond <ge<x, y>, x, y>. Here, cond <P, V1, V2> denotes a function corresponding to the conditional branch of if p then V1 else V2 endif, and ge a predicate for the comparison of values. This V-code is turned by the second step 222 into: ##EQU20##

Accordingly, the V-code expression for a program max (3, 5) employing this function becomes:

and the internal form thereof becomes a graph as shown in FIG. 22. Arrows 271 in FIG. 22 indicate reference relations by pointers.

Shown in FIG. 23 is a flow chart of reductions which are carried out for the present embodiment by the third step 223. The outline will be explained.

(281) The V-graph to be reduced now is pushed onto a stack and is followed by (282).

(282) While the top of the stack is the apply-node, keep its function part (left-hand subtree) pushed. Then, the control proceeds to (283).

(283) If the stack top is a combinator node, it is examined. When the condition is met, the control proceeds to (284), and when not, the control proceeds to (285).

(284) A graph operation corresponding to the combinator node of the stack top (as defined by the combinator) is executed, whereupon the control proceeds to (282).

(285) If the stack top is a primitive function node, it is examined. When the condition is met, the control proceeds to (286), and when not, the control proceeds to (289).

(286) It is checked if a real parameter corresponding to the primitive function of the stack top is in the form in which the function is applicable. When the function is applicable, the control proceeds to (287), and when not, the control proceeds to (288).

(287) Calculation for the real parameter of the function of the stack top is executed, and the corresponding V-code is substituted by the resultant expression. Then, the control is returned to (282).

(288) The real parameter of the function of the stack top is pushed, and the control is returned to (282).

(289) It is checked if only the stack top exists in the stack (if the stack is emptied by pop). When the condition is met, the control proceeds to (291), and when not, the control proceeds to (290).

(290) The stack is popped, and the control proceeds to (282).

(291) Since the result of the reductions (normal form) exists in the stack top, it is processed to be printed or saved in a file. Then, the reductions of the third step 223 end.

By way of example, the status changes of the stack and the contents of V-graphs in the reductions of the V-graph in FIG. 22 are shown in FIGS. 24(a), 24(b), . . . and 24(j). In each figure, the combinator or function at the stack top becomes the object of the reduction.

The present embodiment is realized by a hardware arrangement as shown in FIG. 25. This apparatus is constructed of a main processor unit 301 (MPU), a main memory device 302 (MMD), a stack memory 303 (STM), and a register array for pointer caching 304 (REG). A program to be run is transformed into combinator graphs (V-codes) having variable-free product structures, and is stored in the MMD 302 in the internal form described above. The MPU 301 or the REG 304 sends the address of a node to be referred to, to the MMD 302 via a line 305 or 306, whereby the content of the MMD can be read out via a line 307 or 308. The STM 303 operates as follows, according to stack operation instructures `push`, `pop`, `depth` and `pushregister` which are sent from the MPU 301 via a line 309:

push . . . A value sent from the MPU 301 via a line 310 is pushed onto the stack. Next, the value of a new stack top is sent to the REG 304 via a line 312.

pop . . . The value of the stack top is sent to the MPU 301 via the line 310. Next, the stack is popped, and the value of a new stack top is sent to the REG 304 via a line 312. If the stack empties, this situation is reported to the MPU 301 via a line 314.

pushregister . . . A value sent from the REG 304 via a line 313 is pushed onto the stack. Next, the value of the new stack top is sent to the REG 304 via the line 312.

depth . . . The depth of the stack at that time is sent to the MPU 301 via the line 310. The REG 304 has a large number of registers which are in one-to-one correspondnece with integers from 1 to n.

The REG 304 examines the respective source fields of the node of a V-graph which is denoted by the value sent from the STM 303 via the line 312. In a case where the source field is a pointer value (the address of a sub node), the REG sends the address to the MMD 302 via the line 306, reads the content via the line 308 and stores the value into the register of No. corresponding to the source field. In a case where the source field is any other than the pointer value, the REG puts the value thereof into the register of corresponding No. Next, the REG sends the content of the register of register No. equal to a value delivered from the MPU 301 via a line 311, to the STM 303 via the line 313.

The MPU 301 executes the reduction steps explained with reference to FIG. 23, in accordance with microinstructions. On this occasion, the STM 303 is used for the stacks for the reductions. The push and pop of the reduction stacks are effected by sending the instructions of push, pop etc. to the STM 303 via the line 309. Especially when the sub node of the stack top is to be pushed, the pushregister instruction is sent to the STM 303 via the line 309 instead of the push instruction, while at the same time the index of the sub node (No. of the sub node) is sent to the REG 304 via the line 311, whereby a value cached by the REG 304 beforehand can be pushed, and high-speed processing becomes possible. The V-graphs to be reduced are stored in the MMD 302, so that when the value of the V-graph has become necessary in the MPU 301 in the course of the reduction, the address of the node is sent to the MMD 302 via the line 305 so as to read out the value via the line 307. Besides, when it is desired to know the depth of the stack as at the reduction step 289 by way of example, the depth instruction is sent to the STM 303 via the line 309, and the depth fo the stack can be known via the line 310.

The above MMD 302 is of very high efficiency when it is a memory device with which, as shown in FIG. 26, one set is written and a plurality of sets (two sets in the figure) can be simultaneously read out.

Referring to the figure, read amplifiers S.sub.11, S.sub.12, . . . S.sub.32 . . . are connected to data lines 321, and drive circuits W.sub.11, W.sub.12, . . . W.sub.32 . . . to word lines 323. Read-only gate elements .gamma..sub.11 . . . .gamma..sub.33 . . . are respectively connected to memory elements e.sub.11 . . . e.sub.33 . . . .

With this memory device, data are written into the elements e.sub.11 . . . e.sub.33 . . . in the write mode, and data can be read out from the elements .gamma..sub.11 . . . .gamma..sub.33 . . . in parallel with the elements e.sub.11 . . . e.sub.33 . . . in the read mode. In general, in case of reading out a plurality of sets, that number of .gamma..sub.nm may be connected.

Owing to the hardware arrangement which has the pointer caching register array explained above, processes corresponding to the reduction steps 282 and 288 have greater speed.

When the REG 304 and the STM 303 are applied, improved speed can also be attained by pipeline control.

According to the second embodiment of the present invention, functional or applicative programming languages suited to future parallel processing machines can be efficiently processed by von Neumann type machines which are extensively available at present. This is effective to increase fields where, unlike procedural languages presently forming the mainstream, the functional or applicative programming languages capable of readily developing programs of higher productivity and reliability can be exploited.