WATFIV

From Infogalactic: the planetary knowledge core
(Redirected from Paul H. Dirksen)
Jump to: navigation, search

Lua error in package.lua at line 80: module 'strict' not found.

WATFIV, or WATerloo FORTRAN IV, developed at the University of Waterloo, Canada is an implementation of the Fortran computer programming language. It is the successor of WATFOR.

WATFIV was used from the late 1960s into the mid-1980s. WATFIV was in turn succeeded by later versions of WATFOR. Because it could complete the three usual steps ("compile-link-go") in just one pass, the system became popular for teaching students computer programming.

History

In the early 1960s, newly formed computer science departments started university programs to teach computer programming languages. The Fortran language had been developed at IBM, but suffered from slow and error-prone three-stage batch processing workflow.[1] In the first stage, the compiler started with source code and produced object code. In the second stage, a linker constructed a complete program using growing libraries of common functions. Finally, the program was repeatedly executed with data for the typical scientific and business problems of customers. Each step often included a new set of punched cards or tape. Students, on the other hand, had very different requirements. Their programs were generally short, but usually contained errors, resulting in time-consuming repetition of the steps and confusing "core dumps". Once their programs worked correctly, they were turned in and not run again. In 1961, the University of Wisconsin developed a technology called FORGO for the IBM 1620 which combined some of the steps.[2] Similar experiments were carried out at Purdue University on the IBM 7090 in a system called PUFFT.[3]

WATFOR 7040

In summer 1965, four undergraduate students of the University of Waterloo, Gus German, James G. Mitchell[4][5] Richard Shirley and Robert Zarnke, led by Peter Shantz, developed a Fortran compiler for the IBM 7040 computer called WATFOR. Its objectives were fast compilation speed and effective error diagnostics at both compile and execution time.[1] It eliminated the need for a separate linking step and, as a result, FORTRAN programs which contained no syntax errors were placed into immediate execution. Professor J. Wesley Graham (1932–1999) provided leadership throughout the project.[6]

This simple, one-step process allowed non-experienced programmers to learn programming with lower cost in time and computing resources.[7] To aid in debugging, the compiler used an innovative approach to checking for undefined variables (an extremely common mistake by beginning programmers). It used a diagnostic feature of the 7040 that could deliberately set areas of memory to bad parity. When a program tried to reference variables that hadn't been set, the machine took an interrupt (handled by the Watfor runtime routines) and the error was reported to the user as an undefined variable. This had the pleasant side effect of checking for undefined variables with essentially no CPU overhead.

WATFOR quickly gained popularity and over 75 institutions installed it on their IBM 7040 systems. The distribution of the compiler was handled by Sandra Bruce (née Hope).

WATFOR 360

In 1966, the University planned to replace the 7040 with an IBM System/360 computer, which was much faster but not software compatible. A team of full-time employees and undergraduate students was formed to write an IBM 360 version.[8] The project members, Betty Schmidt, Paul Dirksen, Paul H. Cress, Lothar K. "Ned" Kesselhut, Bill Kindree and Dereck Meek, who were later joined by Mike Doyle, Rod Milne, Ron Hurdal and Lynn Williams, completed 360 WATFOR in the early part of 1967. Many other institutions (universities, colleges, businesses and governmental agencies) started using the WATFOR compiler to meet needs similar to those experienced at the University of Waterloo. The distribution of the software and customer support was carried on by Sandra Ward.

WATFIV

As a result of proposals from the SHARE user group Fortran committee and others, a new version called WATFIV was produced in 1968. WATFIV introduced new features such as CHARACTER variables and direct-access input-output. The Association for Computing Machinery presented Paul Cress and Paul Dirksen the Grace Murray Hopper Award for contributions to the WATFOR and WATFIV projects in 1972.[9] The WATFIV compiler was included in the DATAPRO Honour Roll for 1975 and 1976. People involved with maintenance and enhancement included Bernie Murphy, Martin Wiseman and Yvonne Johnson.

WATFIV was pronounced as "WHAT FIVE", but, as was realized at the time, could also (almost) still be pronounced as "WHAT FOR", as in WAT-F-IV (Waterloo Fortran IV).

Universities and corporations used these compilers and a number of other software products have been developed in the WATFOR tradition. For example, a version for the COBOL programming language was called WATBOL.[10][11][12] Daniel D. McCracken said "it is no exaggeration to suggest that WATFOR revolutionized the use of computers in education."[13] At one point, more than 3,000 mini and mainframe computer licenses and over 100,000 microcomputer licenses were held worldwide for this family of software products.

WATFOR-11, -S and -11S

In 1974, a compiler with characteristics similar to the IBM implementation was created for the Digital Equipment Corporation PDP-11 computer and called WATFOR-11. The team members, Jack Schueler, Jim Welch and Terry Wilkinson, were later joined by Ian McPhee who had added new control statements to the WATFIV compiler for structured programming (SP). These new statements included the block IF (later included in the ANSI X3.9-1978 language standard), WHILE, UNTIL, and others. WATFIV-S was announced in 1974 and a few months later, WATFOR-11S (the "S" indicating the new SP features) was also announced. The original SP features were later enhanced with additional statements by Bruce Hay in WATFIV-S in 1980 and by Jack Schueler in WATFOR-11S in 1981.

WATFOR-77

