VAL(ID:876/val001)Value-oriented Algorithmic LanguageValue-oriented Algorithmic Language. J.B. Dennis, MIT 1979. Single assignment language, designed for MIT dataflow machine. Based on CLU, has iteration and error handling, lacking in recursion and I/O. Structures: Related languages
References: in [AFIPS] Proceedings of the 1977 AFIPS National Computer Conference Dallas, Texas, June 13-16, 1977 view details in [AFIPS] Proceedings of the 1977 AFIPS National Computer Conference Dallas, Texas, June 13-16, 1977 view details in [AFIPS] Proceedings of the 1977 AFIPS National Computer Conference Dallas, Texas, June 13-16, 1977 view details in [AFIPS] Proceedings of the 1977 AFIPS National Computer Conference Dallas, Texas, June 13-16, 1977 view details in [AFIPS] Proceedings of the 1977 AFIPS National Computer Conference Dallas, Texas, June 13-16, 1977 view details Schemes for pipelined mapping of forall and for-iter array operation constructs in well-behaved VAL programs are formulated Extract: VAL The programming language VAI, [l] is a high level language dcsigncd particularly for expressing algorithms to run on computcrs that are capable of achieving parallel execution, especially those machines based on data flow architecture. VAL is also a functional language which lacks the concepts of storage, or rather, makes them hidden from the programmer. In VAL, variables are trcatcd differently from variblcs in conventional languages. Whcn a variable is declarcd in VAL, it is assigncd a value which it retains for its lifetime. 'his is called the single assignment rule. The basic programming unit in VAL is the hnction. Both thc inputs and the outputs to a function should be explicitly declared. When a hnction is called, arguments are passed to it and a set of one or more values are computed as the result. It is interesting to note that a hnction is guaranteed access to only those argument values, i.e., no global variables are needcd. Furthermore, a function will not change the argument values because VAL is side-effect Free. The body of a function consists of expressions. Usually, these exprcssions arc built using the let-in, if-then-else, forall, tagcase and for-iter constructs of VAL. These expressions are also side-effects free. One important feature of VAL is that it provides implicil concurrency (operations that can be executed independently are evidcnt without the need for any explicit language notation). This allows programmers to focus on the presentation of the algorithm, meanwhile the concurrency can be easily identified by both compiler and reader. This is a very desirable feature, since, in a data flow environment, execution speed depends heavily on a programmer's ability to write programs that contain large amounts of concurrency. It is impractical to ask programmers to specify all concurrency explicitly in the program. The main target of the mapping of VAL programs is the data flow computer. The machine level program in a data flow machine is a data flow graph. The nodes of the graph represent operations; the directed arcs represent data paths. The execution of such a graph is based on the firing rule. An operator is enabled as soon as all its input values are present. The execution (firing) of an operator will consume input values and put output values on each of its output arcs. Figure 1.1 shows a data flow graph representation of a VAL function which computes the sum of squares of two values. There are many interesting features in the VAL language. This thesis concentrates on the implemcnbtion of array operations in VAL language. To be more specific, among the may operations in a VAL programs. we are only interested in those which can be expressed by forall and for-itcr constructs. Extract: The aim of this thesis The aim of this thesis has been to study the problem of mapping array operations in the high level language VAL on a static data flow machine. The main interest is producing pipelined data flow machine codes which can run with maximum throughput. Since data driven instruction execution is radically different from its conventional counterpart, new models and schemes for its translation should be investigated and developed. The main contributions and accomplishments of this thesis are : (1) The specification of a class of VAL program, i.e. well-behaved VAL programs, for which both a good model and efficient schemes exist to map the array operations into fully pipelined machine codes on a static data flow architecture. (2) 'The development of flow dependency graph model (FDG model) for the class of well-behaved VAL programs. A polynomial time algorithm is presented for balancing a general acyclic FDG to achieve maximum pipelining. The issue of reducing the buffering in a balanced FIX is addressed. An algorithm for reducing the buffering based on equivalent transformation of balanced FDG is formulated. Although no general algorithm is known for optimization of a balanced FDG, a class of FDG (well-structured FDG) is defined for which a polynomial time algorithm exists for its optimization. (3) The establishment of mapping schemes for well-behaved forall and for-iter array operation constructs. In particular, a new scheme for mapping for-iter constructs to achieve maximum pipelining is proposed. This is based on the concepts of companion function for a recurrence function. The construction of FIFO buffer on a static data flow machine is also discussed which is crucial for efficient implementation of above mapping schemes. in [AFIPS] Proceedings of the 1977 AFIPS National Computer Conference Dallas, Texas, June 13-16, 1977 view details in TOPLAS 4(1) January 1982 view details in TOPLAS 4(2) April 1982 view details VAL is an expression oriented language based on CLU [60] . Iteration is viewed as a simple kind of recursion. There are two FORALL constructs. The first generates an array of results, one element per iteration. The second combines the results. There are modules that manipulate streams of data. in TOPLAS 4(2) April 1982 view details in TOPLAS 4(2) April 1982 view details The major group in America is that led by Jack Dennis at MIT, and many of the other groups in the USA have used the MIT work as a basis. Jack Dennis's group are currently partially funded by the Lawrence Livermore Laboratory, and have built a simple version of their data flow machine. [Dataflow] Work is also in progress in the field of programming language design [Val], and in application areas. Kosinski has also worked at MIT looking into the formal semantics of data flow programming languages [DFPL] Extract: Id languages Another large data flow research project in America was the one at the University of California at Irvine [Id]. They originally took Dennis?s graphical notation as a base language, and designed a high-level language which could be compiled into the MIT notation. Since then they have made many changes to the base language - adding and deleting features to fit more closely the view of data flow that they developed - so that it is now significantly different to Dennis's. Various designs for machine architectures have been produced, and work has been done on simulating them. As far as I am aware there is as yet no intention to build an actual machine. Around 1980 both the main researchers, Arvind and Gostelow, left Irvine, but the project is continuing on a smaller scale with Lubomir Bic being the main faculty member involved. Arvind moved to MIT, and is pursuing his research separately from Jack Dennis there, though obviously there is some interaction between the groups. A report on Arvind's ideas for a data flow computer was given in a paper by Arvind and Kathail in 1981. in TOPLAS 4(2) April 1982 view details in Annals of the History of Computing 16(4) Winter 1994 view details James R. McGraw, "The VAL language: description and analysis", ACM TOPLAS, 4, #1, pp. 44-82. Jan. 1982, VAL is a side effect free language, based on expressions and non-recursive functions. Normally the language is single-definition, but in a fairly complex for...do...iter construct redefinition is allowed to handle iteration. Its main features are explained using a single example, quad integration. in Annals of the History of Computing 16(4) Winter 1994 view details VAL VAL was developed by Dennis starting in 1979 [Ackerman and Dennis 1979; Dennis 1977], and obeyed the single-assignment rule. A program in VAL consisted of a series of functions, each of which could return multiple values. Loops were provided by the Lucid technique [Ashcroft and Wadge 1977], and a parallel assignment construct, for all, was also provided. However, recursion was not provided as it was not thought necessary for the target domain. Other disadvantages [Whiting and Pascoe 1994] included the lack of general I/O and the fact that nondeterministic programs could not be expressed. Extract: Introduction Introduction The original motivation for research into dataflow was the exploitation of massive parallelism. Therefore, much work was done to develop ways to program parallel processors. However, one school of thought held that conventional "von Neumann" processors were inherently unsuitable for the exploitation of parallelism [Dennis and Misunas 1975; Weng 1975]. The two major criticisms that were leveled at von Neumann hardware were directed at its global program counter and global updatable memory [Silc et al. 1998], both of which had become bottlenecks [Ackerman 1982; Backus 1978]. The alternative proposal was the dataflow architecture [Davis 1978; Dennis and Misunas 1975; Weng 1975], which avoids both of these bottlenecks by using only local memory and by executing instructions as soon as their operands become available. The name dataflow comes from the conceptual notion that a program in a dataflow computer is a directed graph and that data flows between instructions, along its arcs [Arvind and Culler 1986; Davis and Keller 1982; Dennis 1974; Dennis and Misunas 1975]. Dataflow hardware architectures looked promising [Arvind and Culler 1986; Dennis 1980; Treleaven and Lima 1984; Veen 1986], and a number of physical implementations were constructed and studied (for examples, see Davis [1978], Keller [1985], Papadopoulos [1988], Sakai et al. [1989], and Treleaven et al. [1982]). Faced with hardware advances, researchers found problems in compiling conventional imperative programming languages to run on dataflow hardware, particularly those associated with side effects and locality [Ackerman 1982; Arvind et al. 1977; Arvind and Culler 1986; Kosinski 1973; Wail and Abramson 1995; Weng 1975; Whiting and Pascoe 1994]. They found that by restricting certain aspects of these languages, such as assignments, they could create languages [Ackerman 1982; Ashcroft and Wadge 1977; Dennis 1974; Hankin and Glaser 1981; Kosinski 1978] that more naturally fitted the dataflow architecture and could thus run much more efficiently on it. These are the so-called dataflow programming languages [Ackerman 1982; Whiting and Pascoe 1994] that developed distinct properties and programming styles as a consequence of the fact that they were compiled into dataflow graphs-the "machine language" of dataflow computers. The often-expressed view in the 1970s and early 1980s that this form of dataflow architecture would take over from von Neumann concepts [Arvind et al. 1977; Treleaven et al. 1982; Treleaven and Lima 1984] never materialized [Veen 1986]. It was realized that the parallelism used in dataflow architectures operated at too fine a grain and that better performance could be obtained through hybrid von Neumann dataflow architectures. Many of these architectures [Bic 1990] took advantage of more coarse-grained parallelism where a number of dataflow instructions were grouped and executed in sequence. These sets of instructions are, nevertheless, executed under the rules of the dataflow execution model and thus retain all the benefits of that approach. Most dataflow architecture efforts being pursued today are a form of hybrid [Iannucci 1988; Nikhil and Arvind 1989], although not all, for example, Verdoscia andVaccaro [1998]. The 1990s saw a growth in the field of dataflow visual programming languages (DFVPLs) [Auguston and Delgado 1997; Baroth and Hartsough 1995; Bernini and Mosconi 1994; Ghittori et al. 1998; Green and Petre 1996; Harvey and Morris 1993, 1996; Hils 1992; Iwata and Terada 1995; Morrison 1994; Mosconi and Porta 2000; Serot et al. 1995; Shizuki et al. 2000; Shurr 1997; Whiting and Pascoe 1994; Whitley 1997]. Some of these, such as LabView and Prograph were primarily driven by industry, and the former has become a successful commercial product that is still used today. Other languages, such as NL [Harvey and Morris 1996], were created for research. All have software engineering as their primary motivation, whereas dataflow programming was traditionally concerned with the exploitation of parallelism. The latter remains an important consideration, but many DFVPLs are no longer primarily concerned with it. Experience has shown that many key advantages of DFVPLs lie with the software development lifecycle [Baroth and Hartsough 1995]. This article traces the development of dataflow programming through to the present. It begins with a discussion of the dataflow execution model, including a brief overview of dataflow hardware. Insofar as this research led to the development of dataflow programming languages, a brief historical analysis of these is presented. The features that define traditional, textual dataflow languages are discussed, along with examples of languages in this category. The more recent trend toward large-grained dataflow is presented next. Developments in the field of dataflow programming languages in the 1990s are then discussed, with an emphasis on DFVPLs. As the environment is key to the success of a DFVPL, a discussion of the issues involved in development environments is also presented, after which four examples of open issues in dataflow programming are presented. Extract: Early Dataflow Programming Languages 3. Early Dataflow Programming Languages 3.1. The Development of Dataflow Languages With the development of dataflow hardware came the equally challenging problem of how to program these machines. Because they were scheduled by data dependencies, it was clear that the programming language must expose these dependencies. However, the data dependencies in each class of language can be exploited to different degrees, and the amount of parallelism that can be implicitly or explicitly specified also differs. Therefore, the search began for a suitable paradigm to program dataflow computers and a suitable compiler to generate the graphs [Arvind et al. 1988]. Various paradigms were tried, including imperative, logical, and functional methods. Eventually, the majority consensus settled on a specific type of functional language that became known as dataflow languages. An important clarification must be made at this stage. In early publications, dataflow graphs are often used to illustrate programs. In many cases, these graphs are simply representations of the compiled code [Dennis and Misunas 1975] that would be executed on the machine, where the graph was generated either by hand or by a compiler from a third-generation programming language. Until the advent of Dataflow Visual Programming Languages in the 1980s and 1990s, it was rarely the intention of researchers that developers should generate these graphs directly. Therefore these early graphs are not to be thought of as "dataflow programming languages." 3.1.1. What Constitutes a Dataflow Programming Language ?. While dataflow programs can be expressed graphically, most of the languages designed to operate on dataflow machines were not graphical. There are two reasons for this. First, at the low level of detail that early dataflow machines required, it became tedious to graphically specify constructs such as loops and data structures which could be expressed more simply in textual languages [Whiting and Pascoe 1994]. Second, and perhaps more importantly, the hardware for displaying graphics was not available until relatively recently, stifling any attempts to develop graphical dataflow systems. Therefore, traditional dataflow languages are primarily text-based. One of the problems in defining exactly what constitutes a dataflow language is that there is an overlap with other classes of language. For example, the use of dataflow programming languages is not limited to dataflow machines. In the same way, some languages, not designed specifically for dataflow, have subsequently been found to be quite effective for this use (e.g., Ashcroft and Wadge [1977]; Wadge and Ashcroft [1985]). Therefore, the boundary for what constitutes a dataflow language is somewhat blurred. Nevertheless, there are some core features that would appear to be essential to any dataflow language. The best list of features that constitute a dataflow language was put forward by Ackerman [1982] and reiterated by Whiting and Pascoe [1994] and Wail and Abramson [1995]. This list includes the following: (1) freedom from side effects, (2) locality of effect, (3) data dependencies equivalent to scheduling, (4) single assignment of variables, (5) an unusual notation for iterations due to features 1 and 4, (6) lack of history sensitivity in procedures. Because scheduling is determined from data dependencies, it is important that the value of variables do not change between their definition and their use. The only way to guarantee this is to disallow the reassignment of variables once their value has been assigned. Therefore, variables in dataflow languages almost universally obey the single-assignment rule. This means that they can be regarded as values, rather than variables, which gives them a strong flavor of functional programming. The implication of the single-assignment rule is that the compiler can represent each value as one or more arcs in the resultant dataflow graph, going from the instruction that assigns the value to each instruction that uses that value. An important consequence of the single-assignment rule is that the order of statements in a dataflow language is not important. Provided there are no circular references, the definitions of each value, or variable, can be placed in any order in the program. The order of statements becomes important only when a loop is being defined. In dataflow languages, loops are usually provided with an imperative syntax, but the single-assignment rule is preserved by using a keyword such as next to define the value of the variable on the next iteration [Ashcroft and Wadge 1977]. A few dataflow languages offer recursion instead of loops [Weng 1975]. Freedom from side effects is also essential if data dependencies are to determine scheduling. Most languages that avoid side effects do so by disallowing global variables and introducing scope rules. However, in order to ensure the validity of data dependencies, a dataflow program does not even permit a function to modify its own parameters. All of this can be avoided by the single-assignment rule. However, problems arise with this strategy when data structures are being dealt with. For example, how can an array be manipulated if only one assignment can ever be made to it? Theoretically, this problem is dealt with by conceptually viewing each modification of an array as the creation of a new copy of the array, with the given element modified. This issue is dealt with in more detail in Section 6.3. It is clear from the above discussion that dataflow languages are almost invariably functional. They have applicative semantics, are free from side effects, are determinate in most cases, and lack history sensitivity. This does not mean that dataflow and functional languages are equivalent. It is possible to write certain convoluted programs in the functional language Lucid [Ashcroft and Wadge 1977], which cannot be implemented as a dataflow graph [Ashcroft and Wadge 1980]. At the same time, much of the syntax of dataflow languages, such as loops, has been borrowed from imperative languages. Thus it seems that dataflow languages are essentially functional languages with an imperative syntax [Wail and Abramson 1995]. 3.1.2. Dataflow Languages. A number of textual dataflow languages, or functional languages that can be used with dataflow, have been implemented. A representative sample is discussed below. (Whiting and Pascoe [1994] presented a fuller review of these languages.) Dataflow Visual Programming Languages are discussed in detail in Section 5. in Annals of the History of Computing 16(4) Winter 1994 view details |