DavisA . L., and Keller R. M. Dataflow program graphs.IEEE Computer15, 2 (1982), 26-41.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....of Timed CTL (TCTL) properties [3] using a transformation of PRES into Timed Automata. Models constructed at different levels of abstraction are possible by means of hierarchy [27] 2.1. 2 MDC models The modelling of transformational embedded systems has been primarily based on data flow graphs [28], since its suitability for scheduling. This model consists of a directed graph G = V , E) where nodes V = n 1 , n 2 , nN ,N V represent computations and the arcs E describe the data dependency between operations, hence the processing order. FGM The Flow Graph Model (FGM) ....

A. L. Davis and R. M. Keller. Data Flow Program Graphs. IEEE Computer, 15(2), February 1982.

....for program optimisation and program transformations (e.g. vectorisation) that require interaction of different dependence types. Dataflow graphs, from which the PDG notation is extended by adding control arcs, have long been used to exploit parallelism independent of computer architectures [22, 23]. A dependence graph, like a Dataflow graph, exposes potential parallelism. A visual program dependence graph (VPDG) 24] an extension of a program dependence graph (PDG) supports both code transformations when parallelising programs and mapping when visualising the code. Common features of ....

A. L. Davis & R. M. Keller (1982) Data flow program graphs. IEEE Computer 15, 26}41.

....systems result in dataflow program graphs that are not reentrant. This constraint affects both iteration and function (subroutine) calling mechanisms. Automatic run time loop unravelling is not supported by static dataflow systems. Functions can be made reentrant by either code duplication [4] or code sharing mechanisms[5] In dynamic dataflow architectures, dataflow program graphs are also represented as a collection of multiply linked activity templates. In this case, activity templates consist of i) an operation code and ii) a (destination) pointer list. No space is reserved in the ....

A. L. Davis and R. M. Keller, "Data Flow Program Graphs," Computer, Vol. 15, No. 2, Feb. 1982. pp. 26-41,

.... addressed by this group can be found in [31] which its by itself an extension of [33] Specifications are given in HardwareC [41] a HDL developed in Stanford University by late 80s, and then compiled into a sequencing graph model (SGM) 35] a graph representation based on flow graphs [19], using the program Hercules [42] The system behaviour is represented by a set of acyclic sequencing graphs (# = G 1 , G 2 , G n ) timing constraints (T) and resource constraints (R) Each of this G i is a iterative construct in a HDL. The partitioning algorithm [34] starts with a ....

A. L. Davis and R. M. Keller. Data Flow Program Graphs. IEEE Computer, 15(2), Feb. 1982.

....by the first author. The basic idea behind this approach is to perform strictness analysis using an abstract form of demand propagation. Intuitively, abstract demand propagation can be seen as a compile time abstraction of the demand driven evaluation process associated with lazy evaluation [DK82]. Although some forms of compile time demand propagation have been used before to implement lazy languages [Lin86, Pin86, Hal87, SPR90] our approach is novel in a number of ways. First of all, the notions of demands and demand propagation are given a formal interpretation through the definition ....

A.L. Davis and R.M. Keller. Data flow program graphs. IEEE Computer, 15(2):26--41, Feb. 1982.

....efficient environment that enables scientists to create new simulations and scenarios, to develop new algorithms, and to couple existing algorithms with powerful visualization tools. SCIRun combines several different computer science concepts to achieve this flexibility and efficiency. A dataflow [27] visual programming model is combined with concepts from object oriented programming to achieve modularity by insulating data representations from dataflow modules. This combination also provides a mechanism for implementing demand driven dataflow (lazy evaluation) 120] in a straightforward ....

....is not required to gather data from the inputs in order, and it may interleave computation with receiving data. However, to satisfy the requirements for determinacy in a dataflow program, the module is not able to request datasets in a first come, first served or any other nondeterministic order [27, 63]. It is important to note that modules do not send actual data, but rather a handle to the data (see 6.3.2 for a discussion of handles) Sending a dataset to the matrix out port is just a few lines of code, similar to: MatrixHandle matrix = new DenseMatrix(nrows, ncols) build the matrix . ....

[Article contains additional citation context not shown here]

DAVIS, A., AND KELLER, R. Data flow program graphs. Computer (February 1982), 26--41.

