Dataflow architectures tolerate long unpredictable com-munication delays and support generation and coordi-nation of parallel activities directly in hardware, rather than assuming that program mapping will cause these issues to disappear. However, the proposed mecha-nisms are complex and introduce new mapping com-plications. This paper presents a greatly simplified ap-proach to dataflow execution, called the explicit token store (ETS) architecture, and its current realization in Monsoon. The essence of dynamic datallow execution is captured by a simple transition on state bits associ-ated with storage local to a processor. Low-level storage management is performed by the compiler in assigning nodes to slots in an activation frame, rather than dy-namically in hardware. The processor is simple, highly pipelined, and quite general. It may be viewed as a generalization of a fairly primitive von Neumann archi-tecture. Although the addressing capability is restric-tive, there is exactly one instruction executed for each action on the dataflow graph. Thus, the machine ori-ented ETS model provides new understanding of the merits and the real cost of direct execution of dataflow graphs. 1

Abstract. Many developments have taken place within dataflow programming languages in the past decade. In particular, there has been a great deal of activity and advancement in the field of dataflow visual programming languages. The motivation for this article is to review the content of these recent developments and how they came

This thesis presents and justifies a framework for programming real-time signal processing systems. The framework extends the existing "block-diagram" programming model; it has three components: a very high-level textual language, a visual language, and the dataflow process network model of computation. The dataflow process network model, although widely-used, lacks a formal description, and I provide a semantics for it. The formal work leads into a new form of actor. Having established the semantics of dataflow processes, the functional language Haskell is layered above this model, providing powerful features---notably polymorphism, higher-order functions, and algebraic program transformation---absent in block-diagram systems. A visual equivalent notation for Haskell, Visual Haskell, ensures that this power does not exclude the "intuitive" appeal of visual interfaces; with some intelligent layout and suggestive icons, a Visual Haskell program can be made to look very like a block dia...

The programmer's most powerful tool for controlling complexity in program design is abstraction. We seek to use abstraction in the design of concurrent programs, so as to separate design decisions concerned with decomposition, communication, synchronization, mapping, granularity, and load balancing. This paper describes programming and compiler techniques intended to facilitate this design strategy. The programming techniques are based on a core programming notation with two important properties: the ability to separate concurrent programming concerns, and extensibility with reusable programmerdefined abstractions. The compiler techniques are based on a simple transformation system together with a set of compilation transformations and portable run-time support. The transformation system allows programmer-defined abstractions to be defined as source- to-source transformations that convert abstractions into the core notation. The same transformation system is used to apply compilation transformations that incrementally transform the core notation toward an abstract concurrent machine. This machine can be implemented on a variety of concurrent architectures using simple run-time support.

: 81/2 is a declarative data-parallel language designed for the simulation of large dynamical systems. Such simulations are of growing importance and they requires more and more computing power. In consequence, 81/2 introduces a new entity, the web, that combines features of collection-oriented and data-flow language to express data-, stream- and control-parallelism. In this paper, we present the language 81/2, some examples of dynamical systems programmed in 81/2 and we describe the compilation process of a 81/2 programme. Key-words: data-parallelism, collection-oriented languages, declarative languages, synchronous data-flow languages, simulation of dynamical systems. I. Introduction Nowadays, simulation of large dynamical systems represents the majority of supercomputers applications. In this article, a dynamical system refers as any application that modelizes space-time phenomena. Three usual examples are: . numerical resolution of partial differential equations [1] describing con...

This paper describes the language 8 1/2 , an embedding of data-parallelism in a declarative framework.

. This paper presents a static dataflow graph model, where only data tokens are allowed to flow. The proposed model is formally described, and the dataflow graph is obtained by employing only actors with homogeneous I/O conditions. Each actor, which executes an elemental operation, is characterized by having one output and two input arcs. Even though no control tokens are allowed, so that no T-gate, merge, and switch actors are present in this model, it is always possible to represent conditional and iterative structures whose behavior is well-behaved. As homogeneous I/O conditions are a severe restriction to represent the flow of a computation and the token flow in such dataflow graphs is completely asynchronous, proof is given to guarantee their determinacy. I. INTRODUCTION The recent developments in VLSI technology and the rapid decrease in hardware costs have raised interest in computing devices for performing computationally intensive tasks. One of the hardware architectures whi...

A High Level Dataflow System. This paper presents a new dataflow graph model, where only data tokens are allowed to flow. First we introduce a High-Level Dataflow System (HLDS) to describe a formal dataflow graph model, then we present a homogeneous HLDS (hHLDS) that formally describes our proposal. In this proposal the dataflow graph is obtained by employing only actors with homogeneous I/O conditions, that is, each actor, which executes an elemental operation, is characterised by having one output and two input arcs. Even though no control tokens are allowed, i.e. no T-gate, merge, and switch actors are present in this model, it is always possible to obtain dataflow graphs, which represent any programming structure and whose behaviour is well-behaved. As homogeneous I/O conditions are a severe restriction to represent the flow of a computation and the token flow in such dataflow graphs is completely asynchronous, proof is given to guarantee their determinacy. The main advantage of th...

Abstract-- The SAM architecture is an enhanced von Neumann processor that contains inexpensive features for supporting data flow style of parallelism. The architecture gets is name from the basic instructions for supporting parallelism, Split and Merge. It is shown that these instructions can be used to implement the parallel structure of an arbitrary acyclic data flow graph. Features for supporting dynamic parallelism and multiple run-time environments are presented. Implementation issues for supporting instruction execution and the handling of faults and interrupts ar also discussed. 1. Introduction. One of the main focuses of current research in computer architecture is the design of hardware organizations that support the parallel execution of instructions (see [1] for several examples.). Data flow parallel architectures continue to receive a great deal of attention [3] [4]. In a data flow architecture an instruction may execute as soon as its operands become available, permiting a degree of parallelism

Parallel programs are more difficult to debug than sequential programs because of their increase in the complexity of interaction. Debugging is complicated both by the properties of multiprocessors in general, and by the specifics of particular multiprocessors, such as their parallelism granularity, interprocessor communication time lags, etc. Additional effort is necessary to assist users both in debugging their code and in helping them to understand it. Previous efforts have focused on either multiprocessor program debugging or program understanding; it is necessary to unify these two tasks. The tasks of program understanding and debugging are similar. By dealing with both tasks through the same program, one can create a flexible program usable both to increase program understanding and debug code. This necessarily would be a event-based tool, operating both during program execution, and during traditional debugging conditions. If successful, this would greatly contribute to increasi...