During the 1970s, the ANSI X3J3 subcommittee (the FORTRAN language standard group) developed a new language standard which was officially approved in April, 1978. This standard, designated FORTRAN 77, introduced many new statements into the language. In fact, the previous language standard FORTRAN 66 was a very small document and described, what was in effect, a subset of most implementations of FORTRAN. For example, the WATFIV and WATFOR-11 implementations were based upon the IBM definition of FORTRAN-IV.

As programmers used the FORTRAN 77 features, a new compiler was required to combine the advantages of the WATFIV compiler with the new language standard. In January 1983, a project to develop a FORTRAN 77 compiler was started at Watcom Systems Inc. Under the leadership of Jack Schueler, Watcom employees and undergraduate students from the University of Waterloo's Co-operative Computer Science program became involved in the creation of the WATFOR-77 compiler. The major work was done by Geno Coschi, Fred Crigger, John Dahms, Jim Graham, Jack Schueler, Anthony Scian and Paul Van Oorschot. They were assisted by Rod Cremasco, John McCormick, David McKee and Brian Stecher. Many of the team members from former compiler projects provided input. These included Bruce Hay, Ian McPhee, Sandra Ward, Jim Welch and Terry Wilkinson.

Unlike previous compilers, a significant portion of WATFOR-77 was written in a portable systems language to ease the implementation of the compiler on other computer systems. Earlier WATFOR compilers were written entirely in machine-dependent assembly language.

Two components of the compiler would not be portable. The code generator translated FORTRAN statements into native computer instructions and stored them in memory. The first version of WATFOR-77 generated instructions for the IBM 370 computer architecture. Most of the execution-time support (undefined variable checking, subscript evaluation, intrinsic functions) was written in assembly language for good performance. In September 1984, the first version was installed at the University of Waterloo for the Department of Computing Services. It was an implementation for IBM 370 computers running the VM/SP CMS operating system.

A few months earlier, in May 1984, a project started to implement the WATFOR-77 compiler on the IBM Personal Computer. This project included Geno Coschi, Fred Crigger, Tim Galvin, Athos Kasapi, Jack Schueler, Terry Skomorowski and Brian Stecher. In April 1985, this second version of WATFOR-77 was installed at the University of Waterloo for use by students of the Faculty of Engineering. The compiler could run on a 256K IBM Personal Computer using IBM PC DOS 2.0 and did not require special floating-point hardware.

In the fall of 1985, a Japanese version of WATFOR-77 was delivered to IBM Japan for the IBM JX Personal Computer. This version produced Japanese language error messages and supported the Kanji, Hiragana and Katakana character sets for variable names and character strings. To support the JX, the Language Reference manual and User's Guide were translated into Japanese. Another version of WATFOR-77 with the same features mentioned above was also developed for Japanese IBM PS/55 family of personal computers in Spring 1988.

During the summer of 1986, the IBM PC version of WATFOR-77 was adapted to run on the Unisys ICON which ran the QNX operating system. Since QNX was quite different from IBM PC DOS, parts of the run-time system were rewritten. This implementation of WATFOR-77 was made available in September 1986.

During the summer of 1985, a project was started to adapt WATFOR-77 to the Digital Equipment Corporation VAX computer series running the VMS operating system. The members of this project included Geno Coschi, Marc Ouellette, Jack Schueler and Terry Skomorowski. This implementation was made available in March 1987.

Also, in the spring of 1988, a new project was begun to develop an optimizing FORTRAN 77 compiler. This compiler used the code generator from the Watcom C compiler, which produced superior machine code than other C compilers. The FORTRAN 77 optimizing compiler was first shipped in mid-1990.

In October 1990, the 25th anniversary of WATFOR was celebrated.[14] Many involved in the development of the WATFOR compilers were invited to the University of Waterloo for a reunion.

In spring 1992, a version of WATFOR-77 was adapted to the NEC PC-9801 family of personal computers. This version was similar to the IBM PS/55 version but modified to accommodate architectural differences. In January 1992, development of a 32-bit version of WATFOR-77 for Intel 80386 and Intel 80486 personal computers began. The first version was shipped in the fall of 1992.

As late as 1995, classes for programming in WATFIV were still being held at the University of Mississippi, led by Professor Charles H. (Chuckie) Franke.

See also

References

  1. 1.0 1.1 Lua error in package.lua at line 80: module 'strict' not found.
  2. Lua error in package.lua at line 80: module 'strict' not found.
  3. Lua error in package.lua at line 80: module 'strict' not found.
  4. Lua error in package.lua at line 80: module 'strict' not found.
  5. Lua error in package.lua at line 80: module 'strict' not found.
  6. Lua error in package.lua at line 80: module 'strict' not found.
  7. Lua error in package.lua at line 80: module 'strict' not found.
  8. Lua error in package.lua at line 80: module 'strict' not found.
  9. Lua error in package.lua at line 80: module 'strict' not found.
  10. Lua error in package.lua at line 80: module 'strict' not found.
  11. Lua error in package.lua at line 80: module 'strict' not found.
  12. Lua error in package.lua at line 80: module 'strict' not found.
  13. Lua error in package.lua at line 80: module 'strict' not found.
  14. Lua error in package.lua at line 80: module 'strict' not found.

Further reading

  • Lua error in package.lua at line 80: module 'strict' not found.
  • Lua error in package.lua at line 80: module 'strict' not found.
  • Lua error in package.lua at line 80: module 'strict' not found.
  • Lua error in package.lua at line 80: module 'strict' not found.
  • Lua error in package.lua at line 80: module 'strict' not found.
  • Lua error in package.lua at line 80: module 'strict' not found.

External links