Contact us Heritage collections Image license terms
HOME ACL ACD ICF SUS DCS G&A STARLINK Literature
Further reading □ OverviewProject listBathBelfastCambridgeEast AngliaEdinburghHatfieldKeeleKentLancasterLondon: ImperialLondon: PCLLondon: QMCLondon: UCLLondon: WestfieldLoughboroughManchesterUMISTNewcastleOxfordReadingSheffield City PolyStrathclydeSussexSwanseaWarwickYork
C&A INF CCD CISD Archives Contact us Heritage archives Image license terms

Search

   
ACDDCSProjects
ACDDCSProjects
ACL ACD C&A INF CCD CISD Archives
Further reading

OverviewProject listBathBelfastCambridgeEast AngliaEdinburghHatfieldKeeleKentLancasterLondon: ImperialLondon: PCLLondon: QMCLondon: UCLLondon: WestfieldLoughboroughManchesterUMISTNewcastleOxfordReadingSheffield City PolyStrathclydeSussexSwanseaWarwickYork

DCS Projects: University College of Swansea

J A SHARP

A DATAFLOW PROGRAM DESIGN ENVIRONMENT - ITS IMPLEMENTATION AND USE AS A DESIGN VEHICLE

April 1981 - March 1983

Research Goals

This project aimed to develop a program design environment using a dataflow notation as the basis. Regarding a program as a description of a Problem Solution Environment (PSE), the program design environment is seen as a means of specifying PSEs. The dataflow model supports this in providing descriptive rather than imperative notations which are well suited to serve as PSEs.

Progress Made

An initial naive sequential demand-driven implementation using a tree structure to represent the PSEs demonstrated the feasibility of adapting a dataflow notation for specifying PSEs. Also included was a simple method of representing input and output by infinite functions.

A second implementation takes a set of function definitions and translates them into an intermediate code representation of a Problem Solution Environment. An expression for evaluation (a problem) is then translated into the same intermediate code, and fed into the workspace of one of a number of (simulated) processors (currently up to 10). Parallel evaluation can then be modelled.

The evaluation strategy is again essentially demand driven. In order to evaluate the original expression various other functions from the PSEs are demanded. These functions in turn demand others. A demand for a function to be evaluated results in the definition of that function being placed into a queue of demanded definitions waiting to be evaluated when a process becomes free.

The system is not purely demand-driven since all the expressions which are passed as parameters to a function are demanded when the function is called and are not passed through for the function to demand internally only when required. This method was adopted to increase the potential for parallelism. and to a limited extent avoid the possibility of duplicated evaluation of arguments.

A simple version of this implementation is now working, and some measures on the amount of parallelism achievable in this simple model have been obtained.

⇑ Top of page
© Chilton Computing and UKRI Science and Technology Facilities Council webmaster@chilton-computing.org.uk
Our thanks to UKRI Science and Technology Facilities Council for hosting this site