The Other Manchester Dataflow Project (1977-1980)

My interest in dataflow architectures came from Philip Treleaven then at Manchester and although it was not the path that my supervisor Professor Derrick Morris would have chosen, he gave me a free hand. This I found out later was uncharacteristic for the Professor who was regarded by others as somewhat of a tyrant. Perhaps his adventures with Professor Jeff Rohl on Atlas had an effect. Jeff was my Masters supervisor at UMIST and a fellow Australian.

Others at the time had also been caught up with the prospect of breaking the uniprocessor mold apparently well entrenched at Manchester although a quick study of MU5 the last major machine showed that some at least understood concurrency and asynchronism. At the time there were not too many multiprocessors around. Parallel computing was in an area of dubious research merit as analysis of exisiting scientific applications showed that available concurrency appeared to be between e and Pi. This work was duly published.

My PhD dataflow work however is less well known than the dataflow project project at Manchester (practically invisible if truth be known) which Australians in England at the time could become. This invisibility was exacerbated by the fact that I enjoy the building more than the writing up or publishing. A low priority on publication was not uncommon generally at Manchester then - things change however. I also become much more outspoken as some my older friends would have have noticed.

After completing my PhD I took up a lecturing position and continued my research until the Manchester weather got the better of me as it did also to Jeff Rohl who went to Perth.

Architecture

It was, and is, my belief that dataflow architectures are likely to be best suited to heterogenous concurrency particularly in real-time stimulus response applications. Clearly the re-entrant execution features of most dataflow architectures, including mine, are necessary. The trap however of making architectural decisions, using too small benchmarks pervaded dataflow architecture as much as it did conventional architectures, although we are becoming wiser. Small benchmarks, usually hand written before compilers were available for dataflow machines, forced to much attention on extracting the maximum concurrency from the resulting small dataflow graphs. The availability of compilers and larger more realistic benchmarks then (suprise) saw machines overwhelmed by massive amounts of concurrency. This opened up a new reasearch area of throttling! In amongst this most architectures lost the ability to maintain temporal ordering efficiently.

The early focus of my work was in robotics and AI - this served to keep me focussed on real-time issues and the preservation and, where necessary through unravelling, restoration of temporal ordering within the machine. The use of streams [Dennis/Weng] are part if this.

The very early architectural features of FLO included:

 

Languages

NewSpeak (Pure Lisp)

A pure Lisp compiler called NewSpeak was developed by Sak Wathanasin for AI studies.

Dataflow Language 1 (DL1)

A conventional block structured language, DL1, was developed by Chris Richardson, my research student, for the robotics applications.

Dataflow Emulator

A four processor emulation facility, using Zilog Z80s (the latest thing at the time), was constructed to support the research. An interview with the Professor of Computer Engineering, Di Edwards, was necessary to allow one of Derrick's students to actually build hardware. Derrick had no funds for hardware being the software Prof. I think my answer of "every device" to the question of how much "C" one should put on the boards did the trick!

In what turns out to be continuing trend for my dataflow hardware efforts the printed circuit board facility in the Computer Science Department at Manchester was burnt out preventing completion.

The story is as follows:

The level in one of the Ferric etching tanks was a little low, in fact it was below the thermostatic sensors at the top of the tank. Manchester used to be a cold place before global warming so the tank heaters came on and stayed on as the sensors were in the air not the ferric. After a number of hours the ferric evaporated completely. The very large plastic tank, urged on by the now red hot tank heaters, melted and caught alight. Very fine carbon combustion particles then "took out" the rest of the clean rooms and any prospect of fabricating hardware for the balance of my PhD studies!

I continued with simulation and stayed there for the last three decades although at this date (early 2007) we have a four processor implementation, or should that be 4 dataflow cores, on a single FPGA. The hardware description was written entirely in Handel C.

Surviving components of the original Dataflow Processor Emulator ~1978

Research | G.K. Egan