....has little or no involvement in the parallelisation process. It is completely managed by the underlying system components (compiler, run time system and hardware) We think that the data ow model of computation is at the top of this category. Here, programs are represented by a directed graph [51]. The nodes represent machine instructions and the arcs connecting nodes represent the ow of data between the nodes. When all data is available on the arcs of a node, the node executes the instruction or res and places the result on its output arc. As several nodes can re simultaneously, the ....

A. Davis and R. Keller. Data Flow Program Graphs. IEEE Computer, pages 26-41, February 1982.

....node input timing problems are handled. 2 The GTO Dataflow Node Set Dataflow programming is a functional programming methodology. In its most basic form, a dataflow program is represented as a dataflow graph: a directed graph whose nodes are operators and whose arcs carry data from node to node. [3, 4] The arcs carry data from the source node s output port to the destination node s input port. 1 Multitransputer use is not currently supported. 1 name.b8h Transputer name.occ Occam Code Dataflow Graph DIVA source name.gto GTO code gto diva by hand occam Figure 1: System Overview ....

Alan L. Davis and Robert M. Keller, "Data Flow Program Graphs," Computer, February 1982, pp. 26-41.

.... Most of these applications are written today in conventional procedural languages and there is no trend to write them in nonconventional ones (like logical, applicative or data flow languages) that might provide better opportunities for parallel execution, as is believed by some researchers [2, 3, 4]. Streams have been studied extensively, and code written with streams was shown to have the following good qualities: 1 ffl Designing and programming by means of flow of data: the stream enhances the transformation, even automatic one, from clear design as a set of individual modules connected ....

.... simulate a change of state without using assignments [8] hence it may be used in applicative and single assignment languages where multiple assignments are not allowed [7] Thus streams were introduced to many languages Prolog [6, 7] lisp [8, 10] functional programming [2] data flow languages [3, 4] APL and even in unix. There are even languages like Lucid [5] whose main data structure is the stream. The only experiment with introducing streams to a conventional language was done in [9] This paper shows that introducing streams in languages can achieve parallel executions of programs ....

A. L. Davis, R. M. Keller. Data Flow Program Graphs. comp. IEEE, vol 15, feb. 1982. pp 26-41.

....strict constraints on periodicity, the Synchronous Data Flow graph offers a powerful model for static analysis and simplified implementation. Data Flow graphs [1] 7] are often used in signal processing to model real time applications because they offer an intuitive and visually oriented approach [6]. SDF is a variant of the traditional Data Flow graph; the amount of data consumed and produced by each node for all its inputs and outputs, is fixed in advance. 2.1 The SDF model In the SDF model, a signal processing application is described in terms of static transfers and operations. The ....

A.L. Davis and R.M. Keller. Data flow program graphs. Computer, 15(15):26--47, February 1982.

....be spaghetti like . Many algorithms are conveniently described as data flow graphs; this holds especially in the case of digital signal processing algorithms [78] which are typical embedded computer system specifications. An essential advantage of data flow graphs is their natural composability [24]: a given subgraph, such as shown in Fig. 1, can be defined to be the implementation of a new compound block, such as shown in Fig. 2, which is then ready to be used exactly in the same way as the old predefined blocks. This composition straightforwardly carries over to hardware realizations: both ....

A. L. Davis and R. M. Keller. Data flow program graphs. IEEE Computer, vol. 15, no. 2, pp. 26--41. February 1982. -- 94 --

....of embedded systems. While considerable progress has been made in data oriented optimizations, control optimization has been fairly limited to those carried out by compilers at the register transfer level. In the past, variants of data flow graphs (DFGs) and control data flow graphs (CDFGs) [15, 16, 17, 18, 19, 20, 21] have been used for hardware synthesis and program compilation tasks. Most DFG based representations are quite efficient in implementing data oriented transformations, but the modeling of control flow is inadequate. In most CDFG models, control flow is often embedded in the modeling hierarchy that ....

A. L. Davis and R. M. Keller, "Data flow program graphs," IEEE Computer, vol. 15, no. 2, February 1982.

....the traditional data flow graph [1] 8] where the amount of data consumed and produced by each node for all its inputs and outputs, is fixed in advance. Data flow graphs are often used in signal processing to model real time applications, because they offer an intuitive, visually oriented approach [7]. An application expressed as an SDF graph has a priori been decomposed into manageable sub problems, each performing a distinct operation; at the same time, the unity of an operation or of a block of data is preserved. This provides modularity and the possibility Inria A Component Model for ....

