In recent years, the roles of the four classes of computer participants have become confused and entangled to the detriment of everyone. These four types of participants are: the end user, application programmer, system software designer, and hardware engineer. A watershed was in 1975, when FPS successfully commercialized a wide-instruction word computer, the AP-120B [3]. That computer shifted the burden of raising performance from the hardware engineer to the designers of subroutine libraries that did ``software pipelining.'' It also put a burden on the application programmer, who had to rewrite applications in terms of those library routines. The CRAY-1 [18], introduced in 1977, forced the issue of ``vectorization'' on disgruntled application programmers. Those who accepted the new burden were (sometimes) rewarded with much higher performance, at the price of having to learn a new set of skills, reduced portability, and increased code development time. By about 1982, ``parallel processing'' was beginning to be debated as the unavoidable next advance in computer architecture [2,6,8,10,11].
Parallel processing has been with us for many years.
Computer architectures of the 1950's
had parallel functions (for example, the IBM 7094 [14] fetched data and
instructions in parallel), and even the use of n-bit words implies
parallelism at the finest grain. Yet ``parallel processing''
is treated as a recent revolution in computing. Why?
The difference now is that the application programmer is being asked to recognize parallelism and make use of it, whereas in the past the parallelism had always been the province of the hardware engineer, or beginning in the 1980's, the compiler designer [1,7,9,16,17,20]. As the term is used today, ``parallel processing'' means only that type of parallelism that cannot be disguised from the application programmer. The need for the application programmer to know so much about computer architecture is viewed by some as a major calamity, and the cost of rewriting the serial software in existence is enormous. Even the end user is no longer insulated from changes in computer architecture. In parallel computing environments, users are expected to specify how many processors they need, for example.
A popular school of thought is that we must find ways to exploit parallelism at the application level that are gradual and painless. Others feel that only revolutionary change is the solution and that we must discard old software and start over with some assumption about what ``all'' future computers will have in common. There is no agreement about what that future will be and the result is paralysis.
The debate is often couched in terms of computer languages. Those who oppose all changes at the application level want to lock in existing definitions of languages like C and Fortran. Others look to extensions to languages by compiler directives and new keywords, asking the application programmers and compiler designers to do the ``dirty work.'' The High Performance Fortran (HPF) [13] initiative belongs to this category. Still other want to invent entirely new languages like Sisal or Occam, that can express parallelism or data flow, requiring a complete rewrite of every application.
It is not our intent to offer, in this technical report, a new language definition. We see the choice of computer language as neither the problem nor the solution. The problem lies in the correct assigning of responsibility for tasks among the four participants. Computer languages are inherently ephemeral. Consider Knuth's series The Art of Computer Programming [12]. His ``assembly language'' examples written in MIX are of little value today; however, the English and mathematical examples are still relevant and useful. A combination of English and standard mathematical notation to delineate tasks and responsibilities seems likely to remain readable over many decades of technological change and is the focus of this technical report.