A.L. Davis and R.M. Keller. Data flow program graphs. Computer, 15(15):26--47, February 1982.

....icon. The User Interface Builder may subsequently be invoked to specify the window s size, position, text font, and so on. Of the two remaining subsystems shown in Figure 1, the first deals with arithmetic and logic (boolean) expressions, and for this wehaveadopteda visual dataflowapproach [13, 18]. Dataflow diagrams appear to offer a simpleand easily visualised notationfor novice programmers [2] Note that, although it is possible to write complete programs in a data flow fashion, we chose to retain the more usual procedural control flow for the main program. The step by step instructional ....

DAVIS, A. L., AND KELLER, R. M. Data Flow Program Graphs. IEEE Computer (Feb. 1982), 26--41.

....Techniques This section gives a brief introduction to the concept of dataflow computing. Since it is not of direct relevance to this thesis, it is merely meant to serve as a pointer to further reading. In the dataflow model of parallel computation, a program is represented by a directed graph [DK82] in which the nodes represent instructions and the arcs represent the paths of the data tokens. A node executes the instruction (or fires) when data becomes available on all of its input arcs and places the result on Chapter 2 Related Work 17 its output arc. Several nodes can fire ....

Alan L Davis and Robert M Keller. Data flow program graphs. IEEE Computer, pages 26--41, February 1982.

....(locally controlled by their operand availability) and thus these actors represent many asynchronous concurrent computation events. Work on dataflow computer architecture emerged in the early 1970s with the use of dataflow program graphs to represent and exploit the parallelism in programs [25, 27]. In a Dennis dataflow graph [27] operations are specified by actors that are enabled just when all actors that produce required data have completed their execution. The dependence relationships between pairs of actors are defined by the arcs of a graph, which maybe thought of as conveying ....

A. L. Davis and R. M. Keller. Data flow program graphs. Computer, 15(2):26--41, Feb. 1982.

....a node becomes active whenever tokens are present on its input arcs and tokens may be produced on its output arcs. When this occurs, input tokens are consumed, function result(s) are computed and produced on the output arc(s) Advantages provided by this representation have already been discussed [5][6] First, it enables exploiting the inherent concurrency in the algorithm without requiring the programmer to make it explicit. As a result, all parallel operations may be executed concurrently. Second, the lack of hidden dependencies between operators yields to a cleaner algorithm ....

A.L. Davis, S.A. Keller, Data-Flow Program Graph, IEEE Computer, Feb 1982, pp 26-40.

....the Compute button on any quantity node to compute its value. SIGMA s graphical user interface will graphically simulate execution of the data flow diagram to help the user visualize the computation. Basic execution is relatively straightforward, and is typical of data flow execution schemes (Davis Keller, 1982). To compute a given quantity, the system executes each transform in the data flow subgraph rooted at the quantity node. Execution proceeds in order from the fringe of the subgraph back to the root. Before a transform can be executed, all its inputs must be computed. The execution sequencing is ....

A. L. Davis, and R. M. Keller (1982). Data Flow Program Graphs. IEEE Computer(February), 26-41.

No context found.

DavisA . L., and Keller R. M. Dataflow program graphs.IEEE Computer15, 2 (1982), 26-41.

No context found.

Davis, A. L., and Keller, R. M. Data Flow Program Graphs. Computer (February 1982), 26--41.

No context found.

A. L. Davis, and R. M. Keller, "Data Flow Program Graphs," Computer , pp. 26--41, February 1982.

No context found.

Davis, A. l., Keller, R. M., "Data Flow Program Graphs", Computer, 15, 2, pp. 2641, February 1982.

No context found.

A. L. Davis and R. M. Keller, `Data flow program graphs', IEEE Computer, 15, (2), (1982).

No context found.

DAVIS82 Davis, A. L., Keller, R. M., Data Flow Program Graphs, IEEE Computer, Vol. 15, No. 2, February 1982.

No context found.

DAVIS82 Davis, A. L., Keller, R. M., Data Flow Program Graphs, IEEE Computer, Vol. 15, No. 2, February 1982.

First 50 documents

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC