09_10_Pascal_News_Sep77 09 10 Pascal News Sep77

09_10_Pascal_News_Sep77 09_10_Pascal_News_Sep77

User Manual: 09_10_Pascal_News_Sep77

Open the PDF directly: View PDF .
Page Count: 114

Download
Open PDF In Browser	View PDF

PASCAL USER'S GROUP

PascalNews
(FORMERLY PASCAL NEWSLETTER)
NUMBERS

9 AND 10 (COMBINED ISSUE)

COMMUNICATIONS ABOUT THE PROGRAMMING LANGUAGE PASCAL BY PASCALERS
SEPTEMBER"

1977

TAB LEO F CON TEN T S

o
1
3
4
4
8
8
11
11
12
39
39
40
42
43
47
54
58
60
60
60
61
61
63
64
73
113

POLICY: Pascal News
ALL PURPOSE COUPON
EDITOR'S CONTRIBUTION
HERE AND THERE
News
Conferences
Books and Articles
Past Issues of Pascal Newsletter
PUG Finances
Roster
ARTICLES
"Pascal at Sydney University"
- A. J. Gerber and C. C. Morgan
"Disposing of Dispose"
- Stephen P. Wagstaff
"What is a Textfile?"
- William C. Price
"Generic Routines and Variable Types in Pascal"
- B. Austermuehl and H.-J. Hoffmann
OPEN FORUM FOR MEMBERS
Special Topic: Micro/Personal Computers and Pascal
Special Topic: Pascal Standards
IMPLEMENTATION NOTES
Checklist
General Information
Software Writing Tools
Portable Pascals
Pascal Variants
Feature Implementation Notes
Machine Dependent Implementations
POLICY: Pascal User's Group

POLICY:

PASCAL NEWS

(77109/01)

* Pascal News is the official but informal publication of the User's Group.
Pascal News contains all we (the editors) know about Pascal; we use it as
the vehicle to answer all inquiries because our physical energy and
resources for answering individual requests are finite. As PUG grows, we
unfortunately succumb to the reality of (1) having to insist that people
who need to know "about Pascal" join PUG and read Pascal News - that is
why we spend time to produce it! and (2) refusing to return phone calls
or answer letters full of questions - we will pass the questions on to
the readership of Pascal News. Please understand what the collective
effect of individual inquiries has at the "concentrators" (our phones and
mailboxes). We are trying honestly to say: "we cannot promise more than
we can do."

* An attempt is made to produce Pascal News 4 times during an academic year from
July 1 to June 30; usually September, November, February, and May.

~

u
.-

-c.o

*

ALL THE NEWS THAT FITS, WE PRINT. Please send written material for Pascal News
single spaced and in camera-ready form. Use lines 18.5 cm wide!

*

Remember: ALL LETTERS TO US WILL BE PRINTED UNLESS THEY CONTAIN A REQUEST TO
THE CONTRARY.

*

Pasc&l News is divided into flexible sections:
POLICY - tries to explain the way we do things (ALL PURPOSE COUPON, etc.).
EDITOR'S CONTRIBUTION - passes along the opinion and point of view of the
editor together with changes in the mechanics of PUG operation, etc.
HERE AND THERE WITH PASCAL - presents news from people, conference
announcements and reports, new books and articles (including reviews),
notices of Pascal applications, history, membership rosters, etc.
ARTICLES - contains formal, submitted contributions (such as Pascal
philosophy, use of Pascal as a teaching tool, use of Pascal at different
computer installations, how to promote Pascal, etc.
OPEN FORUM FOR MEMBERS - contains short, informal correspondence among
members which is of interest to the readership of Pascal News.
IMPLEMENTATION NOTES - reports news of Pascal implementations: contacts
for maintainers, implementors, distributors, and documentors of various
implementations as well as where to send bug reports. Qualitative and
quantitative descriptions and comparisons of various implementations are
publicized. Sections contain information about Software Writing Tools
for a Pascal environment, Portable Pascals, Pascal Variants, Feature
Implementation Notes, Machine Dependent Implementations, etc.

* Volunteer editors are:
Andy Mickel - editor
Tim Bonham and Jim Miner - Implementation Notes editors
Sara Graffunder - Here and There editor
John Strait and John Easton - Tasks editors
David Barron and Rich Stevens - Books and Articles editors
Rich Cichelli - Software Tools and Applications editor
George Richmond - past editor (issues 1 through 4)

ALL PURPOSE COUPON

USER'S

******************

GROUP

(77109/01) •
Pascal User's Group, c/o Andy Mickel
University Computer Center: 227 EX
208 SE Union Street
University of Minnesota
Minneapolis, MN 55455 USA

+

Clip, photoQopy,

+
+
+

~eplLOdu.Qe,

m.

O~

a.nd

/ / Please enter me as a new member of the PASCAL USER'S GROUP for
Academic
year{s) ending June 30
I shall receive all 4 issues of P~ca.l N~
for each year. Enclosed please find
($4.00 for each year). (* When
joining from overseas, check the P~Qal N~ POLICY section on the reverse
side for a PUG "regional representative." *)
/ / Please renew my membership in PASCAL USER'S GROUP for ____ Academic year{s)
ending June 30
Enclosed please find
($4.00 for each year).
/ / Please send a copy of P~Qal N~ Number{s)
• (* See the P~eal
POLICY section on the reverse side for prices and issues available. *)
/ / My new a~~~~~s is printed below. Please use it from now on.
old mailing label if I can find one.
address
/ / You messed up my phone. See below.

N~

I'll enclose an

/ / Enclosed please find a contribution (such as what we are doing with Pascal at
our computer installation), idea, article, or opinion which I wish to submit
for publication in the next issue of P~Qal N~. (* Please send bug reports
to the maintainer of the appropriate implementation listed in the Pa.oca.l N~
IMPLEMENTATION NOTES section. *)
/ / None of the above.

Other comments:

From:

name _ _ _ _ _ _ _ _ _ _ _ _ __

mailing address _ _ _ _ _ _ _ _ _ _ _ _ __

phone _ _ _ _ _ _ _ _ _ _ _ _ __
computer system( s) _ _--'--_ _ _ _ _ _ _ _ _ _-:date _ _ _ _ _ _ _ _ _ _ _--,-__
(* Your phone number aids communication with other PUG members. *)

JOINING PASCAL USER'S GROUP?
- membership is open to anyone: particularly the Pascal user, teacher, maintainer,
implementor, distributor, or just plain fan. Memberships from libraries are also
encouraged.
please enclose the proper prepayment - we will not bill you.
please do not send us purchase orders - we cannot endure the paper work! (if you are
trying to get your organization to pay for your membership, think of the cost of
paperwork involved for such a small sum as a PUG membership).
when you join PUG anytime within an academic year: July 1 to June 30, you will
receive all issues of Pascal News for that year unless you request otherwise.
You will receive a membership receipt.
please remember that PUG is run by volunteers who don't consider themselves in the
"publishing business. " We consider production of Pascal News as simply a means
toward the end of promoting Pascal and communicating news of events surrounding
Pascal to persons interested in Pascal. We are simply interested in the news
ourselves and prefer to share it through Pascal News (rather than having to
answer individaally every letter and phone call). We desire to keep paperwork
to a minimum because we have other work to do.
JOINING THROUGH "REGIONAL REPRESENTATIVES" ?
- anyone can join through PUG(USA) - address on reverse side. International telephone:
1-612-376-7290. PUG(USA) produces Pascal News and keeps all mailing addresses on
a common list. Regional representatives collect memberships as a service and
reprint and distribute Pascal News using mailing labels sent from PUG(USA) which
speeds up delivery overseas.
Australasian Region (Australia, New
European Region (Europe, North Africa,
Zealand, Indonesia, Malaysia):
Middle and Near East):
send $AI0 to: Pascal Users Group (AUS)
send £2.50 to: Pascal Users Group (UK)
c/o Arthur Sale
c/o Computer Studies Group
Dept. of Information Science
Mathematics Department
University of Tasmania
The University
GPO Box 252C
Southampton S09 5NH
Hobart, Tasmania 7001
United Kingdom
Australia
telephone: 44-703-559122 x700
telephone: 23 0561
l

RENEWING?
- please renew early (before August) and please write us a line or two to tell us what
you are doing with Pascal, and tell us what you think of PUG and Pascal News to
help keep us honest. To save PUG postage, we do not send receipts when you renew.
ORDERING BACKISSUES OR EXTRA ISSUES?
Our unusual policy of automatically sending all issues of Pascal News to anyone
who joins within an academic year (July 1 to June 30) means that we eliminate many
requests for backissues ahead of time, and we don't have to reprint important information
in every issue - especially about Pascal implementations!
- Issues 1, 2, 3, and 4 (January, 1974 - August, 1976) are out of print.
- Issues 5, 6, 7, and 8 (September, 1976 - May, 1977):
Less than 40 copies each remain at PUG(USA) available for $2 each.
Less than 20 copies each remain at PUG(UK) available for {I each or ~2.50 for 6,7,8.
None available at PUG(AUS): write to PUG(USA) or PUG(UK).
- Extra single copies of new issues are $2 each - PUG(USA); £1 each - PUG(UK); and
$A3 each - PUG(AUS).
SENDING MATERIAL FOR PUBLICATION?
(such as ideas, queries, articles, letters, oplnlons, notices, news, implementation
information, conference announcements and reports, etc.) "ALL THE NEWS THAT FITS,
WE PRINT." Please send written material for Pascal News single spaced and in cameraready form. Use lines 18.5 cm wide! Remember: ALL LETTERS TO US WILL BE PRINTED
UNLESS THEY COiHAIN A REQUEST TO THE CONTRARY.
MISCELLANEOUS INQUIRIES? Please remember we will use Pascal News as the vehicle to
answer all inquiries and regret to be unable to answer individaal requests.

I ~I . UNIVERSITY OF MINNESOTA

\.JIll!

TWIN CITIES

University Computer Center
227 Experimental Engineering Building
Minneapolis, Minnesota 55455

(612) 376-7290
Here is another potpourri of topics:
Pascal Newsletter #8
"Green on green" was not our idea (neither was the thick paper - it destroyed our poverty
image!). It was a giant disappointment to have worked so hard on #8 and see it come out
this way. We agree with the 20 or so people who gently suggested that "we say it in
black and white." We were faced with wasting paper and making the newsletter 3 weeks
late if we reprinted)or sending it out. We sent it out and were reimbursed by the
printer for the extra postage and heavy paper costs. PUGN 8 from the UK was over 2
months late due to circumstances beyond their control, but it was black on white!
Pascal Jobs
Who says you can't get a job "in the real world" using Pascal? Herb Rubenstein, the first
research assistant to work for us at the University Computer Center who learned Pascal
before he learned FORTRAN, picked Colorado as a place to live when he graduated with a
B. Sci. in Computer Science from the University of Minnesota and then he began job hunting.
In 2 months he landed a job with a rapidly growing engineering peripherals firm, AutoTrol,
and is working almost exclusively with Pascal.
Also see the OPEN FORUM section for a letter from Neil Barta.
New Australasian Distribution Center for PUG
To solve problems with slow mail to Australia (as well as currency exchange), Arthur Sale,
prolific PUGN contributor at the University of Tasmania, has kindly set up a distribution
center this summer (winter) much like Judy Mullins and David Barron did for Europe a year
ago.
The area served is Australia, New Zealand, Indonesia, and Malaysia. We at PUG(USA) are
confused about why the price is so high; apparently we were to receive a letter from
Arthur over 2 months ago with the details, but it was lost in the mail. Other details are
on the reverse side of the ALL PURPOSE COUPON.
Computer Companies Using Pascal
It is past time to print a list we've been keeping of computer companies who are seriously
using Pascal. This is so we all can argue back that "Pascal is being used for serious
real world work" when accused otherwise!
Total conversion internally to the company:
Texas Instruments, January, 1977 ("from micros to super computers")
Harris Data Communications, March, 1977 ("Pascal is our language - replacing FORTRAN and
COBOL" - Tom Spurrier.)
Companies Using Pascal for future software systems:
Cray Research (CRAY-2)
Control Data Corporation (Cyber 270 series)(They have already been using it for the 2550
and the Cyber 18)
DATA 100 Corporation (model 78)
companies marketing Pascal as a user product:
Honeywell; Computer Automation; Four Phase Systems; Varian Data Machines (Sperry Univac).

Editor's Contribution

New Developments - Micro/Personal Computers
Several PUG members took my request seriously to write to several of the personal computing
journals to promote Pascal over BASIC (see Editor's Contribution PUGN 8). David Mundie,
George Cohn, and Tim Bonham have written letters. At Frank Brewster's and Rich Cichelli 's
urging, I sent personal letters and a free copy of #8 (the ~ free copies we'had given)
to the editors of 14 computing journals. We received warm responses from half a dozen.
Also we've Qeen getting new members from their readership, some who are so curious to know
about Pascal that they are dyi ng to get thi s issue of PUGN! I'm really encouraged at
these developments because these computers represent the future and we have an early start
(unlike on the current dinosaur systems).
See the OPEN FORUM section.
Pascal News
We changed the name to avoid confusion by people who think a newletter is 4 pages long.
This issue is a combined one because it contains so much material - and it is also late.
We had to revise nearly everything: the cover, the coupon, policy, and do a summary for
the implementation notes! This has good side effects because PUGN 8 was late in Europe,
and renewals have been slow to come in. Next issue will be in February. Deadline for
material is the last day in December: (77/12/31).
New Policies
Look at all the new editors! Please read the revised policy pages on the inside covers
(front and back). The major change is that we are declaring that we are tired of
processing purchase orders and answering requests for information "about Pascal" from
people who won't join PUG and read Pascal News. It may sound strange, but we print
everything we know about Pascal in Pascal News.
Back Issues
It is really difficult to plan ahead on back issues with a growing membership. Nevertheless
we made it through last year with some extra copies of each issue. But we incurred some
tremendous distribution problems which caused unjustified delays in sending back issues
to people who joined PUG after mid-February. I apologize, and hope that we have learned
enough from our mistakes to do better this year.
Membership
We began collecting PUG memberships on 76/03/03. Here are some interesting membership
totals: 317 on 76/08/13 (#5 to press); 368 on 76/09/09 (#5 mailed);
516 on 76/11/14 (#6 to press); 560 on 76/12/10 (#6 mailed);
598 on 76/12/29 (#7 to press); 644 on 77/01/13 (#7 mailed);
943 on 77/04/26 (#8 to press); 984 on 77/05/12 (#8 mailed);
1095 on 77/06/30 (end of year);1306 on 77/09/07 as I write this (759 active).
We have 211 new members and 560 renewals since 77/07/01 with renewalS still rolling in.
PUG Finances
I last printed information in PUGN 6. Last year (our first) we promised and delivered
4 issues of PUG Newsletter. What we did not know was how popular PUG was going to be.
We also delivered a few things we did not promise: 230 copies of backissue #4, mass
mailings to get to new and old people, letters to implementors to get compiler information
and unfortu_nately, slow service to late joiners (sorry, but we wish you had joined
earlier).
See the HERE AND THERE section for details under "PUG Finances". We show a small loss almost exactly 1% - and our crude accounting knowledge doesn't account for all the back
issues produced with 76-77 money and sold in 77-78 (since July 1,·we have sold 243 at
PUG(USA) alone. So I claim we did okay.

~

- 77/09/07.

(/)

rn
-0

-l

rn

NEWSHere and There With Pascal
(* Here are extracts from almost all of PUG's mail. To reiterate what we've said
elsewhere, many of the inquiries we get are answered in previous issues. If you are a
member,
please try to find answers to your questions from Pascal News before you write
to us. If you aren't a member and you want information that's in an issue that's already
Qut, we'll tell you to join rather than to answer each inquiry with a personal
letter. *)
Attn:

Production
Automation Project, Dniv.
of Rochester Dept.
of Elec. Engr.,
Rochester, NY 14627 (Aristides Requicha): III also would appreciate any information you

might have on the existence and availability of reliable and efficient Pascal compilers
for the PDP-11/40. We normally use the RT-11 operating system." (* 77/6/28 *)
Attn:
Centro Ciencias de 1a Computacion, Universidad Catolica de Chile, Casilla 114 D,
Santiago, Chile;
"Is there any FULL PASCAL implementation for the IBM
370?"
(* 77/6/7 *)

Bill Barabash, Dept. of Computer Sci., State Univ. of NY, Stony Brook, NY 11794: "Yes. I
want to be the first one on my block to RENEW my membership in the Pascal User's Group_
I enclose a check for $4.00 which entitles me to issues 9-12 of the newsletter plus a
Captain Pascal secret decoder ring which glows in the dark • • • • " (* 77/6/8 *)

D. Michael Clarkson, DBt1S Research and Development, California Software Products, 525 N.

Cabrillo Park Dr., Suite 300, Santa Ana, CA 92701: 'My company is currently involved in
implementing a
(* 77/6/27 *)

Kurt

lot

of

high-level

transportable

Requirements Engineering and Validation System, supporting interactive color

CALCOMP plotting, and a relational
PASCAL system." (* 77/8/22 *)

data

Gus Bjorklund, 2250 Coppersmith Square, Reston, VA 22091: "l am presently working on a
Pascal compiler for the IBM Series 1, and should be finished in September 1977."
(* 77/6/22 *)

Kenneth Bowles, P.O. Box 1123, Rancho Santa Fe, CA 92067: "Looks like we will be working
with CONDUIT on getting a (Standard) ANSI BASIC running under our PASCAL system.
Object: entice Basic users over to PASCAL by making a switch very convenient. This will
be the only truly portable BASIC we know of." (* 77/6/22 *)
presently engaged in
activity is for my

education mostly, not for release.}
certainly could use the information your
newsletter will provide. For your information, I heard of the PASCAL user's group from
a notice in 'Creative Computing. n, (* 77/9/1 *)

Arthur

using

PASCAL."

Cockrum, 3398 Utah, Riverside, CA 92507: "R. A. Lovestedt should get in touch with

John

Collins,

3M

Co.,

Bldg.

235-F247, St. Paul, MN 55101: "We are considering using

PASCAL as a Systems Implementation Language for microprocessor based systems,
PDPll as a host for cross-compilation and system monitoring." (* 77/6/13 *)

using

a

Larry Crane,
EDS,
1200 Locust, Des Moines, IA 50309: "Thanks for sending us the PUG
newsletters, hopefully we'll be able to get ahold of something good. If not we'll just
have to develop it. With luck we'll have an operating system in Pascal. To the bit
bucket with Fortran, even COBOL will be overcome.
Long Live the Computocracy." (* 77/5/16 *)

(* Response to Andy's letters to personal computing publications has been heartening, if
somewhat humorous at times. In Creative Computing, f or example,
the "Pasacal" User's
Group was mentioned,
but the address got lost in the press. Nonetheless, high school
address

from

Andy's

name

and

the

Columbia

name

of

Heights,

the

building

MN

55421,

deduced

the

and wrote to ask for an

all-purpose coupon. *)

graphics,

base. We have implemented a complete 7600

Bill Brennan, 39 Jody Drive, Norristown, PA 19401: "I am
implementing PASCAL for Sperry-Univac 9000 computers.
{This

software

Tom Payne, Math Dept., University of California at Riverside, Riverside, CA 92507 for
information on HP-3000 implementations of Pascal. I believe that John Hayward of UCR
has written a P-code interpreter that runs on the 3000.
"Are there any HOBBYISTS doing anything with Pascal? Most of us can't handle tapes
(except paper) and some of us are poor." (* 77/6/6 *)

student Steven Trapp, 5020 Mulcare Drive,
Philip N. Bergstresser, 128 Jackson Ave., Madison, AL 35758: "TRW has a PASCAL program
on the CDC 7600 and TI-ASC with 40000 statements and 1100 procedures, REVS, the

system

A. Brown, 1101 New Hampshire Ave. NW, Washington, DC 20037: "I am a professional

translator of Russian mathematics, and will be glad to abstract the Proceedings of
the
All-Union Symposium on Implementation Techniques for New Programming Languages. (* We
sent them off right away, but just received word from Arthur Brown that an English
translation has been published as Vol.
47 of Springer-Verlag's Lecture Notes in

Jack Crone, Systems Analyst, USC School of Medicine, Hoffman Res. Ctr., Rm. 805, 2025
Zonal Ave., Los Angeles,
CA 90033:
(* From his letter which we saw in ~ May
1977. *) "At present, supporting a full blown high level language compiler is quite an
achievement for a personal computer; supporting several is out of the question. For
this reason it is important to make the best possible selection and to select some
obscure educational vernacular such as PASCAL because it is esthetically more pleaSing,
and
[sic] would leave personal computing where it is right now: a lot of hardware with
very little software."
Kenneth A. Dickey, 1662 Stromberg, Arcata, CA 95521: "I am especially interested in
Pascal]
applications dealing with environmental modeling, approximations, simultaneous
equations, and text editing." *( 77/7/11 *)
John Dickinson, Dept. of Elec. Engr., Univ. of Idaho, Moscow, ID 83843:

like

to

ask

your

help

in

locating

"I

would

also

a

good implementation of PASCAL for a IBM 370
machine. I understand there are many such implementations and my question for you is
which is best for a student environment. I plan to use PASCAL in a beginning computer
science class and so I would like a version that is easy to use and one that has clear

error messages." (* 77/6/30 *)
Jim Elam,
150 Lombard, No.
601, San Francisco, CA 94111: "I would be interested in
information on usage in a production environment and efficiency of generated code on

370 gear?" (* 77/6/2 *)

Computer Science. *) (* 77/6/10 *)
Gary
Thomas W. Burtnett, Computer Center, Dickinson College, Carlisle, PA 17013: "What PASCAL
is available for a PDP-ll running RSTS?" (* 77/6/30 *)
Edwin J. Calda, Dept. E152, AAI Corp., P.O. Box 6767, Baltimore, MD 21204: "\;ould
appreciate information concerning the availability of Pascal for the SEL 8000 series or
SEL 32." (* 77/7/19 *)
Patrick Chevaux, DEC, Quai Ernest Ansermet 20, B.P. 23, CH-1211 - Geneva 8, Switzerland:

"I

am urgently looking for a PASCAL compiler running on PDP-11 under RSX-llM operating

system, and I wonder if you know about such a product. If so, could you please give me
a few indications about it, as well as the person to contact and perhaps how to obtain

it." (* 77/7/11 *)

Feierbach,

Advanced Studies Dept., Inst. for Advanced Computation, P.O. Box 9071,

Sunnyvale, CA 94086: "We currently have Pascal upon our KI-IO and plan to put it up
several other machines including a version on the ILLIAC IV." (* 77/6/24 *)
Charles

N.

Fi~er,

Academic

Computing

Center,

Street, Madison, WI 53706: "We may have a proposal

on

Univ. of Wisconsin, 1210 West Dayton

for

PL/l

like

varying

length

strings for for you in the next few months - it appears to extend PASCAL fixed length
strings rather nicely. Also, I'll be in Minneapolis for a Univac User's Meeting in
mid-october.
If its convenient, I may be able to stop by and talk some PASCAL with you
(I'll be heading a PASCAL "birds of a feather" session at the meeting). (* 77/8/30 *)

Dan Fylstra, 22 Weitz St. C, Boston, MA 02134 {* To put this letter in context:
an

Dan

is

editor/consultant for Byte *}: "Initially I plan to write an article explaining the

=
rn
:::e:
en

"""

1.O

!eatures and strengths of Pascal, aimed at the BASIC-oriented beginning programmer or
casual user. But I'll certainly include notes on the status of Pascal implementations
and especially their availability on micros (since the news is so good).
"You can invite people to write or call me if they have late-breaking news that
deserves a w~der audience than the User's Group itself. Since everyone connected with
Byte is enthusiastic about Pascal, articles, new product announcements, and material
for "Byte's Bits" or the "Technical Forum" are always welcome. These should be sent to

or IMSAI, and
(* 77/6/5 *)

any

information

you

could

supply

would

be

greatly

appreciated.

Tao-Yang Hsieh, VIDAR, 77 Ortega Ave., Mountain View, CA 94040:
"I am considering
implementing Pascal on our HPZI00 system and would appreciate very much if you could
assist me in obtaining a copy of Pascal P-code compiler and a copy of Pascal compiler
written in Pascal." (* 77/8/1 *)

Byte's regular address in Peterborough." (* 77/8/22 *)
Richard Gemeinbardt, Jr., Discipledata, Inc., 110 S. Downey, Indianapolis, IN 46219:
"Please advise i f Pascal operates on any NCR hardware--such as NCR Century 201 or NCR
Criterion." (* 4/25/77 *)
James D. George, Computer Branch, Underwater Sound Reference

DiVision,

Naval

Research

Laboratory, P. O. Box 8337, Orlando, FL 32806: "The Naval Research Laboratory has
several PDP-11s, and is using RSX11M and RSX11D. I would be very much interested in
finding

out

more

about

PASCAL under RSXll, and would appreciate any leads you could

provide." (* 77/5/17 *)
Roger Gulbranson, Dept. of Physics, Univ. of Illinois, Urbana, IL 61801: "Even though

I

know you don't like it, you can add my name to the list of people who want an OTHERWISE
(or whatever) clause added to the CASE statement. I particularly liked George
Richmond's article. I'm not sure I agree with all the things he said, but most of his
points seem reasonable. I'm not sure I agree with his point about partial L->R
evaluation of boolean expressions. While I'll admit it will help some problems

concerning

array

indexes

and the like I'm finding out that the FTN (* CDC FORTRAN *)

method of logical if evaluation (i.e., convert

the

whole

mess

into

a

logical

(or

~oolean)
result) and subsequent jump on true/false is faster on machines like the [
CyberJ 175 and probably also the 76. Considering the trend toward faster hardware, it
may not be a good idea to explicitly demand partial evaluation.

"I

agree

with

Legenhausen's

comment

** *

about

pushing PASCAL in the appropriate micro

computer journals. Maybe the way to do it is to develop a standalone PASCAL compiler
for a paper tape based system with no more memory than 8K (16K if you must) and then
distribute it for a nominal fee--say $10 or $15. And no, I don't have the time to do
it." (* 77/6/6 *)
George E. Haynan, 556 Parker Rd., W. Melbourne, FL 32901: 'Many maintainers who
arbitrarily change Pascal at their sites are guilty of the NIH (Not Invented Here)
syndrome: 'If I haven't ~hought of it then it isn't any good.'
"r'm interested in Sequential Pascal,
directly compilable, for the PDP-Il, with an

Jon F. Hueras, Dept. of Information and Comp. Sci., Univ. of Calif., Irvine, CA 92717:
"I'm. ~king for Univac on the side • . • . We would find life a whole lot easier
if
we had a reasonable file comparison program to work with. You wouldn't happen to
know of anyone Who's written one in Pascal, would you? Please let us know."
(* 77/7/26 *)

Alfred

J.

Hulbert,

Inhalation

Toxicology

Res. Inst., P.O. Box 5890, Albuquerque, NM

87115: "We are working with John Barr of Hughes Aircraft to get Brian Lucas' NBS PASCAL
written in PASCAL for RSX-ll users of DEC PDP-II's (along with real time and character
string extensions)" (* 77/6/22 *)
Geoffrey Hunter, Chemistry Dept., York Univ., Duwnsview M3J 1P3, Ontario, Canada:
"Thanks for your memo of 77/05/24. I am of course familiar with Pascal and actually
taught a course one year using Wirth's book "Systematic Programming: an Introduction."
I used "Algol" rather than PASCAL, Simula, Algol 68, etc. for the Waterloo talk,
because it is, as you note,
the ancestor of all current structured programming
languages.
On first acquaintance I was an enthusiast for PASCAL, but after some practical
experience, and after reading Habermann's article in Acta Informatica V~l. 3 (1973) p.
47., I have some reserVations about some features of the language. Espec1ally the lack
of block structure (environment structuring--as distinct from control structures and
procedures in particular), and the lack of dynamically dimensio~ed arrays" ar:,
it
seems to me conceptually oversights of the language. PASCAL s strong po~nt 1S, of
course, data structuring.

***

. . " (* 77/6/1 *)

Peterborough

Nl!

03458:

"A

couple

of

optimized for high level languages such as Pascal is being performed.
lobby

of

the

A

talk

in

the

West Coast Computer Faire's convention hotel with one of Motorola's LSI

compilation and assembly done on the larger PDP-11 system. (* 77/7/29 *)
Univ. of MN, Minneapolis, MN 55455: "It may
interest PUG members to know that the LEAA (Law Enforcement Assistance Administration),
a division of the Justice Department, requires, by legally enforceable regulation, that
all criminal justice sof tware be in ANSI FORTRAN or ANSI COBOL." (* 77/8/18 *)

Matti

Karinen,

Univ.

of

and

Jyrki Tuomi, Compiler Project, Room 2113, Computer Center, Tampere

Technology,

PL

5.27,

33101

Tampere

10,

Finland:

"We

would

appreciate

language

Pascal Newsletter, especially as w~ have in mind to
implement Pascal on our PDP 11/70." (* 77/8/17*)

constructs in the next generation of integrated circuits.
A strong suggestion: people involved with the implementation of languages should seek
out LSI design engineers in order to inject ideas about appropriate features to be

Barbara I. Karkutt, Box 942, Easton, PA 18042: HAm interested in the Pascal compiler for
the Z-80 microcomputer." (* 77/6/6 *)

designers strongly hinted of

the

possibility

of

built

in

microcode

for

built into the designs of future microprocessor products. (* 77/6/20 *)

information

about

PUG

and

the

Doug Kaye, DuArt Film Labs Inc., 245 W. 55th Street, New York, NY
Richard

Hendrickson, Cray Research Inc., 7850 Metro Parkway, Suite 213, Minneapolis, MN

55420: "Keep up good work. Articles like the one by Barron and Mullins in No. 7 will do
wonderful job of keeping FORTRAN and eliminating PASCAL as major computing language."
(* 77/5/23 *)
Sam Hills,
3514 Louisiana Ave. Pkwy., New Orleans, LA 70125: "I am interested in
developing a subset of PASCAL to run on a hobby-type microcomputer such as the Altair

Here and There With Pascal

3:

to
:::0

Aron K. rnsinga,
126 Dupont Hall, University of Delaware, Newark, DE 19711: IIWe are
interested in using Pascal under UNIX (and DEC-supported operating systems) as well as
on micro-processors
(the LSI-II, Motorola M6800, and Intel 8080, in particular) with

Mitch Jolson, SSRFC, 25 Blegen Ilall,
St.,

comments about the Zi10g rumor. All the information came from the same source and later
proved premature. At the IEEE Computer Society Asilomar conference this year, a Zilog
representative could not confirm Pascal as a programming model
for
advanced
architectures, but hinted strongly that research in the direction of instruction sets

--l

rn

RT-l1/RSX-11 operating system." (* 77/5/25 *)
Carl Helmers, BYTE Publications, 70 Main

-0

rn

There is a danger with any organisation such as PUG--that it becomes the defendent of a
fixed particular definition and implementation of the language. Guard
against

this.

C/')

rn

10~19 ~

await Newsletter #9 with writeups about PASCAL on Data General gear.

(

"I

anxiously

77/7/21 *)

Ed Keith, Citrus College, 18824 E. Foothill Blvd., Azusa, CA 91702: "Please send data on
availability of compilers, assemblers etc. I have a XEROX 560, IMSAI 8080, SWIPC 6800."
(* 77/4/28 *)
Thomas J. Kelly, Jr.: 120 East Street Road, C3-9, Warminster, PA 18974: "I am interested
in

obtaining

a

Pascal compiler for any Burroughs computer; especially for the B5500,

B6700, or B7700." (* 77/5/16 *)

Peter Klauberg, c/o Hamburgische Electricitaets-Werke, Ueberseering 12, D-2000 Hamburg
60, Germany: l~y intention to use PASCAL, is to introduce the philosophy of structured
programming to out commercial COBOL-programmers. For this reason the PASCAL must be
able to communicate with normal IBM datasets.
''My question to you is: Do you know a working PASCAL compiler for our IBM 370/158 SVS?"
(*77/6/16*)
Jerry LeVan, Dept. of Math. Sciences, Eastern Kentucky Univ., Richmond, KY 40475: "I
would like to know if anybody has PASCAL running under RSTS/E on a PDP 11/70 (or 45
etc.)" (* 77/5/2 *)
Donald Lindsay, Dynalogic Corporation Ltd., 141 Bentley Ave., Ottawa, Ontario, Canada
K2E 6T7: III am interested in M6800 Pascal. I have an incomplete implementation of
Brinch Hansen's Sequential Pascal. Due to the press of other work, I would be just as
happy to purchase a compiler. (It would have to·be commercially Viable.)" (* 77/6/22 *)
David Lippincott, Information Control Systems, 313 N. First Street, Ann Arbor, Michigan
48107:
"We are a computer typesetting firm upgrading to an as yet unknown machine. We
will be writing an operating system so any information of similar applications would
facilitate my attempts at convincing others that Pascal would be a good choice. 11
(* 77/7/23 *)
R. A. Lovestedt, 20427 SE 192, Renton,
interpreter on HP3000." (* 77/5/24 *)

WA,

98055:

"Will

soon

be

starting

a

P4

Tim L. Lowery, Applications Prog. Group, 110 Love Building, Computing Center, Florida
State Univ., Tallahassee, FL 32306: "We are very interested in acqu~r~ng a Pascal
implementation for 8080 development, since Pascal is the favorite and dominant language
among the computer science students. 11 (* From a letter to PUG member Peter Zechmeister,
77/7/20 *)

and an application system, I failed to notice the Group has grown so much. /"inally got
to reading some SIGPLAN notices, and ran across your letter. 1I (* 77/5/22 *)
Carlton Mills, 203 North Gregory, Urbana, 1L 61801: "We are working on Pascal compiler
for micro-processors. It is a highly optimized cross compiler running on the B6700
(Burroughs). Currently I am looking for venture capital to get it on the market. I will
let you have more details when we are ready to announce it." (* 77/8/22 *)
J. Misra, Dept. of Computer Sciences, Painter Hall 3.28, Univ. of Texas at Austin,
Austin,
TX 78712:
"I would appreciate receiving any information about Pascal
implementation on NOVA computers.
"0ur department has recently acquired two NOVA's for which we wish to get the
compilers. The size of P-compiler wOol'ld probably make i t prohibitive for the NOVA's. I f
you know of any existing implementation, please send us the information. It (* 77/8/29 *)
Tom Moberg, Academic Computing, Grinnell College, Grinnell, IA 50112: "We are looking
for a PASCAL system which will run on our PDP 11/70 (RSTS/E)." (* 77/6/7 *)."
Gerald Nadler, RBMS Research Center, Brandeis Univ. ,Waltham, MA 02154:
11
•
I was
hoping that a list was a available of Pascal implementations on machines other than CDC
and PDP-10's." (* 77/8/18 *)
Brian Nelson, Computer Services, 2801 W. Bancroft Street, U. of Toledo, Toledo, OR
43606: "I am trying to locate a Pascal compiler for use on a PDP 11/70 and a PDP
11/40." (* 77/6/2 *)

John W. Nunnally, Harding College, Box 744, Searcy, AR 72142: "Harding College has just
ordered a PASCAL compiler from Oregon Museum of Science and Industry (OMSI). It is a
modified version of ESI's implementation that is supposed to run under RSTS/E Version
6B (with the RT-11 emulator). We will let you know how it goes." (* 77/5/25 *)

(/)

rn
Bruce Mackenzie, Computervision Corporation, 201 Burlinton Road, Route 62, Bedford, MA
01730: "We will be implementing PASCAL-P4 on Data General NOVA's and NOVA compatible
machines, running under our own operating system. We will also be using Zilog's Z80 in
the near future, PASCAL has been mentioned for it. Do you know of anyone planning to
implement PASCAL for the Z80?
"1 found a little bit of information for you: Ted Park of Loma Linda, California has a
PCODE interpreter and assembler written in (Data G~neral) ECLIPSE assembly language and
running under RDDS. It took them about a month of work. Ted said he would write you
directly." (* 77/8/9 *)
Ian MacMillan, P.O. Box 128, Mount Royal, Quebec, Canada H3N 2T6: "We are running Pascal
under NOS (* CDC 6000 operating system *). How do you get that interactive?"
(* 77/4/28 *)

Mark T. Marshall, 18229 Topham St., Reseda, CA 91335:
COMPUTER AUTOMATION LSI 4/90." (* 77/8/29 *)

"I

am

going

to

be

using

the

Jim McCord, Systemetrics Inc., 120 E. de la Guerra Street, Santa Barbara, CA 93101: "I'm
a hobbyist with an LSI-II (PDP-11-03) with dual floppies. If anybody knows of a version
of Pascal that will run on this machine, I'd like to hear about it, (especially if it's
cheap). (* 77/9/7 *)
.
Brian Meekings, Dept. of Computer Studies, Univ. of Lancaster, Bailrigg, Lancaster,
England, UK LA1 4YX: "I took advantage of the fact that we have an enthusiastic Pascal
faction here to collect some subscriptions. (* NINE were enclosed. *) Incidentally, is
there a student subscription rate--some of our undergraduates may well be interested. t1
(* There isn't, but where else can a student get a student rate that is much
cheaper? *) (* 77/5/18 *)

c.

A. Miller, Nuclear Research Centre, Dept. of PhYSics, Univ. of Alberta, Edmonton,
Alberta, T6G 2N5, Canada: "Our computing equipment giving rise to my interest in PASCAL
consists of three DATA GENERAL Eclipses." (* 77/6/8 *)

David Miller, 11203A Avalanche Way, Columbia, MD 21044: "Please sign me up for th"
PASCAL User's Group. I've been so busy developing PASCAL (relocatable, for DEC 11/45)

Carol Anne Ogdin, Software Technique, Inc., 100 Pommander Walk, Alexandria, VA 22314: "I
am preparing some material for publication on PASCAL for micros in my capacity as
Consulting Editor of Mini-Hicro Systems and EDN.II (* From a note to PUG member Peter
Zechmeister, 77/6/15. *)
Shmuel Peleg, Computer Science Center, University of Maryland, College Park,
·Do you know of any PASCAL compilers working under UNIX?" (* 77/8/28 *)

MD

-C

-;

rn

20742:

Lee Potts, DARCOM ALMSA, Attn.: DRXAL-TL, P.O. Box 1578, St. Louis, MO, 63188: "My
agency is planning to try Pascal as a systems implementation language on IBM 360 and
several minicomputers of varying architecture. Pascal's main attraction to us now is
systems portability. (* 77/9/1 *)
Walter F. Prautsch, Albertinenestrasse 29, D-IOOO Berlin 37, Germany: "1 would like to
mention that I am working in the field of system-simulation (methodology applications
in the field of urban and regional planning). If you know any people uSin~ PASCAL for
the development of simulation-systems (event-oriented as well as continuous) please
let me know their addresses." (* 77/6/10 *)
,
Bruce K. ~, Polymorphic Computer Systems, P. O. Box 3581, Boulder, CO 80303:
"1 am
interested in developing a PASCAL compiler for use with the NOVA-series computer, and
am therefore interested in anything and everything which may help me in the task. Is
there a PASCAL written in a mini-PASCAL (subset) which is available which would be
easier to bootstrap, and if so, who, how, where, and how much." (* 77/8/16 *)
Harlan R. Ribnik, P.O. Box 3182, Boulder, CO 80307: "1 am a graduate student in Computer
Science at the University of Colorado working on an implementation of a PASCAL to JANUS
compiler. I was informed by someone I met on the CDC PLATO system that I might be able
to get some information from you regarding the PASCAL Users' Group." (* 77/8/19 *)
Bo Rojder, AB Atomenergi, Fack, 611 01 Nykoping 1, Sweden: "AB Atomenergi is a research
and development center for nuclear and other energy forms. At our data center we have a
CDC CYBER 172 with 131 K memory, and NOS 1.2 operating system. We plan to install
Pascal on it and hereby apply for membership in Pascal User's Group, as individuals or
as an organization, whichever the policy of PUG is. II (* 77/8/22 *)

en

.Peter Rouschmayer, Luitpold-Gymnasl.um, Seeaustrasse 1, U-!:SUUU Munchen, Germany: "We got:

A PDP 11/34 with 64 kWordsCore, 2 Disks RK05, a LA180 Lineprinter and 7 VT50 screens.
RSTS/E Release 6B, BASIC+.
"We ought to: teach Informatics to our pupils aged 10 to 20.
'~e would
like to get: a PASCAL-Compiler, interactive if possible, running in RSTS if
possible.
"Can you help us?" (* 77/4/2 *)
Bernie Rosman, Math/CS Dept., Framingham

State

College,

Framingham,

MA

01701:

"I'm

trying to get (CDC 6000) Pascal 2 for Mass. State Gollege Computer Network (Cyber
72,73). Currently, we have Pascal-Release 1 update 11 which has some bugs; e.g., SQRT
doesn't work (fixed by MSCCN). Also: we're now using Pascal in data structures and CS
II (2nd semester-freshman) courses. We have, however, not yet switched to Pascal in CS

KI-11

Tom Spurrier, Electronics Systems DiVision, Harris Corp., P.O. Box 37, Melbourne, FL
)2901: "Harris Corp. headquarters has issued a corporate directive that Pascal is our
language. There are over 100 computer centers in the corporation. It will be used for

systems level development initially and then in applications areas." (* 77/6/21 *)
John P. Stallings, Tymshare, Corporate Offices, 20705 Valley Green Drive, Cupertino, CA
Y5014:
"Once again I find myself potentially involved in a project concerning Pascal
and have decided that it is past time for me to associate myself with an appropriate
source of information.
"Could you tell me how to go about joining the Pascal User's Group, and if possible,

z
rn
:::E:
U')

how to obtain a list of available Pascal compilers for the PDP-11?" (* 77/7/18 *)

I. Finally, we hope to install Pascal on our new PDP-11/34." (* 77/5/31 *)
David J. Rypka, Dept. of Computer and Info. SCience, 2036 Neil Ave. Mall, Columbus, Ohio
43210:

receive a special executab.le version, with GSI and CCL intertace to version) at
and LSSG's RT-11X extension of version 2C." (* 77/4/23 *)

"I

am an active user of a DEC-l0 version and would like to find other versions
and documentation for the DEC-10." (* 77/14/6 *)

Carlos Scheel, Depto de Sistemas, Instituto Tecnologico de Monterrey, Sucursal J,
Monterrey, Mexico:
I~e
would like to have the compiler of the PASCAL system; please
mail me back all the information and prices, manuals, etc." (* 77/8/8 *)

Rod Steel, MS 60-456, Tektronix Inc., P.O. Box 500,
partially

OR

97077:

the. Interdata 7/16 running on our DEC KL10 (translated from Sequential
lower case version of PASREL)." (* 77/5/31 *)

"I

have

a

Pascal

to

the

W. Richard Stevens, Kitt Peak National Observatory, P.O. Box 26732, Tuscon, AZ 85726:
(* What follows is extracted from an article Richard wrote for the Kitt Peak Computing
Newsletter

Barry Searle, TowerC Floor 10C, Transport Canada, Section TASX, Place de Ville, Ottawa,
Ontario K1A ON8, Canada: "The Canadian Dept. of Transport will be converting to Pascal
on PDP-11 equipment." (* 77/8/25 *)

Beaverton,

debugged version of Mike Ball and Co.' s Concurrent Pascal cross-compiler for

*)

"The

PASCAL

language,

because

of features designed into it, has the

ability to detect programming errors that would be undetected by any FORTRAN system.

I

have personally found that this feature alone cuts in half the time needed to develop a
new program." (* 77/1/3 - The article mentions other features of PASCAL which make it

useful at Kitt Peak. *)
David Segal, 111

Third

Ave.

BK,

New

York,

NY

10003:

"I

am

planning

to

get

a

microcomputer and would like to implement something more useful than BASIC for it to
think in. I first heard about Pascal while trying to track down information on another
decent language, BCPL. In my BCPL search I talked to Art Evans and Bob Morgan at Bolt,
Beranek and Newman in Cambridge, Mass. From them I gathered that BCPL compilers aren't
so easy to come by on small machines, but that Pascal is implemented on several
PDP-ll's. That was heartening since the microcomputer I'm most interested in is a
PDP-ll look-alike with respect to instruction set • • • • If you happen to know of any
already existing Pascal implementations on a microcomputer, or anybody working on one,
please let me know about it." (* 77/8/18 *)
Bruce

Seiler,

UCLA

Dept. of Chemistry, Los Angeles, CA 90024: "I am interested in the

Peter Sumner, Interdata Computers Pty. Ltd., 30 Kings Park Rd., West Perth, Western
Australia 6005: "I was delighted to discover the existence of your User's Group as
there are a number of interested Interdata customers in Australia. In fact,
a Pascal
compiler is currently under development at the University of Melbourne, Dept. of
Computer Science." (* 77/5/3 *)
Markku Suni, Computer Centre, Univ. of Turku, SF-20500 Turku 50, Finland: "Since I
interested in Pascal and have spent some nice hours kitbashing our Pascal compiler,
would like to join in.
. We have here a PDP-ll with KA processor, 128Kw of core,
RP03 discs, one TU10 mag tape unit, card reader, line printer, and usual sortiment
terminals." (* 77/4/28 *)

am
I
2
of

implementation of PASCAL on microprocessor based systems. n (* 77/5/23 *)
Rodney Thayer, Central Research Group, P.O. Box 451, Harvard, MA 01451: "A few people in

Michael Settle, 751 Washington, No. 115, Arlington, TX 76011: "I have a confession to
make--I~t have any idea what PASCAL is. I work with the huge Insane Business
Monsters and tinker with my own Altair. There has been so much discussion of PASCAL in
Dr. Dobb's Journal during the past year, that I finally broke down and wrote you.
Please enter a subscription to your newsletter for me, and send me the details about
your PUG." (* 77/8/15 *)

David

Elliot

Shaw,

Structured

94022: "You are performing a
implementors, fans • • • •

Systems Corp., 343 Second St. - Suite K, Los Altos, CA

welcome

service

for

the'

community

of

Pascal

users,

G.

Shaw,

P.O.

Box

the

Data

General

Lancaster

PASCAL

for

NOVA. If I am closer than England for somebody, they are welcome to

write to me to find out about Lancaster PASCAL." (* 77/7/7 *)
Mike Tiller, 2501 N. Lancaster Ln. No. 178, Plymouth, MN 55441:
for NOVA/ECLIPSE." (* 77/7/14 *)

"Interested

in

Pascal

Martin Tuori, Behavioral Sci. Div., Defence and Civil Inst. of Environmental MediCine,
P.O. Box 2000, Downsview, Ontario, M3M 389, Canada: "We will be running ES1 Pascal

under RSX11M, as soon as ESI has it ready." (* 77/7/26 *)

On the accompanying sheet we describe (as compactly as possible) the STRUCTURED SYSTEMS
PASCAL-SS compiler for the PDP-11." (* 77/7/12 *)
Jeffrey

my area (myself included) are investigating R. E. Berry's U. of

2678,

Menlo

Park,

~ Texas at Austin: (* The statistics from their newsletter indicate that Pascal
and Pascal 2 accounted for 5% of their total use in t1arch 1977. *)

Univ.

CA 94025: "Could you direct me to an

individual OJ: group that might have a Pascal compiler for
(* 77/8/18 *)

the

8080

or

280

micros?"

Evan L. Solley, The Life Support Systems Group, Ltd., 2432 NW Johnson, Portland, OR
Y7210: " • • • Also enclosed is a write-up and sample listing
for
a
PASCAL
cross-referencer we developed some time ago. It is an extension of Wirth's PCREF, which
we find much more usable. Its symbol tables are currently set up to process ESI Pascal

(V5.5) for RT-11, but can be easily modified for use with other compilers.
"The program is licensed and distributed in ASCII source form for a fee of $25.00.
Distributable media include magtape (9 track 800 bpi), DECtape, RK05 cartridge, or card
deck (800 cards). Media should be provided by Licensees. RT-11 users will additionally

James A. Vellenga, System Development, Data 100 Corp., Box 1222, Minneapolis, MN 55440:
(* He reports that there is a class in Pascal at Data 100. Ten to fifteen people were
enrolled. Nine memberships came from people at the company. *)
Kenneth R. Wadland, Computer Science Dept., Fitchburg State College, Fitchburg, MA
01420: "Although I have not used PASCAL much, I have become quite interested in it from
talking to Professor Bergeron of
the University of New Hampshire. (He has been
modifying a DEC System-10 compiler written in Germany.)
"I intend to teach PASCAL in my Data Structures course and later in my Systems
Programming course on a CDC Cyber 72. As a teaching device, I think it is far superior
to any of the other standard languages." (* 77/6/29 *)

U')

rn
-0

--I

rn
3
0:1

rn
:;;0

Walter Wehinger, Pfaffenwaldring 64, Rechenzentrum Uni Stuttgart, 0-7000 Stuttgart 80,
Germany: '~e are running PASCAL 6000.3.4 modified by T. A. Nemeth Uni Adelaide, so we
have only minor INTERCOM problems (e.g., EOL-definition). We switched over to NOS/BE
1.0 L.420 without problems."
David

H.

Welch, P.O. Box 721, Colton, CA 92324: "In the August issue of 'Microcomputer

sees

Interface' the existance of your group, its quarterly newsletter,
and dues of
$4.00/yr were mentioned. I'm interested in learning more about Pascal and I think your
newsletter might be useful." (* 77/9/2 *)
Richard West, Small Terminal Engineering, Comterm Ltd., 147 Hymus Blvd., Montreal 730,
Quebec,~nada: Our software team has decided to change over to using PASCAL to write
our systems packages. • • • I would like to have copies of • • • back issues so that we

can find the most economical way of obtaining PASCAL for our PDP-II DOS system and
a variety of microprocessors." (* 77/6/20 *)
Hans-Wilm

for

Wipperman, Univ. of Kaiserslautern, Pfaffeuberstr. 95, 0-6750 Kaiserslautern,

Germany: "German Chapter of ACM is planning a meeting concerned with PASCAL.
.1
shall inform you about details later on." (* 77/5/20 - See the Conferences section for

details of the 77/10/14 meeting. *)
Louis F. Wojnaroski, Mental Health Research Institute, University of Michigan, Ann
Arbor, MI 48109: "I am interested in implementing Pascal on my Prime-300. I would like

to get more information on the hypothetical stack machine code (Pascal-P I believe) and
any macro generat-ing systems before I attempt to order a

particular

tape

from

PUG."

(* 77/6/27 *)
Joan Zimmerman, MUMPS Users' Group, Biomedical Computer Laboratory, 700 South Euclid,
St. Louis, MO 63110: "I have never heard of any other group obsessed with a single
language apart from ours: we are all involved with MUMPS as described in the enclosed

Pocket Guide (additional copies $1) and Book of MUMPS (additional copies $2).
'~e have about 250 paying members ($25 annual

mailing

fee),

but

about

5000

people

on

Report on IFIP conference, Aug. 8-12, 1977, Toronto.
(* Thanks for this report to Nick Solntseff *) "I did not have too much interest shown
at IFIP in a meeting of PUG, but I am not really surprised as it was almost impossible
to get in touch even with people one knew were at the conference.
"The computerized message system was terrible to say the least, but anyone interested
should have seen my manual notice on the general notice board.
"In all, I gathered nine people over coffee in the hospitality lounge at various times,
but decided that a more formal meeting was not called for."
Meeting of the Pascal sub-group, AFCET, Nice, France, June 13-14, 1977.
(* PUG member Olivier Lecarme, IMAN, University of Nice, Parc Valrose, F-06034 - Nice
CEDEX, France, has sent us a bulletin, which he publishes regularly before meetings of
the sub-group,
of articles to serve as a basis of discussion for the meeting of the
sub-group. He'll try to get word to you in advance of the next meeting, but in the
meantime,
if you wish to receive the bulletin and/or be notified of meetings, write to
Olivier Lecarme. *)

Titles of Articles:
"The language Pascal as support for teaching introductory progranuning," R. Rousseau.
"The future of Pascal (extensions and standardization)," Andy Mickel.
"Some tools for users of Pascal at Rennes," l' equipe Simone.
"Simulator of machines in Pascal, II D. Thalmann.

"Pascal/CIl-Iris 80 and 10070," P. Maurice.
"Application of parallel algorithms to three simple problems, II J. Bezivin, J. L. Nebut,
and R. Rannou.
"One year of using the language Simone at Rennes:
Judgment and perspectives, II J.
Bezivin, J. L. Nebut, and R. Rannou.

(/)

BOOKS

AND

ARTICLES

-0

our

--i

list. A member has asked me to find out for him if anyone has written MUMPS in

PASCAL. If you know of anyone who has, or could query your members about this, I
appreciate any positive information." (* 77/8/22 *)

would

Karl L. Zinn, Center for Research on Learning and Teaching, University of Michigan, 109
East Madison Street, Ann Arbor, MI 48109: "I am working on uses of PASCAL in personal
computing as "ell as in intro courses." (* 77/8/15 *)

rn
We've had no news from David Barron. Rich Stevens supplied us with one item. George
Richmond's bibliography, which we didn't have room for in No.8, appears separately. A

price

list

for

some formerly out-of-print documentation appears under IMPLEMENTATIONS

LANGUAGES
Brinch Hansen, Per, The Architecture

October

14,

1977

in

Kaiserslautern.
Papers will include such subjects as "Implementations," "Pascal in
Schools," "Applications," and "Pascal and Microcomputers." For more information get in

contact with G. Nees, German Chapter of the ACM, c/o Siemans AG, E 54, Mozartstr. 33/b,
Erlangen,

Concurrent

Programs,

Englewood

Cliffs,

NJ:

simple and reliable operating systems from scratch using Concurrent Pascal."

German Chapter of the ACM, a meeting on Pascal.
(* This is rather late notice, but we'll hope that interested members will at least be

able to attend the conference, if not submit papers. *) Meeting

of

August 1977, 366 pp.~16.95. (Prentice-Hall)
(* From the publisher's blurb *)
" • • • detailed handbook showing you how !Q develop

CONFERENCES

D-8520

rn

Germany; or H.-W. Wippermann, Universitat Kaiserslautern,Informatik,

Pfaffenbergstr., Gebaude 14, 0-6750 Kaiserslautern, Germany. (* Our thanks to Hans-Wilm
Wippermann for keeping us informed about the conference. We hope to have a report

from

the conference in No. 11. *)
Pascal Day or Pascal Workshop, McMaster Univ., Hamilton, Ontario, Canada.
(* From a letter from Nick Solntseff *) "I am starting to plan a 'Pascal Day' or a

'Pascal Workshop' to be held at McMaster on March 3, 1978. I will be getting in touch
with the Regional ACM group and the IEEE Computer Society, to see if they want to
sponsor it. I am thinking of asking for brief reports on implementations, use of Pascal

for teaching, etc. n (* For more information, write to Nick Solntseff, Dept. of Applied
Mathematics, 1280 Main St. West, Hamilton, Ontario, Canada L8S 4K1; or call (416)
525-9140. *)

"Proceedings of the All-Union Symposium on Implementation Techniques
for
New
Programming
Languages,"
Novosibirsk
1975,
English
translation
published
by
Springer-Verlag as Volume 47 of their Lecture Notes in Computer Science.
(* PUG member
Arthur Brown,
who had offered to abstract the Russian, sent us news of the English
translation in lieu of the abstract. We'll try to get more information for No. 11.

TEXTBOOKS

(* A Summary of all known Pascal textbooks, partly reprinted from newsletters 5-8 *)
Atwood, J. W., Standard Pascal, to be published. (* Note: we haven't heard anything new
about this book. For more information, write to J. W. Atwood, Dept. of Comp. Sci., Sir

George Williams Campus, Concordia Univ., Montreal, Quebec, Canada H3G 1MB. *)
Conway, Richard C., David Gries, and E. C. Zimmerman,

~

Primer

~

Pascal,

Winthrop,

1976, 448 pp., paper, $9.95.
An

introduction

to

Pascal

for non-programmers which in spite of its length fails to

cover any data structures besides arrays. A rewrite of a book based on PL/C which still
carries the smell of PL/I--a foreward stating the contrary notWithstanding.

Bowles, Ken (U. of Calif., San Diego), Introduction
by Springer-Verlag in October 1977.

~

Computer SCience, to be published
APPLICATIONS

A complete introduction to Pascal for non-programmers

using

an

interactive

graphics

approach and the Keller teaching method.
Kieburtz, Richard, Structured Programming and Problem
published by Prentice-Hall sometime in 1977. For more

Solving with Pascal, to be
information, write Richard

G.

Michael,

Steven

W.

Weingart,

and

David

The

M. Perlman, Introduction!Q

manuscript may, with written permission, be duplicated for class use until

the publication date.
A complete introduction to Pascal for computer science majors.

Collection

to Compile Time," CACM, 20:7 (July

Algorithms expressed in Pascal.
for

Numerical

Computation

in

A description of how to carry attributes of computation such as temperature, energy,
fuel consumption, etc., and units expressing these attributes such as celsius, kelvin,
joules,
liters per km with numerical quantities used in scientific and engineering
problems. This circumvents problems which arise in
dealing
only
with
pure
(dimension-less) real numbers in current programming languages.

Brownlee, J. Nevil, "An
(July 1977), pp. 527-529.

Webster, C.A.G., Introduction to Pascal, Heyden, 1976. $11.00,

Garbage

Science and Engineering with Special Reference to Pascal," SIGPLAN Notices, 12:4 (April
1977), pp. 31-33.

Programming and Problem Solving with PASCAL, New York: Wiley, to be published in
January 1978. A camera-ready copy of the manuscript can be obtained by writing Gene
Davenport, Editor, John Wiley and Sons Publishers, 605 Third Avenue, New York, NY
10016.

"Shifting

Biedl, Albrecht, "An Extension of Programming Languages

Kieburtz, Dept. of Compo Sci., SUNY at Stony Brook, Stony Brook, NY 11794.
A rewrite of a book by the same name on PLjI.
Schneider,

Barth, Jeffrey M.,
1977), pp. 513-519.

5.50, DM35.00.

Implementation of SNOBOL4 Patterns," (;AQ1, 20:7

Algorithms expressed in Pascal.

A book for beginning computer-;cience majors which received a bad review in Pascal
Newsletter No.
8 because, among other things, there are numerous errors and the old
language definition was used.
Wirth, Niklaus, Systematic Programming: An Introduction, Englewood Cliffs, NJ:

ALGOL-Based

Prentice

Hall, 1973, 169 pp., $13.96.
(* From the preface *) "A book which introduces programming as the art or technique of
formulating algorithms in a systematic manner, recognizing that it is a discipline
its own right." (* This introductory book only covers Pascal through arrays *)

in

Bulman, David M., "Stack Computers," IEEE's Computer, May
Suggests that new machines introduced by semiconductor
'Pascal machines' instead of stack machines because the
for a 'hypothetical stack machine' and manufacturers may

1977.
manufacturers may be called
Pascal compiler generates code
start building machines, using

LSI technology, like the hypothetical one.
Gries, David, and Narain Gehani, "Some Ideas ort Data Types

in

High

Level

Languages,"

CACM, 20:6 (June 1977), pp. 414-420.
Algorithms expressed in Pascal.

Wirth,

Niklaus, Algorithms

+ Data Structures

~

Programs, Englewood Cliffs, NJ: Prentice
Hueras, Jon, and Henry Ledgard, "An Automatic Formatting Programming for Pascal, SIGPLAN

Hall, 1976, 366 pp., $16.50.
(* From the cover *) " . . . lucid, systematic, and penetrating treatment of
dynamic data
compilers. "

structures,

sorting,

recursive

algorithms,

language

basic and
structures, and

Notices, 12:7 (July 1977), pp. 101-105.
A

larger

description of the pretty printer announced as available for distribution in

Pascal Newsletter 6, page 70. (* This and the other article below from the
were drawn to our attention by PUG member Harry M. Murphy. *)

July

issue

IMPLEMENTATIONS
Price List s!!!:. Reports

.9.!.

Leventhal, Lance A., "Talk Your Computer's Language, II Kilobaud, August 1977, pp. 34-38.
Mentions Pascal as one high-level language used on small computers, and urges readers
to be aware of it.

Interest--hard-to-get implementation information:

Through the courtesy of George H. Richmond and his co-workers Karin Bruce and Michele
Dowd, reprints of some hard-to-get Pascal documentation is now available. Write to:
Karin and Michele--Pascal Distribution

Computing Center Library: 3645 Marine St.
Univ. of Colorado,

Boulder, CO 80309
or call (303) 492-8131.
(* These all can be ordered from North America at the price listed. All others must
include overseas postage. *)
"Pascal-S, A Subset and its Implementation," 63 pages, N. Wirth, ETH, June 1975, $6.50.
(* Includes an entire listing of a Pascal-S compiler/interpreter in Pascal. *)
"On Code Generation in a Pascal Compiler," 42 pages, U. Ammann, ETH, April 1976, $4.00.
(* Description of the internal design and performance of Pascal-6000 *)
"The Pascal-P Compiler Inplementation Notes," 65 pages,

ETH,

December

1974,

revised

July 1976 by K. V. Nori, et. al., $5.50.
(* Describes the portable Pascal compiler and interpreter. *)

(* Letter received from David Barron - 77/7/25 *)
"I am sorry I have not been able to write earlier with news of the publication

Proceedings

of

the

Pascal

Symposium.

We

had

Springer-Verlag 'Lecture Notes in Computer Science,' but after

reaction

of

the

hoped that these would appear in the
an

initial

favourable

Springer delayed, and have finally declined to publish. However, I am pleased

to be able to report that Wiley-Interscience have agreed in principle to publish the
proceedings. I
am currently discussing details with them, and hope to be able to give
you firm details very shortly."

Peterson, James L. , and Theodore A. Norman, "Buddy Systems, II

~,

20:6

(June

1977),

pp. 421-431.
Algorithm in Pascal.
Singer, A, J. Hueras, and H. Ledgard, "A Basis for Executing Pascal Programmers, SIGPLAN

Notices, 12:7 (July 1977), pp. 101-105.
A set of guidelines for standard naming, formatting and commenting conventions in
Pascal programs and why programmers should adhere to them.
Surden, Esther, "Software Thievery Cited as Thorny Hobbyist

Problem,

II

Computer

World,

June 6, 1977.
A report on the National Computer Conference, whJch lists Pascal as a programming
language available on personal computers,
but which says that there are
few
implementations of it so far.
Tennent, R. D.,
"Language Design Methods Based on Semantic Principles," to appear in
Acta Informatica, 1977. (* Rich Stevens let us know about this one. *)
(* from the summary. *) '~Two language design methods based on principles derived from
the denotation approach to programming language semantics are described and illustrated
by
an
application to the language Pascal. The principles are, firstly,
the
correspondence between parametric and declarative mechanisms, and secondly, a principle
of abstraction for programming languages adapted from set theory.
Several useful
extensions and generalizations of Pascal emerge by applying these principles, including
a solution to the array parameter problem, and a modularization facility."

MacLennan. S. 1.1., "A Note on Dynamic Arrays
-10·~. 9. pp. 39-40 (September 1975)

BIBLIOGRAPHY
Li tp.rature

abo~lt

the Programming Language Pascal

January 1971

- George H. Richmond, University of Colorado Computing Center
Ammann, U.,
"The MeU10d of
Structured
Programming
Applied
to
the
DevO::!Jopment
of
a
Compiler". "International Computing Symposium 1973",
Gunther, et a1.. Eds., pp. 93-99 North Holland (1974)
Ammnnn, U., "Die Entwlcklung eines Pascal-Compilers nach del" Methode des
strukturierten Programmierens, ETH-Diss. 5456 (1975)
Ammann., U., "On Code Generation in a
PASCAL Compiler",
Institwts fur Informatik, Nr. 13, ETH ZuriCh (April 1976)
Bachmann, K. H.,
Akademie-Verlag,

PAGE 10

SEPTEMBER,1977

PASCAL NEWS #9 & #10

"Die
Programmiersprachen
Serlin (1976)

Pascal

Berichte

und

des

Algol

in Pascal",

SIGPLAN

NOTICES

Mancel, P., Thibault,O.,
"Trensport dlun compilateur PASCAL. Ecrit en
PASCAL dlun CDC 6400 sur un ell IRIS BO", These de Docteur
lngenieur,
Univ':?rsite Paris VI (1974)
Marmier. E ••
"A Program Verifier fol" Pascal",
(IF!P Congress 1974),. North-Holland (1974)

Information Processing 74

Micl,el. A.,
"Pascal
Newsletter",
University of
Minnesota
Computer
Center,
Minneapolis; No.5 (September 1976), No.6 (November 19:3) (see
G. Richmond)
Molster,

T., Sundvor, V ••
"Unit
Pascal
System
Computer~,
Teknisk
Notat
1/74,
Institutt
Uni verSi tetet I Tronheim, Norway (February 1974)

for
the Univac
1108
for
Databehandling.

68",

TR-22,

Nagel, H.-H., "Pascal for the DEC-System
10,
Experiences and
Further
Plans",
Mitteilung Nr. 21, Institut fur Infcrmatik. Universitat Hamburg
(November 1975)

C'Jrger, W. F.,
"BOBSW A Parser
Generator", Department of Computer
SCiences. SESLTR-7, The University of Texas at Austin (December 1974)

Nori, K. V.,
Ammann. U.,
Jensen, K.,
Nageli, H. H ••
"The
Pascal(P)
Compiler:
Implementation Notes ll ,
No. 10,
Berichte des Instituts fur
Informatik, Eidgenossische Technische Hochschule. ZuriCh (December 1914)

Burger, W. F., "Pascal Manual", Department of Computer Sciences,
The University of Texas at Austin (JUly 1973)

Bran, C •• de Vries, W., "A Pascal
Compiler
for
PDP11
Minicomputers",
Department
of
Electrical Engineering, Twente University of Technology,
En5chede, Netherlands (1974); SOFHJARE-PRACTICE AND EXPERIENCE -6-,
1,
pp.
109-116 (January 1976)
Com1teur pour les

~riesland,

Solntseff. N., "McMaster Modifications to the Pascal 6000 3.4 System'I,
Computer
Science Technical Note 74-CS-2, McMaster University, OntariO,
Canada (November 1974)

11974 )

Takeichi, M., "On the portability of a PASCAL Compiler". Proceedings
the 16-th- Programming Symposium, pp. 90-96 (1975) in Japanese

(1974 )
G.,
Sengler, H.-E.,
"lur
Ueberotrag;Jng von Campi lern durch
Selbstcompilatic-n am Beispiel
des
PASCAL-Compilers",
Institut
fuel"
Infof'matlk
des
Universitaet Hamburg,
report 1Fl-HH-B-13/74 (December

c.-a.,

Grosse-Lindemann,
Lorenz, P.-W., Nagel, H.-H. t
Stir}, P. J.,
If A
PASCAL
Compi leI"
Bootstrapped on a
DEC-System10",
Fachtaguno uber
ProgrammiersP"'achen, pp. 101-1i3, Le-Cture Notes in Computer SCience -3-,
Springer-Verlag (1974).
Grosse-Lindemann, C.-O., Naqel, H.-H., "Postlude
to
a
Pascal-Compi leI"
Boo·.:strap on a DEC System-l0", Bericht Nr. 11, Institut fur Informatik,
Un i vers i tat Hamburg, Germany (1974);
SOFTWARE-PRACTICE
AND EXPERIENCE
-6-, 1, pp.
29-42 (January 1976)
Hab~:!rmann,

Pascal",

A. N.,
"Critical
ACTA INFORMATICA -3-.

Comments on
the Programming
1, pp. 47-57 (1973)

Hansen, P. S., "Operating System Principles",
Cliffs, New Jersey (1973)

Prentice-Hal',

Hansen, P. B., "The Purpose of Concurrent Pascal",
6. pp. 305-309 (1975)

Language

Englewood

SIGPLAN NOTICES -10-,

Heistad. E.,
I!Pascal
Cyber Version", Teknisk Notat 5-305 Forsvarets
Forskningsinstitutt, Norwegian Defense Research Es 3blishment,
Kjeller,
Norway (June 1973)
Hikita, T.,
Ishihata, K.,
"PASCAL 8000 REFERENCE MANUAL, Version 1.0 u ,
Techrdcal Report 16-02, Depaf'tment of Information
Science,
Faculty of
SCience, University of Tokyo (March 1976)
Hoal'e, C. A. R.,
Wirth, N., "An Axiomatic .Definition of the Programming
Language Pascal", ACTA INFDRMATICA -2-, 4. pp. 335-355 (1973)
11 1um, K., "En i ntrodukt i on t i l programmer i ngssporget Pasca 1 ~,
Ingeniorakademi, Aalborg (1973)

Danmarks

Ishihata. K.,
H't'\ita, T.,
"Bootstrapping
PM 'AL Using a
Trunk",
Technical Report 76-04, Department of Information SCience,
Faculty of
SCience, University of Tokyo (March 1976)

Takeichi. M.,
"PASCAL Compi ler
for
the FACQM 230-38:
Notes". Internal Report, UniverSity of Tokyo, Department
Engineering and Instrumentation PhysiCS (1975)

of

Implementation
of Mathematic

Takeichi, M..
.IPASCAL -- Implementation and Experience", University of
Tokyo, Department of Mathemattc Engineering and Instrumentation
Physics
(December 1975)
Thibault. 0 ••
Mancel, P.,
"Implementation of a Pascal Compiler for the
CII Iris 80 Computer". SIGPLAN NOTICES -8-, 6, pp. 89-90 (1973)
de Vries. W., "An Implementation of the language Pascal for the PDP
11
series,
based on a portable Pascal compi 1er M, Technische Hogeschool
TWe'1te, Enschede (March 1975)
Welsh, J., QUinn, C.,
"A
Pascal
Compiler
for
the
ICL 1900 Series
Computer ll , SOFTWARE-PRACTICE AND ·EXPERIENCE -2-, 1, pp. 73-77 (1972)
Wirth. N.,
Hoare, C. A. R.,
tlA Contribution to
the
Development
Algol", COMMUNICATIONS OF THE ACM -9-, 6, pp. 413-432 (1966)

of

Wirth, N., "The Programming Language Pascal", ACTA INFORMATICA
pp. 35-63 (1971)

1,

-1-,

Wirth, N.,
MThe Design of
a
Pascal Compiler". SOFTWARE-PRACTlCE AND
EXPERIENCE -1-.4, pp. 309-333 (1911)
Wirth, N., "Program Development by Step-Wise Reflnement M ,
OF THE ACM-14-, 4, pp. 221-227 (April 1971)

CDfllMUNICATIONS

Wirth, N., "The Programming Language f.c3scal and
Its Design
Criteria",
presented at
the Conference on Sof tware Eng; neer i ng Techn i ques (NATO
Science Committee).
Rome
(Dctober
1969);
published
in
"High
Level
Languages U , Infotech State of the Art Report 7 (1972)
Wi r th, N..

·Systemat i sches Programmi eren'l

(Tasche. ,-,uch), Teubner-Vet' lag,

Stuttgart (1972)

Jensen. K •• Wl rth, N., "Pasca I User Manua I and Report" I Lecture Notes in
Computer SCience, -18-, Springer-Verlag, New York (1974): Springer Study
Add i t ion (1975)

Wirth, N.,
• ... he Programming
Language Pascal (Revi,sed Report) .. , Nr. 5,
Berichte des
Instituts
fur
Informatik,
Eidgenossische
Technische
Hochschule, ZUrich (November 1972)

Knobe, B.,
Yuval, G.,
"Making a Compiler
Indent",
Department, The Hebrew University of Jerusalem, Israel

Wirth, N ••
Man
Pascal.
Code Generation,
and the CDC 6400 Computer M•
Computer Sc i ence Department, STAN-CS-72-257, Stanf ord Un; vers; ty
(1 972)
(out of print, Clearinghouse stock no. PB208519)

Computer Science
(November 1974)

Kristensen, B. B.,
Madsen, O. L.,
Jensen, B. B.,
Eriksen, S. H.,
itA
Short
Description of a Translator Writing System (BOBS-System)", Daim1
PB-11, Un i vers i ty of Aarhus, Denmark (February 1973)
Kristensen, B.' B •• Madsen, O. L., Jensen, B, B., IIA
Pascal
Environment
Machine
(P-code)",
Daimi
PB-28,
UniverSity of Aarhus. Denmark (April

1974)
Kristensen, B. B., Madsen, O. L, uensen, B. B ••
Eriksen, S. H. t
"User
Manua I
for the BOBS-System'I, unpubl i shed Enal ish Version, Uni versi ty of
Aarhus, Denmark (Apri 1 1974)
Lecarme,O.,
"Le
Montreal (1972)

langage

de

programmation

Pascal·,

Universite

Lecarme, D.,
"Structured
Programming,
Programming Teaching,
Language Pascal", SIGPLAN NOTICES -9-, 7. pp. 15-21 (JUly 1974)

de

and the

Lecarme, 0., Desjardins, P., "Reply to a Paper by A. N • .Habermann on the
Pascal",
SIGPLAN NOTICES -9-,
10.
pp. 21-27

~~~~~~~~i7~74~anguage

Lecarme, 0.,
Desjardins, P., "More Comments on the Programming Language
Pascal", ACTA INFr"MATICA -4-. PP. 231-243 (197Sl

Wirth, N.,
"SystematiC
Programming:
Englewood Cliffs, New Jersey (1973)

An IntrodU'_ction u , Prentice-Hall

Wirth, N •• "On the Composition of Well-Structured
SURVEYS -6-, 4. pp. 247-260 (December 1974)
Wirth. N .•

MAlgorithmen und Oatenstrukturen M

,

Programs",

f

COMPUTING

Teubner-Verlug, Stuttgart

( 1975)
Wirth, N., MAlgorithms + Datastructures
Englewood Cl iffs, New Jersey (1975)

Prog ·.J.ms'l,

Prentice-Hall

t

Wirth, N.,
MAn Assessment
of
the Programming language Pascal·, IEEE
TRANSACTlONS ON SOFTWARE ENGINEERING -1-, 2, pp. 192-198 (1975); SIGPLAN
NOTICES -10-, 6, pp. 23-30 (~une 1975)
Wirth. N.,
MPASCAL-S:
A Subset and
its
Berichte
des
Instituts
fur
Infor;natik,
Hochschl,l 1 e, Zur i ch (Jl,lne 1975)
Wirth, N., ·Comment on A Note on Dynamic
NOTICES -11-, 1, pp. 37-38 (,January 1976)

Implementation",
Nr. 12,
Eidgenossische Technische

Arrays

in

Pascal",

SIGPLAN

PAST ISSUES OF Pascal Newsletter (now Pascal News)
George RichmOnd, Computing Center, University of Colorado, started Pascal Newsletter
with issue #1 in January, 1974. He proceeded to produce 3 more issues while doing
the other thankless chores of distributing 2 Pascal compilers to dozens of sites and
promoting Pascal in other ways.
In mid-1975 John Strait and I proposed a Pascal User's Group after having talked to
several other Pascalers around the U.S. At the Minneapolis ACM '75 conference in
October, 1975, we launched the group at an ad hoc meeting (35 persons) convened by
Rich Cichelli and Bob (Warren) Johnson. A year later we began the task of producing
4 issues of Pascal Newsletter which PUG as a group assumed responsibility for.
John and I edited the first 2 issues with help from Tim Bonham on the Implementations
section. By issue #8 John had less time for the constant demands of the newsletter
and only promised occasional help, but with #8 Jim Miner, Sara Graffunder, and others
volunteered to help. With this issue (#9 
), we have spread the load quite a bit,
which only causes coordination problems!
#1 January, 1974, University of Colorado Computing Center, (also SIGPLAN Notices 9:3
1974 March) 8 pages, edited by George Richmond. (* Mostly contained descriptions
of the CDC-6000 implementation of unrevised Pascal. *)
out of print
#2 May, 1974, University of Colorado Computing Center, (also SIGPLAN Notices 9:11
1974 November) 18 pages, edited by George Richmond. (* A Pascal history; news of
other implementations for unrevised Pascal; news of the new CDC-6000 implementation
for revised Pascal.*) out of print
#3 February, 1975, University of Colorado Computing Center, (also SIGPLAN Notices 11:2
1976 February) 19 pages, edited by George Richmond. (* Announcement of the book:
Pascal User Manual and Report; Pascal usage questionaire; revised History of Pascal;
bibliography; news of Pascal-P; more on Pascal-6000 for CDC machines; letters to the
editor. *) ouf, of print
#4 August, 1976, University of Colorado Computing Center, 103 pages (103 numbered pages),
edited by George Richmond. (* 36 letters of correspondence dealing mostly with
various implementations; implementors list; bibliography; news of new release of
Pascal-P.*)
out of print
#5 September, 1976, Pascal User's Group, University of Minnesota Computer Center, 124
pages (65 numbered pages), edited by Andy Mickel. (* Short notes, 5 articles,
general correspondence, and implementation notes were featured; Christian Jacobi,
ETH Zurich supplied a description of Dynamic Array Parameters. *)
#6 November, 1976, Pasc,al User's Group, University of Mi nnesota Computer Center,
180 pages (91 numbered pages), edited by Andy Mickel. (* News from members; a full
membership roster; conference notices; information on back issues; 6 articles
including 2 proposing directions for Pascal by G. Michael Schneider of the U of
Minnesota, and Rich Cichelli of Lehigh University; much implementation news. *)
#7 February, 1977, Pascal User's Group, University of Minnesota Computer Center, 90
pages (45 numbered pages), edited by Andy Mickel. (* ~1ore News from members;
books; 3 articles; correspondence; implementation notes. *)
#8 May, 1977, Pascal User's Group, University of Minnesota Computer Center, 128 pages
(65 numbered pages), edited by Andy Mickel. (* News from members; Conferences;
Books; Applications; 6 articles including one by Ken Bowles about a very complete
inexpensive implementation for nearly every microprocessor in existence; Special
topic: official standardization and clarified definition of Pascal; Portable
Pascals, Feature implementation notes, Machine Dependent implementations, Index. *)

PUG FINANCES 1976-1977
Here are the details for our finances last academic year by both PUG(USA) and PUG(UK).
For additional information see the EDITOR'S CONTRIBUTION (for a real con) under "PUG
Finances."
PUG(USA) Accounts:
Income:
$3980.00 995 memberships @ $4 (76-77)
161.73 contributions
70.00 miscellaneous back issues sold @ $1
$4211.73 TOTAL Income.
Expendi ture:
$ 123.37 buying (230) and mailing #4 from George Richmond
492.70 printing (700) and mailing #5
1239.50 printing (1050) and mailing #6
697.17 printing (1000) and mailing #7
1071.60 printing (1000) and mailing #8
30.23 mailing originals of 5-8, etc. to PUG(UK) for reprinting
92.13 promoting PUG (mass mailings)
10.00 refunds for overpayment
19.00 backissue requests for #4 forwarded to George Richmond
101.09 miscellaneous postage for automatic backissues
$3876.79 TOTAL Expenditure.
PUG(UK) Accounts:

(submitted by David Barron, 15 August, 1977)

Income:
£249.90 subscriptions for 76-77 (99 @ 2.50; 1 @ 2.40)
£249.20 TOTAL Income.
Expenditure:
70.86 printing 250 copies of No.6
29.14 printing 350 cop~es of No.7
105.34 printing 450 coples of No.8
171.06 postage for 6,7, and 8 including back issues

~

f376.40 total production costs
90.01 printing and posting NO.5 (450 copies)
~466.41

TOTAL Expenditure.

========================================================================================

PUG(USA) surplus
PUG(UK) deficit = ~216.51
Total deficit for year

$334.94

= $380.00 approx.
= $ 45.06
Andy Mickel

Back issue ordering information for #5-#8 is on the back of the ALL PURPOSE COUPON.

77/09/01

ROSTER (77109/09)
The PUG roster is sorted by mail code (USA first) and then alphabetically by country.
Members span 31 countries and 47 states. Also supplied is a member index by last name
to mail code. Institutional members begin with the prefix ATTN or ATTENTION.
U1002
01420
01451
01451
01609
01609
01701
01701
01701
01720
01730
01741
01742
01749
01752
01752
01754
01754
01754
01754
01754
01754
01754
01754
01754
01776
01852
01907
02035
02035
02038
02111
02115
02115
02115
02125
02134
02138
02138
02138
02138
02139
02139
02139
02139
02139
02140
02154
02154
02154
02154
02154
02154
02155
02160
02167
02168

You can see at a glance who is at a well known organization at a well known place.
The roster makes a great organizing tool for our mutual communication! Please look
yourself up to check for accuracy and then you can see who is nearby; why not
phone them and talk about Pascal?
States with over 50 PUG members are: California - 171; Minnesota - 128; Texas - 62;
Massachusetts - 61; and countries: United Kingdom - 101; Canada - 59; Germany - 57.

HENRY F. LEDGARD/ COMPUTER AND INFO. SCI./ U OF MASSACHUSETTS/ AMHERST MA 01002/ (413) 545-2744
KENNETH R. WADLAND/ COMPUTER SCIENCE DEPT./ FITCHBURG STATE COLLEGE/ MAIL BOX NUMBER 6372/ FITCHBURG MA 01420/ (617) 342-2268
RALPH S. GooDELL/ HILLCREST DRIVE/ HARVARD MA 01451/ (617) 456-8090
R. L. TMAYER/ CENTRAL RESEARCH GROUP/ P.o. BOX 451/ HARVARD MA 01451/ (617) 772-2306
JOHN DE ROSA JR./ WORCESTER POLYTECHNIC INST./ P.O. BOX 2131/ .WORCESTER MA 01609/ (617) 798-8947
NORMAN E. SONDAK/ COMPo SCI. DEPT./ WORCESTER POLYTECHNIC INSTITUTE/ WORCESTER MA 01609/ (617) 753-1411
HANK EDWARDS/ 2C BRACKETT ROAD/ FRAMINGHAM MA 01701/ (617) 620-1066 (HOME)/ (617) 897-5111 X6809
BERNIE ROSMAN/ MATH/CS DEPT./ FRAMINGHAM STATE COLLEGE/ FRAMINGHAM MA 01701/ (617) 872-3501
DAVID TARABAR/ FIELD ENGINEERING/ DATA GENERAL CORPORATION/ 23~ OLD CONNECTICUT PATH/ FRAMINGHAM MA 01701/ (617) 620-1200 X362
SCOTT D. HANKIN/ 382A GREAT ROAD APT. 103/ ACTON MA 01720/ (617) 263-9121
BRUCE MACKENZIE/ COMPUTERVISION CORP./ 201 BURLINGTON ROAD - ROUTE 62/ BEDFORD MA 01730/ (617) 275-1800
MARTHA L. SPENCE/ 145 CARLISLE PINES DR./ CARLISLE MA 01741/ (b17) 369-7311 (HOME)/ (617) 449-2000 X2526 (OFC.)
MARK S. MAYES/ TSD SYSTEMS ENGINEERING/ GEN RAD./ 300 BAKER AVE./ W. CONCORD MA 01742/ (617) 369-4400
KATHLEEN JENSEN/ 1 FRANKLIN ST./ HUDSON MA 01749/ (617) 897-5111 (WORK)/ (617) 562-9538 (HOME)
DWIGHT BAKER/ MRl/M64/ DIGITAL COMPONENTS/ ONE IRON WAY/ MARLBORO MA 01752/ (617) 481-7400 X6637
CARL W. SCHWARCZ/ MR 1-2/E27/ DIGITAL EQUIPMENT CORP./ 200 FOREST STREET/ MARLBORO MA 01752/ (617) 481-9511
ATTN: LIBRARY/ ML5-4/A20/ DIGITAL EQUIPMENT CORPORATION/ MAYNARD MA 01754
RONALD F. BRENDER/ BLISS LANGUAGE DEVELOPMENT/ ML3-5/E82/ DIGItAL EQUIPMENT CORP./ 146 MAIN STREET/ MAYNARD MA 01754/ (617) 897-5111 X2520
ALBERT S. BROWN/ PK3-1/M12/ DIGITAL EQUIPMENT CORP./ 146 MAIN STREET/ MAYNARD MA 01754/ (617) 897-5111 X2391
N. AMOS GILEADI/ APPLIED SYSTEMS GROUP/ ML 21-4 E-20/ DIGITAL EQUIPMENT CORP./ 146 MAIN STREET/ MAYNARD MA 01754/ (617) 897-5111 X4402/X3888/X6472
RONALD J. HAM/ ML5-5/E40/ DIGITAL EQUIPMENT CORPORATION/ 146 MAIN STREET/ MAYNARD MA 01754/ (617) 897-5111
RICHARD KIMBALL/ 145 WALTHAM ST./ MAYNARD MA 01754
DAVID MOBERLY/ P.O. BOX 241/ MAYNARD MA 01754/ (617) 897-8078
ISAAC R. NASSI/ DIGITAL EQUIPMENT CORP./ 146 MAIN STREET/ MAYNARD MA 01754/ (617) 897-5111 X4487
WILLIAM F. SHAWl ML5-5/E40/ DIGITAL EQUIPMENT CORPORATION/ 146 MAIN STREET/ MAYNARD MA 01754/ (617) 897-5111
LLOYD DICKMAN/ 93 PRATTS MILL ROAD/ SUDBURY MA 01776
EDWARD STEEN/ 119 SHERMAN STREET/ LOWELL MA 01852/ (617) 454-9320
JAMES W. HEBERT/51 THOMAS ROAD/ SWAMPSCOTT MA 01907/ (617) 581-3807
THOMAS G. MCGINTY/ DEPT. 330/ FOXBORO CO./ 38 NEPONSET AVE./ FOXBORO MA 02035/ (617) 543-8750 X2031
AARON SAWYER/ DEPT 330/ THE FOXBORO COMPANY/ FOXBORO MA 02035/ (617) 543-8750 X2029
WARREN R. BROWN/ D.330/ THE FOXBORO COMPANY/ 38 NEPONSET AVE./ FOXBORO MA 02038/ (617) 543-8750 X2023
ROGER A. DUE/ SOFTWARE SYSTEMS DESIGN/ TERADYNE INC./ 183 ESSEX STREET/ BOSTON MA 02111/ (617) 482-2700
ATTN: MATH LIBRARY/ NORTHEASTERN UNIVERSITY/ 360 HUNTINGTON AVE./ BOSTON MA 02115/ (617) 437-2460
JOHN CASEY/ DEPARTMENT OF MATHEMATICS/ NORTHEASTERN UNIVERSITY! 360 HUNTINGTON AVENUE/ BOSTON MA 02115/ (617) 437-2450
JENNIFER CLARKE/ COMPUTATION CENTER/ 25 RICHARDS HALL/ NORTHEASTERN U./ HUNTINGTON AVE./ BOSTON MA 02115/ (617) 437-3183
VICTOR S. MILLER/ DEPT OF MATHEMATICS/ BLDG 2/ U OF MASSACHUSETTS/ HARBOR CAMPUS/ BOSTON MA 02125/ (617) 287-1900 X3170/X3161
DAN FYLSTRA/ 22 WEITZ ST. #3/ BOSTON MA 02134
BRUCE KNOBE/ INTERMETRICS INC./ 701 CONCORU AVE./ CAMBRIDGE MA U2138/ (617) 661-1840
MICHAEL MEEHAN/ WINTHROP PUBLISHERS/ 17 DUNSTER STREET/ CAMBRIDGE MA 02138/ (617) 868-1750
CHARLES ROBERT MORGAN/ BOLT BERANEK AND NEWMAN/50 MOULTON STR EET/ CAMBRIDGE MA 02138/ (617) 491-1850 XS02
ROBERT E. WELLS/ BOLT BERANEK AND NEWMAN INC./ 50 MOULTON STREET/ CAMBRIDGE MA 02138/ (617) 491-1850
ATTN: READING ROOM/ INFORMATION PROCESSING CENTER/ 39-430/ MIT I CAMBltIDGE MA 02139
GABRIEL CHANG/ 575 TECHNOLOGY SQUARE/ HONEYWELL INFORMATION SYSTEMS/ CAMBRIDGE MA 02139/ (617) 491-6300
F. J. CORBATO/ NE43-514/ MASSACHUSETTS INSTITUTE OF TECHNOLOGY! 545 TECHNOLOGY SQUARE/ CAMBRIDGE MA 02139/ (617) 253-6001
JEANNE FERRANTE/ 125 ANTRIM ST./ CAMBRIDGE MA 02139/ (617) 876-8635
JOHN N. STRAYHORN/ BOX 157 MIT BRANCH P.O./ CAMBRIDGE MA 02139! (617) 923-1133
KENNETH OLSON/ 16 MONTGOMERY ST./ CAMBRIDGE MA 02140/ (617) 86H-3068
R. STERLING EANES/ SOFTECH/ 460 TOTTEN POND ROAD/ WALTHAM MA 02154/ (617) 890-6900
JOHN B. GooDENOUGH/ SOFTECH INC./ 460 TOTTEN POND RD/ WALTHAM ',MA 02154/ (617) 890-6900
R. KRASIN/ FIRST DATA CORP./ 400 TOTTEN POND ROAD/ WALTHAM MA U2154/ (617) 890-6701
GERALD NADLER/ RBMS RESEARCH CENTER/ BRANDEIS UNIVERSITY/ WALTHAM MA 02154
MICHAEL ROONEY/ THE BOSTON SYSTEMS OFFICE INC./ 400-1 TOTTEN pOIID ROAD/ WALTHAM MA 02154/ (617) 890-0888
ROY A. WILSKER/ 27 BENEFIT STREET/ WALTHAM MA 02154/ (617) 899-6638
DAVID SOLOMONT/ COMPUTER SERVICES/ MILLER HALL/ TUFTS UNIVERSITY/ MEDFORD MA 02155/ (617) 628-2943
PETER COLBY/ 289 MILL ST./ NEWTONVILLE MA 02160/ (617) 527-2394
GEORGE C. HETRICK/ COMPUTING CENTER/ BOSTON COLLEGE/ CHESTNUT HILL MA 02167/ (617) 969-0100
GEORGE POONEN/ 15 ORCHARD AVE./ WABAN MA 02168/ (617) 969-4684

en
l"T1
""0

-I
l"T1
3:
tx:1
l"T1

;:c

""0

»
Ci")

l"T1

.......
N

02172
02173
02174
02193
02809
02881
02912
03060
03301
03458
03766
03824
03824
04103
06035
06268
06320
06413
06432
06488
06901
07102
07205
07470
07724
07724
07733
07757
07828
08540
08903
08904
10003
10003
10012
10012
10013
10016
10016
10019
10019
10024
10025
10027
10036
10598
11530
11740
11794
11794
11794
11973
12180
12181
12308
13032
13201
13210
13210
13323
13440
13440
13676
13676
13760
14063

FRED EILENSTEIN/ 68 SPRING STREET/ WATERTOWN MA 02172/ (617) 924-2248
G. M. SHANNON/ LINCOLN LAB/ J-148G/ M.I.T./ 244 WOOD STREET/ LtiINGTON MA 02173/ (617) 862-5500 X5719
MICHAEL HAGERTY/ 83 PARK STREET/ ARLINGTON MA 02174/ (617) 492 -7100
TERRENCE M. COLLIGAN/ RIVERSIDE OFFICE PARK/ MANAGEMENT DECISION SYSTEMS INC./ RIVERSIDE ROAD/ WESTON MA 02193/ (617) 891-0335
E. R. BEAUREGARD/ 10 HYDRAULION AVE./ BRISTOL RI 02809/ (401) 253-7358
DAVID J. GRIFFITHS/ ACADEMIC COMPUTER CENTER/ TYLER HALL/ UNIVERSITY OF RHODE ISLAND/ KINGSTON RI 02881/ (401) 792-2701
ANDRIES VAN DAM/ BROWN UNIVERSITY/ BOX F/ PROVIDENCE RI 02912/ (401) 863-3088
ATTENTION: JO AN HUESMAN/ NASHUA OPERATIONS/ HARRIS DATA COMMUNICATIONS DIV./ DANIEL WEBSTER HIGHWAY SOUTH/ NASHUA NH 03060/ (603) 883-3313
VINCENT KAYSER/ NORTHEAST ELECTRONICS/ BOX 649/ CONCORD NH 03301/ (603) 224-6511 X-261
CARL HELMERS/ BYTE PUBLICATIONS INC./ 70 MAIN STREET/ PETERBOROUGH NH 03458/ (603) 924-7217
WILLIAM M. LAYTON/ POLYTRONICS/ METHODIST HILL/ LEBANON ~H 03766/ (603) 646-2068
ATTENTION: R. D. BERGERON/ DEPARTMENT OF MATHEMATICS/ KINGSBURY HALL/ U OF NEW HAMPSHIRE/ DURHAM NH 03824/ (603) 862-2321
WILLIAM J. VASILIOU JR./ COMPUTER SERVICES/ KINGSBURY HALL/ U OF NEW HAMPSHIRE/ DURHAM NH 03824/ (603) 862-2323
JOHN HEATH/ DEPT. OF MATH. AND COMPUTER SCI./ UNIV. OF MAINE/ PORTLAND ME 04103/ (207) 773TIMOTHY DENNIS/ 62 LAKESIDE DRIVE/ GRANBY CT 06035/ (203) 653-4492
EDWARD E. BALKOVICH/ DEPT. OF ELECT. ENGR. AND COMPo SCI./ U-157/ UNIV. OF CONNECTICUT/ STORRS CT 06268/ (203)486-4816
JAMES P. SHORES/ 344 GLENWOOD AVE./ NEW LONDON CT 06320/ (203) 442-0771 X2126
ROSEMARY HOWBRIGG/ 36 MENUNKETESUCK DRIVE/ CLINTON CT 06413/ (203) 669-5812 (HOME)/ (203) 442-0771 X2963 (WORK)
MARK BECKER/ 300 COLLINGWOOD AVE/ FAIRFIELD CT 06432/ (203) 334-3627
CHARLES E. SIMON/ RD #1 BERKSHIRE RD./ SOUTHBURY CT 06488/ (203) 264-0640 (HOME)/ (203) 377-4141 X2286 (WORK)
MARK SEIDEN/ NATIONAL CSS INC./ 500 SUMMER ST. - 4 FL./ STAMPORD CT 06901/ (203) 327-9100 X206
PETER ANDERSON/ COMPUTER AND INFO SCI DEPT./ NEW JERSEY INSTITUTE OF TECHNOLOGY/ 323 HIGH STREET/ NEWARK NJ 07102/ (201) 645-5126
NICHOLAS WYBOLT/ 576 LEO STREET/ HILLSIDE NJ 07205/ (201) 688-5328
RICHARD D. SPILLANE/ DEPT OF MATH/C.S./ WILLIAM PATTERSON COL.! WAYNE NJ 07470/ (201) 881-2158
DAN C. RICHARD/ P.O. BOX 188/ EATONTOWN NJ 07724/ (201) 542-3814 (hOME)
RON PRICE/ PERKIN-ELMER DATA SYSTEMS/ 106 APPLE ST./ TINTON FALLS NJ 07724
RON OLSEN/ ROOM 3E207/ BELL LABORATORIES/ CRAWFORD CORNER ROAD! HOLMDEL NJ 07733/ (201) 949-5537
FRANK KURKA/ P.O. BOX 209/ OCEANPORT NJ 07757/ (201) 229-4487
KEN POLAKOWSKI/ 5D VILLAGE GREEN/ BUDD LAKE NJ 07828/ (201) 347-4375
PAUL S. HELLER/ EDUCOM/ P.O. BOX 364/ PRINCETON NJ 08540/ (609) 921-7575
CHARLES HEDRICK/ COMPUTER SCIENCE DEPT./ RUTGERS/ HILL CENTER/ NEW BRUNSWICK NJ 08903
STEVE LEGENHAUSEN/ 12 BARNARD STREET/ HIGHLAND PARK NJ 08904/ (201) 572-6585
WILLIAM HENRY/ 117 E. TENTH ST./ NEW YORK NY 10003
DAVID SEGAL/ 111 THIRD AVE. #2K/ NEW YORK NY 10003/ (212) 674-0454
EDWARD R. FRIEDMAN/ CIMS/CS DEPT./ NEW YORK UNIVERSITY/ NEW YORK NY 10012/ (212) 460-7100
DAVID SHIELDS/ COURANT INSTITUTE/ NEW YORK UNIVERSITY/ 251 MERCER ST./ NEW YO"RK NY 10012/ (212) 460-7168
FRANK PAVLIK/ QUOTRON SYSTEMS INC./ 325 HUDSON ST./ NEW YORK NY 10013/ (212) 344-0400 EXT. 71
GENE A. DAVENPORT/ JOHN WILEY AND SONS/60S THIRD AVENUE/ NEW YORK NY 10016/ (212) 867-9800
STEPHEN LEIBOWITZ/ 165 EAST 32 ST. - APT. 6D/ NEW YORK NY 10016/ (212) 483-2595/ (212) 889-1035
DOUGLAS R. KAYE/ COMPUTER SERVICES/ DU ART FILM LABORATORIES/ 245 WEST 55 ST./ NEW YORK NY 10019/ (212) 757-4580
PETER PAWELCZAK/ UNIVERSITY COMPUTER CENTER/ C/O LIBRARY/ CUNY! 555 W. 57TH ST./ NEW YORK NY 10019
STEVE GROSS/ 200 W. 86TH ST./ NEW YORK NY 10024
HOWARD D. ESKIN/ CENTER FOR COMPUTING ACTIVITIES/ ROOM 712/ COLUMBIA UNIVERSITY/ 612 W. 115TH ST./ NEW YORK NY 10025/ (212) 280-2874
T. A. D'AURIA/ CENTER FOR COMPUTING ACTIVITIES/ COLUMBIA UNIVERSITY/ NEW YORK NY 10027
P. J. PLAUGER/ SUITE 3830/ YOURDON/ 1133 AVE. OF THE AMERICAS/ NEW YORK NY 10036/ (212) 730-2670
PETER G. CAPEK/ IBM RESEARCH CENTER/ P.O. BOX 218/ YORKTOWN HTS NY 10598/ (914) 945-1250
REX FRANCIOTTI/ COMPUTER CENTER/ ADELPHI UNIVERSITY/ GARDEN CITY NY 11530/ (516) 294-8700
M. WAITE/ HAZELTINE CORP./ GREENLAWN NY 11740/ (516) 261-7000 X687
ATTENTION: GARRY S. MEYER/ COMPUTING CENTER/ APPLICATIONS SUPPORT/ SUNY STONY BROOK/ STONY BROOK NY 11794/ (516) 246-7047
WILLIAM BARABASH/ DEPT. OF COMPo SCI./ SUNY STONY BROOK/ STONY BROOK NY 11794/ (516) 246-7146
RICHARD B KIEBURTZ/ DEPT. OF COMPUTER SCI./ SUNY AT STONY BROOK/ STONY BROOK NY 11794/ (516) 246-5987
M. ELIZABETH IBARRA/ DEPT. OF APPLIED MATH/ BROOKHAVEN NATIONAL LABORATORY/ UPTON NY 11973/ (516) 345-4162
J. SCOTT MERRITT/ 36 OAKWOOD AVE./ TROY NY 12180/ (518) 271-7553
S. KAMAL ABDALI/ DEPT. OF MATHEMATICAL SCIENCES/ RENSSELAER POLYTECHNIC INSTITUTE/ TROY NY 12181/ (518) 270-6558
GEORGE H. WILLIAMS/ EE/CS DEPT./ UNION COLLEGE/ SCHENECTADY NY 12308/ (518) 370-6273
J. WILSON/ WHITMAN RD. R.D. #3 BOX 224H/ CANASTOTA NY 13032/ (315) 697-3639
J. DANIEL GERSTEN/ COMPUTED IMAGE ENG. - CSP 3-21/ GENERAL ELECTRIC CO./ SYRACUSE NY 13201
J. L. POSDAMER/ SCHOOL OF COMPo AND INFO. SCI./ 313 LINK HALL/ SYRACUSE U/ SYRACUSE NY 13210/ (315) 423-4679
JOHN M. WOBUS/ 453 WESTCOTT ST. APT. 1/ SYRACUSE NY 13210/ (315) 472-4923
WALTER WUENSCH/ BOX 62/ CLINTON NY 13323/ (315) 797-2370
DAVID A. BENNETT/ PAR CORP./ ON THE MALL/ ROME NY 13440/ (315) 336-8400
MICHAEL N. CONDICT/ PATTERN ANALYSIS AND RECOGNITION CORP/ ON THE MALL/ ROME NY 13440/ (315) 336-8400 X36
NEWTON J. MUNSON/ COMPUTING CENTER/ CLARKSON COLLEGE/ POTSDAM NY 13676/ (315) 268-7721
TED TENNY/ COMPUTER SCIENCE DEPT./ SUNY - POTSDAM/ POTSDAM NY 13676/ (315) 268-2954
ROBERT L. KING/ 1452 SANDRA DR./ ENDICOTT NY 13760/ (607) 754-3112
G. H. GOLDEN JR./ COMPUTER CENTER/ MAY TUM HALL/ STATE UNIVERSITY COLLEGE/ FREDONIA NY 14063

14226
14420
14609
14623
14627
14850
14850
14850
14850
14853
14853
15260
15261
15701
15701
16802
17011
17257
17837
17837
18015
18015
18015
18015
18015
18015
18017
18018
18018
18018
18041
18042
18049
18055
18103
18104
18353
18651
18703
18938
18960
18974
19018
19085
19085
19104
19122
19122
19122
19122
19174
19301
19301
19401
19426
19464
19711
19711
19711
19711
19898
19898
20006
20012
20014
20014

G. FRIEDER/ DEPT. OF COMPUTER SCIENCE/ SUNY BUFFALO/ 4226 RIDGE LEA RD./ BUFFALO NY 14226/ (716) 831-1351
JAMES MOLONEY/DEPT. OF COMP. SCI. / SUNY BROCKPORT/BROCKPORT n 14420/ (716) 395-2384
EDWARD W. SUOR/ COMPUTER CONSOLES INC./ 97 HUMBOLDT STREET/ ROCHESTER NY 14609/ (716) 482-5000 X291
MICHAEL J. LUTZ/ SCHOOL OF COMPUTER SCIENCE/ ROCHESTER INSTITUTE OF TECHNOLOGY/ ROCHESTER NY 14623/ (716) 464-2139
ATTN: PRODUCTION AUTOMATION PROJECT/ ELEC. ENGR. _ COL. OF ENGR. AND APPLIE/ UNIV. OF ROCHESTER/ ROCHESTER NY 14627/ (716) 275-3775
RICHARD CONWAY/ DEPT. OF COMPUTER SCIENCE/ CORNELL UNIVERSITY/ ITHACA NY 14850/ (607) 256-3456
WILLIAM LYCZKO/ SOFTWARE DEVELOPMENT/ NCR CORPORATION/TERMINAL SYSTEMS/ 950 DANBY ROAO/ ITHACA NY 14850/ (607) 273-5310/ X251 X254
KEVIN WEILER/ 147 CORNELL QRTRS/ CORNELL UNIVERSITY/ ITHACA NY 14850/ (607) 256-4880 (DAY)/ (607) 272-7563 (NITE)
JOHN H. WILLIAMS/ OCS/ 418 UPSON HALL/ CORNELL U/ ITHACA NY 14~50/ (607) 256-5033
THOMAS P. BISHOP/ DEPT. OF COMPUTER SCIENCE/ CORNELL UNIVERSITY/ ITHACA NY 14853/ (607) 256-4052
HAL PERKINS/ DEPT. OF COMPUTER SCIENCE/ CORNELL UNIVERSITY/ ITlu\CA NY 14853
MARY LOU SOFFA/ COMPUTER SCI. DEPT./ 335 ALUMNI HALL/ UNIVERSITY OF PITTSBURGH/ PITTSBURGH PA 15260/ (412) 624-6454
JOHN DOW/ WESTERN PSYCHIATRIC INST. AND CLINIC/ U. OF PITTSBUR~H/ 3811 O'HARA STREET/ PITTSBURGH PA 15261/ (412) 624-2848
JOHN NOLD/ COMPUTER CENTER/ G7 STRIGHT HALL/ INDIANA UNIVERSITY OF PA./ INDIANA PA 15701
HOWARD E. TOMPKINS/ COMPUTER SCIENCE DEPT/ INDIANA UNIVERSITY OF PAl INDIANA PA 15701/ (412) 357-2524
BENTON LEONG/ COMPUTER SCIENCE DEPT./ PENNSYLVANIA STATE U./ UNIVERSITY PK PA 16802/ (814) 865-1545
DONALD L. WRIGHT/ 832 WYNNEWOOD RD./ CAMP HILL PA 17011/ (717) 161-0260
CHARLES E. MILLER/ RD 5 - CRESCENT DRIVE/ SHIPPENSBURG PA 1725'7/ (717) 532-9121 X104
ATTENTION: RUTH DROZIN/ FREAS-ROOKE COMPUTER CENTER/ BUCKNELL UNIVERSITY/ LEWISBURG PA 17837/ (717) 524-1436
DANIEL C. HYDE/ COMPUTER SCIENCE PROGRAN/ BUCKNELL UNIVERSITY/ LEWISBURG PA 17837/ (717) 524-1392
JOHN W. ADAMS/ DEPT. OF I.E./ 19 PACKARD LAB/ LEHIGH UNIV./ BETHLEHEM PA 18015
DAVID B. ANDERSON/ DEPT. OF MATHEMATICS/ 14 CHRISTMAS-SAueON/ LEHIGH UNIVERSITY/ BETHLEHEM PA 18015/ (215) 867-4253
DAVE ENGLANDER/ 302 SUMMIT STREET/ BETHLEHEM PA 18015/ (215) 865-9027
S. L. GULDEN/ DEPT. OF MATH/ LEHIGH UNIVERSITY/ BETHLEHEM PA 1~015/ (215) 691-7000 X341
THOMAS RAMS BERGER/ 1036 BROADWAY/ BETHLEHEM PA 18015/ (215) 86~-0905
V. LALITA RAO/ 506 W. THIRD STREET APT. 4/ BETHLEHEM PA 18015/ (215) 865-6448
STEPHEN TITCOMB/ 1111 NORTH BLVD./ BETHLEHEM PA 18017
RANCE J. DELONG/ MORAVIAN COLLEGE/ BETHLEHEM PA 18018
MARILYN HOFFMAN/ 531 W. UNION BLVD./ BETHLEHEM PA 18018/ (215) 865-6937
JOHN A. WEAVER/ 2112 PENNSYLVANIA AVE. F-6/ BETHLEHEM PA 180181 (215) 867-1085
JOSEPH A. MEZZAROBA/ BOX 164/ E. GREENVILLE PA 18041/ (215) 472-8365 (WORK)/ (215) 679-9900 (HOME)
BARBARA I. KARKUTT/ BOX 942/ EASTON PA 18042/ (215) 252-1684
JOHN W. IOBST/ 22 N. KEYSTONE AVE./ EMMAUS PA 18049/ (215) 965-4677
ALEX OSTAPENKO/ 346 ELLEN ST./ HELLERTOWN PA 18055/ (215) 838-7171
RICHARD J. CICHELLI/ 901 WHITTIER DRIVE/ ALLENTOWN PA 18103/ (215) 797-9690
RAMON,TAN/ 2345 UNION ST./ ALLENTOWN PA 18104/ (215) 434-5432
THOMAS HALLDORSON/ BIRCHWOOD PARK #4/ SAYLORSBURG PA 18353
STEPHEN J VNUK/ 740 MILL ST./ PLYMOUTH PA 18651/ (717) 779-9741
JOSEPH A. PARKER JR./ DEPT. OF MATH AND COMPo SCI./ WILKES COLLEGE/ WILKES-BARRE PA 18703/ (717) 824-4651 X448
BILL CHESWICK/ DARIEN 15B / VILLAGE 2/ NEW HOPE PA 18938
CHESTER J. SALWACH/ 2124 DIAMOND STREET/ SELLERSVILLE PA 189601 (215) 723-8301
TOM KELLY/ APT. C 3-9 ASHWOOD APARTMENTS/ 120 EAST STREET ROAOI WARMINSTER PA 18974/ (215) 674-9821
T. L.(FRANK) PAPPAS/ 5130 GRAMERCY DRIVE/ CLIFTON HGTS PA 1901~/ (215) 259-1325
ATTN: MATHEMATICS DEPARTMENT/ VILLANOVA UNIVERSITY/ VILLANOVA PA 19085/ (215) 527-2100
THOMAS SCOTTI COMPUTER CENTER/ VILLANOVA UNIVERSITY/ VILLANOVA PA 19085/ (215) 527-2100 X215
DAVID A. NELSON/ INFORMATION ENGINEERING/ 3401 MARKET STREET/ PHILAOELPHIA PA 19104/ (215) 387-5150
FRANK L. FRIEDMAN/ DEPT. OF COMPo AND INFO. SCI./ TEMPLE UNIVERSITY/ PHILADELPHIA PA 19122
GIORGIO P. INGARGIOLA/ CIS/ 382 SPEAKMAN HALL/ TEMPLE UNIVERSITY/ PHILAOELPHIA PA 19122/ (215) 787-8457
ROBERT KEZELL/ UNIVERSITY COMPUTER ACTIVITY/ TEMPLE UNIVERSITY 1 PHILADELPHIA PA 19122/ (215) 787-8527
FRANK RYBICKI/ COMPUTER ACTIVITY/ TEMPLE UNIVERSITY/ BROAO AND MONTGOMERY/ PHILAOELPHIA PA 19122/ (215) 737-1115
WILLIAM C. HOPKINS/ DEPT. OF COMPo AND INFO. SCI./ U OF PENNSYLVANIA/ PHILAOELPHIA PA 19174/ (215) 243-8549
JOHN T. LYNCH/ BURROUGHS CORP./ P.O. BOX 517/ PAOLI PA 19301
E. L. ROWE/ BURROUGHS CORP./ BOX 517/ PAOLI PA 19301/ (215) 648-2218
BILL BRENNAN/ 39 JODY DRIVE/ NORRISTOWN PA 19401
LEE LAMBERT/ 967 SCHOOL STREET/ COLLEGEVILLE PA 19426
RICHARD A. JOKIEL/ P.O. BOX 818/ POTTSTOWN PA 19464/ (215) 385-6324
JOHN D. EISENBERG/ COMPUTING CENTRE/ SMITH HALL/ U OF DELAWARE 1 NEWARK DE 19711/ (302) 738-8441 X57 (OFN,CE) / (302) 453-9059 (HOME)
WILLIAM Q. GRAHAM/ COMPUTING CENTER/ U. OF DELAWARE/ 13 SMITH HALL/ NEWARK DE 19711/ (302) 368-1513
DAVID HAWK/ 2B7 WHARTON DRIVE/ NEWARK DE 19711
ARON K. INSINGA/ DEPT. OF ELEC. ENGR./ 126 DUPONT HALL/ UNIV. OF DELAWARE/ NEWARK DE 19711/ (302) 738-2406
C. E. BRIDGE/ ENGINEERING DEVELOPMENT LAB/ E. I. DU PONT DE NEMOURS AND CO./ 101 BEECH STREET/ WILMINGTON DE 19898/ (302) 774-1731
STEPHEN C. SCHWARM/ E.I. DU PONT DE NEMOURS CO./ 101 BEECH ST. 1 WILMINGTON DE 19898/ (302) 774-1669
MIKE FRAME/ FIRST DATA CORP./ 2011 EYE ST. NW/ WASHINGTON DC 20006/ (202) 872-0580
RICK THOMAS/ 408 DOMER AVENUE/ TAKOMA PARK MD 20012/ (301) 565 -2678
TERRY P. MEDLIN/ SCIENTIFIC RESEARCH UNIT - DPSA/ NATIONAL INSTITUTE OF DENTAL HEALTH/ BETHESDA MD 20014
WAYNE RASBAND/ BLDG 36 ROOM 2A-03/ NATIONAL INSTITUTES OF HEALTH/ BETHESDA MD 20014/ (301) 496-4957

:z

20014
20016
20016
20037
20037
20052
20052
20234
20375
20433
20550
20705
20742
20742
20742
20755
20810
20810
20854
20910
21031
21044
21045
21204
21218
22090
22091
22091
22101
22152
22201
22209
22210
22304
22311
22314
22314
22901
22901
22901
22901
22901
22903
22903
23234
23284
23508
23602
23665
23666
24401
27514
28743
29206
29208
29613
30092
30328
30332
30332
30332
30332
30332
32303
32304
32304

JOHN M. SHAWl BLDG 36 / ROOM 2A29/ NATIONAL INSTITUTES OF HEALTH/ BETHESDA MO 20014/ (301) 496-3204
DAVID A. GOMBERG/ DEPT. OF MATH. STAT. AND COMPo SCI./ AMERICAN UNIVERSITY/ MASSACHUSETTS & NEBRASKA AVES./ WASHINGTON DC 20016/ (202) 686-2393
JOSEPH P. JOHNSON/ 3520 QUEBEC ST. NW/ WASHINGTON DC 20016/ (202) 362-8523
MARGERY AUSTIN/ THE URBAN INSTITUTE/ 2100 M STREET NW/ WASHING TON DC 20037/ (202) 223-1950
ARTHUR A. BROWN/ 1101 NEW HAMPSHIRE AVE. NW APT.l002/ WASHINGTON DC 20037/ (202) 785-0716
RICHARD TABOR/ UNIVERSITY COMPUTER CENTER/ GEORGE WASHINGTON UNIVERSITY/ 2013 G STREET N.W. #201/ WASHINGTON DC 20052/ (202) 676-6140
RAYMOND E. THOMAS/ DEPT. OF STATISTICS/ GEORGE WASHINGTON UN IV ./ WASHINGTON DC 20052/ (202) 676-6369
T. HARDY/ SECTION J-640.02/ TECH A367/ NATIONAL BUREAU OF STAN DARDS/ WASHINGTON DC 20234
PETER A. RIGSBEE/ CODE 5494/ NAVAL RESEARCH LABORATORY/ WASHINGTON DC 20375/ (202) 767-3181
PETER GUTTERMAN/ COMPUTING ACTIVITIES/ DEPT. N954/ THE WORLD BANK/ 1818 H STREET N.W./ WASHINGTON DC 20433/ (202) 393-6360
THOMAS A. KEENAN/ DIVISION OF MATHEMATICAL AND COMPUTER/ Nf\IlONAL SCIENCE. FOUNDATION! WASHINGTON DC 20550/ (202) 632-7346
TED L. FREEMAN/ RDA INC./ 5012 HERZEL PLACE/ BELTSVILLE MO 20705/ (301) 937-2215
SHMUEL PELEG/ COMPUTER SCIENCE CENTER/ U OF MARYLAND/ COLLEGE PArtK MO 20742/ (301) 454-4527
BEN SHNEIDERMAN/ DEPT. OF INFO. SYS. MGMI./ U OF MARYLAND/ COLLEGE PARK MO 20742/ (301) 454-2548
JOYCE A. SMITH/ COMPUTER SCIENCE CENTER/ PROGRAM LIBRARY/ U OF I~YLAND/ COLLEGE PARK MO 20742/ (301) 454-4261
JOHN NOLAN/ NATIONAL SECURITY AGENCY/ R51/ DEPARTMENT OF DEFENSE/ 9800 SAVAGE ROAD/ FT. MEADE MO 20755
M. J. GRALIA/ APPLIED PHYSICS LABORATORY/ THE JOHNS HOPKINS UNIVERSITY/ JOHNS HOPKINS ROAD/ LAUREL MO 20810/ (301) 953-7100 X7386
A. E. SALWIN/ APPLIED PHYSICS LABORATORY/ THE JOHNS HOPKINS UNIVERSITY/ JOHNS HOPKINS ROAD/ LAUREL MO 20810/ (301) 953-7100
CHARLES BACON/ 10717 BURBANK DR./ POTOMAC MO 20854/ (301) 299-2732 (HOME)/ (301) 496-4823 (WORK)
JACOB C. Y. WU/ SYSTEM SCIENCES DIVISION/ COMPUTER SCIENCES CORPORATION/ 8728 COLESVILLE ROAD/ SILVER SPRING MO 20910/ (301) 589-1545 X276
ATTN: M. WATKINS - TECHNICAL LIBRARIAN/ GENERAL INSTRUMENT CORP./ 11126 MCCORMICK ROAD/ HUNT VALLEY MO 21031/ (301) 666-8700 X333
DAVID MILLER/ 11203A AVALANCHE WAY/ COLUMBIA MO 21044/ (301) 992-5665
RAINER F. MCCOWN/ MCCOWN COMPUTER SERVICES/ 9537 LONG LOOK LANE/ COLUMBIA MO 21045/ (301) 730-0379
EDWIN J. CALKA/ E152/ AAI CORP/ P.O. BOX 6767/ BALTIMORE MO 21204
JOHN LEWIS/ MATH. SCIENCES DEPT./ JOHNS HOPKINS UNIVERSITY/ CHARLES AND 34TH STREETS/ BALTIMORE MO 21218/ (301) 338-7207
DAVID AULT/ COMPUTER SCIENCE/ VPI AND sui 11440 ISAAC NEWTON SQ. N./ RESTON VA 22090/ (703) 471-4601
GUS BJORKLUND/ 2250 COPPERSMITH SQUARE/ RESTON VA 22091
JAMES K. MOORE/ 12345 COLERAINE COURT/ RESTON VA 22091/ (703) 437-2338
EDWARD W. HURLEY/ XONICS INC./ 1700 OLD MEADOW ROAD/ MCLEAN VA 22101/ (703) 790-1840
MARE S. WATERBURY/ 8358 L DUNHAM CT./ SPRINGFIELD VA 22152
L. EDWARD REICH/80S N. CLEVELAND STREET/ ARLINGTON VA 22201/ (703) 243-3131
WILLIAM A. WHITAKER/ DARPA/ 1400 WILSON BLVD./ ARLINGTON VA 22209
JOHN N. LATTA/ P.O. BOX 1297/ ARLINGTON VA 22210
FRANK BREWSTER/ 4701 KENMORE AVE #1009/ ALEXANDRIA VA 22304/ (/03) 370-6645
ARNOLD SHORE/ 5021 SEMINARY RD. #1613/ ALEXANDRIA VA 22311/ (703) 379-2247
RONALD S. NAU/ C/O TELEDYNE GEOTECH/ P.O. BOX 334/ ALEXANDRIA VA 22314/ (703) 836-3882
CAKOL A. OGDIN/ SOFTWARE TECHNIQUE INC./ 100 POMMANDER WALK/ ALEXANDRIA VA 22314/ (703) 549-0646
LINWOOD FERGUSON/ 741-B MOUNTAINWOOD RD./ CHARLOTTESVIL VA 22901/ (804) 293-7816
ROBERT A. GIBSON/ WEST LEIGH/ 2380 KINGSTON RD/ CHARLOTTESVIL VA 22901/ (804) 977-3233
STEPHEN J. HARTLEY/ 2330-20 PEYTON DR./ CHARLOTTESVIL VA 22901/ (804) 827-2897 (WORK)
TIM HILL/ MEDICAL COMPUTING CENTER/ MEDICAL CENTER BOX 282/ UNIVERSITY OF VIRGINIA/ CHARLOTTESVIL VA 22901/ (804) 924-5261
TERRENCE PRATT/ DEPT. OF APPLIED MATH/ THORNTON HALL/ UNIV. OF VIRGINIA/ CHARLOTTESVIL VA 22901/ (804) 924-7201
ATTN: J. F. MCINTYRE - LIBRARIAN/ COMPUTING CENTER/ GILMER HALL/ U OF VIRGINIA/ CHARLOTTESVIL VA 22903/ (804) 924-3731
DAVID A. MUNDIE/ FRENCH DEPT./ 302 CABELL HALL/ U. OF VIRGINIA/ CHARLOTTESVIL VA 22903/ (804) 924-7157
WILLIAM C. MOORE JR./ 3518 LUCKYHEE CRESCENT/ RICHMOND VA 23234/ (804) 275-6676
ANN D. DAVIES/ UNIVERSITY COMPUTER CENTER/ VIRGINIA COMMONWEALTH UNIVERSITY/lOIS FLOYD AVE./ RICHMOND VA 23284/ (804) 770-6339
FRANCES L. VAN SCOY/ DEPT. OF MATH AND COMPUTING SCIENCES/ OLD DOMINION UNIV./ NORFOLK VA 23508/ (804) 489-6522
DAVID A. HOUGH/ 529 HELM DRIVE/ NEWPORT NEWS VA 23602/ (804) 874-3387
J. C. KNIGHT/ LANGLEY RESEARCH CENTER/ M/S 125A/ NASA/ HAMPTON VA 23665
DAVID E. HAMILTON/ 119G PINEWOOD CRESCENT/ HAMPTON VA 23666/ (~04) 827-0758
FRED W. POWELL/ INNOVATIVE MANAGEMENT SYSTEMS/ PO BOX 2585 / 865 MIDDLEBROOK AVENUE/ STAUNTON VA 24401/ (703) 885-4950
STEVEN M. BELLOVIN/ DEPT. OF COMPo SCI./ U OF NORTH CAROLINA/ CHAPEL HILL NC 27514/ (919) 933-5698
CHRISTOPHER K. JOHANSEN/ FREEKSHOW ELECTRON WORKS & XOPHER INFOR/ ROUTE 1 BOX 157/ HOT SPRINGS NC 28743/ (704) 622-3423
HOWARD EISENSTEIN/ 6616 DARE CIRCLE/ COLUMBIA SC 29206/ (803) 782-0544
GERALD STEINBACK/ COMPUTER SERVICES DIV./ U. OF SOUTH CAROLINA/ COLUMBIA SC 29208/ (803) 777-6001
T. RAY NANNEY/ DEPT. OF COMPUTER SCIENCE/ FURMAN UNIV./ GREENVILLE SC 29613/ (803) 294-2097
GERALD N. CEDERQUIST/ DIGITAL CO~ftIDNICATIONS ASSOC./ 135 TECHNOLOGY PARK/ NORCROSS GA 30092/ (404) 448-1400
M. L. MCGRAW/ 655 SPALDING DR./ ATLANTA GA 30328/ (404) 394-2017
ATTENTION: JERRY W. SEGERS/ OFFICE OF COMPUTING SERVICES/ GEORGIA INSTITUTE OF TECHNOLOGY/ ATLANTA GA 30332/ (404) 894-4676
PHILLIP H. ENSLOW JR./ SCHOOL OF INFO. AND COMPo SCI./ GEORGIA TECH/ ATLANTA GA 30332/ (404) 894-3187
JAMES N. FARMER/ OFFICE OF COMPUTING SERVICES/ GEORGIA TECH/ 225 NORTH AVE. NW/ ATLANTA GA 30332/ (404) 894-4660
JOHN J. GODA JR./ SCHOOL OF INFORMATION AND COMPUTER SCI/ GEORGIA TECH/ ATLANTA GA 30332/ (404) 894-3131
JOHN P. WEST/ OFFICE OF COMPUTING SERVICES/ GEORGIA TECH/ 225 NORTH AVE. N.W./ ATLANTA GA 30332/ (404) 894-4676
C. EDWARD REID/ RT. 7 BOX 1257/ TALLAHASSEE FL 32303/ (904) 48~-2451
T. P. BAKER/ DEPT. OF MATH/ 225 LOVE BUILDING/ FLORIDA STATE U,/ TALLAHASSEE FL 32304/ (904) 644-2580
TIM LOWERY/ COMPUTING CENTER/ 110 LOVE BUILDING/ FLORIDA STATE UNIVERSITY/ TALLAHASSEE FL 32304/ (904) 644-3860

rn
:::e::
C/)

-0

»
Gl

rn

32306
32604
32611
32611
32611
32806
32901
32901
32901
32901
32901
33307
33309
33314
35223
35486
35758
35801
35801
35806
35807
37130
37232
37916
37916
38677
38677
39210
39762
40208
40208
40475
40506
40506
43210
43220
43606
44106
44106
44115
44139
44306
44325
44691
45036
46202
46637
46989
47130
47150
47306
47401
47401
47401
47401
47401
47401
47401
47902
47906
47906
47907
47907
47907
47907
48103

R. GARY LEE/ COMPUTING CENTER/ 110 LOVE BUILDING/ FLORIDA STATE U/ TALLAHASSEE FL 32306/ (904) 644-2761
LE H. NGUYEN/ UNIVERSITY OF FLORIDA STATION/ P.O. BOX 12605/ GAINESVILLE FL 32604/ (904) 377-9879 (HOME)/ (904) 392-0907 (OFFICE)
ATTN: DIRECTOR/ NORTHEAST REGIONAL DATA CENTER/ 253 SSRB/ U OF FLORIDA/ GAINESVILLE FL 32611/ (904) 392-2061
ATTN: LIBRARIAN/ CIRCA/ 411 WEIL/ U OF FLORIDA/ GAINESVILLE FL 32611/ (904) 392-0907
JAMES B. CONKLIN JR./ CIRCA/ 411 WELL HALL/ U. OF FLORIDA/ GAINESVILLE FL 32611
J. D. GEORGE/ COMPUTER BRANCH/ NAVAL RESEARCH LABORATORY/ P.O. BOX 8337/ ORLANDO FL 32806/ (305) 859-5120
SAM HARBAUGH/ E.E. DEPT./ FLORIDA INST. OF TECHNOLOGY/ P.O. BOX 1150/ MELBOURNE FL 32901/ (305) 723-3701 X332
GEORGE A. SEYFEBT/ HARRIS CONTROLS DIVISION/ P.O. BOX 430/ MELBOURNE FL 32901/ (305) 727-5675
TOM SPURRIER/ ELECTRONICS SYSTEMS DIVISION/ HARRIS CORP./ P.O. BOX 37/ MELBOURNE FL 32901
CASEY TUBBS/ ELECTRONICS SYSTEMS DIVISION/ HARRIS CORP./ P.O. BOX 37/ MELBOURNE FL 32901/ (305) 727-4000
GEORGE E. HAYNAM/ 556 PARKER ROAD/ W.MELBOURNE FL 32901/ (904) 378-8118
BOB BRUCE/ COMPUTER SYSTEMS DIV./ MAIL DROP 15/ HARRIS CORPORATION/ 1200 GATEWAY DR./ FT. LAUDERDALE FL 33307/ (305) 974-1700 X235
ATTN: MOD COMP LIBRARY/ MS #21/ 1650 W. MCNAB ROAD/ FT. LAUDERDAL FL 33309/ (305) 974-1380
FRED L. SCOTTI BROWARD COMMUNITY COLLEGE/ 3501 DAVIE ROAD/ FT. LAUDERDAL FL 33314/ (305) 581-8700
JEFFREY W. GRAHAM/ GRAHAM COMPUTER ENTERPRISES INC./ 3 OFFICE PARK CIR. - SUITE 106/ BIRMINGHAM AL 35223/ (205) 870-7267
DONALD B. CROUCH/ DEPT.OF COMPUTER SCIENCE/ U. OF ALABAMA/ P.O. BOX 6316/ UNIVERSITY AL 35486/ (205) 348-6363
PHILIP N. BERGSTRESSER/ 128 JACKSON AVE./ MADISON AL 35758/ (205) 837-2400
MARVIN E. KURTTI/ 1327 MONTE SANO BLVD. S.E./ HUNTSVILLE AL 35H01
JOHN D. REYNOLDS/ C/O SYSTEM DEVELOPMENT CORP./ 4810 BRADFORD BOULEVARD/ HUNTSVILLE AL 35801/ (205) 837-7610
ATTENTION: DAVID MADISON/ ADVANCED SOFTWARE TECHNOLOGY DEPT./ TEXAS INSTRUMENTS INC./ 304 WYNN DRIVE/ HUNTSVILLE AL 35806/ (205) 837-7510
PEL HSIA/ COMPUTER SCIENCE PROGHAM/ U OF ALABAMA AT HUNTSVILLE I P.O. BOX 1247/ HUNTSVILLE AL 35807/ (205) 895-6088
SAMUEL T. BAKER/ 1310 STONEWALL BLVD./ MURFREESBORO TN 37130/ (615) 896-3362 (HOME)/ (615) 741-3531 (OFFICE)
STANLEY B. HIGGINS/ DEPARTMENT OF MEDICINE/ VANDERBILT UNIVERSITY/ NASHVILLE TN 37232/ (615) 322-3384
ATTENTION: GORDON R. SHEBMAN/ COMPUTER CENTER/ 200 STOKELY MGMT. CENTER/ U OF TENNESSEE/ KNOXVILLE TN 37916
CHARLES PFLEEGER/ COMPo SCI. DEPT./ U OF TENNESSEE/ KNOXVILLE TN 37916/ (615) 974-5067
ATTN: DEPT. OF COMPUTER SCIENCE/ U OF MISSISSIPPI/ UNIVERSITY MS 38677
RALPH D. JEFFORDS/ DEPT. OF COMPUTER SCIENCE/ U. OF MISSISSIPPI/ UNIVERSITY MS 38677/ (601) 232-7219 (OFFICE)/ (601) 234-0874 (HOME)
ROBERT A. SHIVE JR./ MILLSAPS COLLEGE/ STATION A/ JACKSON MS 39210/ (601) 354-5201
GAY THOMAS/ COMPUTEB SCIENCE DEPT./ DRAWER cc/ MISS. STATE MS 39762/ (601) 325-2942
BRUCE DAWSON/ COMPUTER CENTER -BELKNAP/ COMPUTER AND SYSTEMS BUILDING/ UNIVERSITY OF LOUISVILLE/ LOUISVILLE KY 40208/ (502) 588-6123
SANDEE MITCHELL/ DEPT. OF APPLIED MATH AND COMPUTER SCI/ U. OF LOUISVILLE/ SPEED SCIENCE S/ LOUISVILLE KY 40208/ (502) 636-6661
JERRY LEVAN/ DEPT. OF MATH. SCIENCES/ EASTERN KENTUCKY UNIV./ RICHMOND KY 40475/ (606) 622-5782
LAVINE THRAILKILL/ COMPUTING CENTER/ 72 MCVEY HALL/ U OF KENTUCKY/ LEXINGTON KY 40506/ (606) 258-2916
M. W. VANNIER/ WENNER-GREN RESEARCH LABORAIORY/ U. OF KENTUCKY I LEXINGTON KY 40506/ (606) 258-8885
DAVID J. RYPKA/ DEPT. OF COMPo AND INFO. SCI./ OHIO STATE UNIV./ 2036 NEIL AVENUE MALL/ COLUMBUS OH 43210/ (614) 422-7402
ROY F. REEVES/ 1640 SUSSEX COURT/ COLUMBUS OH 43220/ (614) 422-4843
BRIAN NELSON/ COMPUTER SERVICES/ U. OF TOLEDO/ 2801 W. BANCROFT STREET/ TOLEDO OH 43606/ (419) 537-2511
R. B. LAKE/ BIOMETRY/ WEARN BUILDING/ UNIVERSITY HOSPITALS/ CLEVELAND OH 44106/ (216) 791-7300
FRANK OLYNYK/ CHI CORPORATION/ 11000 CEDAR AVE./ CLEVELAND OH 44106/ (216) 229-6400
T. S. HEINES/ DEPT. OF COMPUTER SCIENCE/ CLEVELAND STATE UNIVERSITY/ CLEVELAND OH 44115/ (216) 687-4762/ (216) 687-4760
TOM ZWlTTER/ ADVANCED DEVELOPMENT DIV./ BUILDING B/ OHIO NUCLEAR INC./ 6000 COCHRAN RD./ SOLON OH 44139
JOHN R. LINDSAY/ 1609 SALEM AVE./ AKRON OH 44306/ (216) 784-68/4
ROBERT L. BRIECHLE/ THE COMPUTER CENTER/ U OF AKRON/ 302 E. BUCHTEL AVE./ AKRON OH 44325/ (216) 375-7172
E. C. ZIMMERMAN/ COMPUTER CENTEB/ THE COLLEGE OF WOOSTER/ WOOSTER OH 44691/ (216) 264-1234 X304
PATRICIA VAN DERZEE/ PROCESS CONTROLS DIVISION/ CINCINNATI MILACRON INC./ LEBANON OH 45036/ (513) 494-5320
ROBERT J. SNYDER/ GR.FL. UNION BUILDING DATA CENTER/ INDIANA U - PURDUE U AT INDIANAPOLIS/ 1100 WEST MICHIGAN STREET/ INDIANAPOLIS IN 46202
ATTN: DOCUMENTS ROOM LIBRARIAN/ COMPUTING CENTEB/ U OF NOTRE DAME/ NOTRE DAME IN 46637/ (219) 283-7784
R. WALDO ROTH/ COMPUTER SCIENCE DEPT/ TAYLOR UNIVERSITY/ UPLAN'D IN 46989/ (317) 998-2751 X269
ANDREW S. PUCHRIK/ 1803 VILLAGE GREEN BLVD. #94/ JEFFERSONVILL IN 47130/ (812) 283-4059
DOUGLAS H. QUEBBEMAN/ COMPUTING SERVICES/ INDIANA UNIV. - SOUTHEAST/ 4201 GRANTLINE ROAD/ NEW ALBANY IN 47150/ (812) 945-2731 X287
GEORGE GRUNWALD/ DEPT. MATH. SCIENCES/ BALL STATE UNIVERSITY/ MuNCIE IN 47306/ (317) 285-6164
GEORGE COHN 111/ 316 N. WASHINGTON/ BLOOMINGTON IN 47401/ (812) 337-9255/ (812) 337-1911
ANTHONY J. SCHAEFFER/ 3510 DUNSTAN DR/ BLOOMINGTON IN 47401/ (812) 334-1163/ (812) 337-9137
LAURA SNYDER/ 402 E. 17TH/ BLOOMINGTON IN 47401
HAL STEIN/ BOX 102 WRIGHT QUAD/ INDIANA UNIVERSITY/ BLOOMINGTON IN 47401/ (812) 337-7081
ALFRED I. TOWELL/ WRUBEL COMPUTER CENTER/ INDIANA UNIVERSITY/ BLOOMINGTON IN 47401/ (812) 337-1911
DAVID S. WISE/ COMPUTER SCIENCE DEPT./ 101 LINDLEY HALL/ INDIANA U/ BLOOMINGTON IN 47401/ (812) 337-4866
STEPHEN W. YOUNG/ WRUBEL COMPUTEB CENTER/ HPER BUILDING/ INDIANA UNIVERSITY/ BLOOMINGTON IN 47401/ (812) 337-1911
JAMES R. MILLER/ P.O. BOX 1141/ LAFAYETTE IN 47902/ (317) 494-8232 (OFFICE)
KENNETH LEROY ADAMS/ 927 N. SALISBURY ST./ W. LAFAYETTE IN 47906/ (317) 743-9905 (HOME)/ (317) 493-9407 OR 494-8232 (WORK)
DAN DORROUGH/ 400 NORTH RIVER RD. - 1018/ W. LAFAYETTE IN 47900/ (317) 493-9408
DOUGLAS COMER/ COMPUTER SCIENCES DEPT./ 402 MATH BLDG./ PURDUE UNIVERSITY/ W. LAFAYETTE IN 47907/ (317) 493-3327
DOROTHY E. DENNING/ COMPUTER SCIENCES DEPT./ 442 MATH SCIENCES. BLDG./ PURDUE UNIVERSITY/ W. LAFAYETTE IN 47907
JOSEPH H. FASEL 111/ COMPUTER SCIENCES/ 442 MATH SCIENCES BUILUING/ PURDUE UNIVERSITY/ W. LAFAYETTE IN 47907/ (317) 494-8566
EDWARD F. GEHRINGER/ DEPT. OF COMPUTER SCIENCE/ MATH SCIENCES BUILDING/ PURDUE UNIVERSITY/ W. LAFAYETTE IN 47907
ALAN A. KORTESOJA/ 701 W. DAVIS/ ANN ARBOR MI 48103/ (313) 995_6124/ (313) 995-6000

48105
48106
48106
48106
48107
48109
48109
48109
48127
48130
48202
48221
48228
48823
48823
48823
48824
48824
48824
48824
48910
49007
49008
49008
49401
50011
50112
50309
50311
52101
52242
52242
53115
53201
53211
53211
53219
53703
53705
53705
53706
53706
53706
53706
54302
54701
54701
54701
55057
55057
55068
55101
55101
55104
55108
55108
55109
55112
55112
55112
55112
55113
55113
55113
55113
55165

JOHN s. GOURLAY/ 1413 MCINTYRE/ ANN ARBOR MI 48105/ (313) 994-6645
NEIL J. BARTA/ ADP NETWORK SERVICES/ 175 JACKSON PLAZA/ ANN ARBOR MI 48106/ (313) 769-6800
CHARLES G. MOORE/ NETWORK SERVICES INC./ 175 JACKSON PLAZA/ ANN ARBOR MI 48106/ (313) 426-2620
PAUL R. TEETOR/ OPER. SYS. GROUP/ ADP NETWORK SERVICES/ 175 JACKSON PLAZA/ ANN ARBOR MI 48106/ (313) 769-6800
DAVID LIPPINCOTT / INFORMATION CONTROL SYSTEMS/ 313 N. FIRST Sf REET/ ANN ARBOR MI 48107/ (313) 761-1600 EXT. 40
PAUL PICKELMANN/ 2217 CROSS/ 1440 HUBBARD ST./ ANN ARBOR MI 48109/ (313) 764-2121
LOUIS F. WOJNAROSKI/ MENTAL HEALTH RESEARCH INST./ U. OF MICHIGAN/ ANN ARBOR MI 48109/ (303) 763-1143
KARL L. ZINN/ CTR. FOR RESEARCH ON LEARNING & TEACHI/ UNIV. OF MICHIGAN/ 109 EAST MADISON STREET/ ANN ARBOR MI 48109
L. RICHARD LEWIS/ 5806 COOLIDGE ROAD/ DEARBORN MI 48127/ (313) 274-6871
GREGORY J. WINTERHALTER/ 3825 NORTH ZEEB/ DEXTER MI 48130
WILLIAM GROSKY/ MATH DEPT - COMPo SCI. SECTION/ WAYNE STATE UN IVERSITY/ DETROIT MI 48202
RONALD G. MOSIER/ 17596 WILDEMERE/ DETROIT MI 48221/ (313) 956-2417
R. NEIL FAIMAN JR./ 8235 APPOLINE/ DETROIT MI 48228/ (513) 834-3065
MARK HERSEY/ 323 VILLAGE DRIVE APT. 534/ EAST LANSING MI 488231 (517) 351-5703 (HOME)/ (517) 355-1764 (OFFICE)
THOMAS W. SKELTON/ 315 WEST SAGINAW STREET/ EAST LANSING MI 48~23/ (517) 332-4368/ (517) 351-2530
THOMAS c. SOCOLOFSKY/ SYSTEMS RESEARCH INC/ 241 E. SAGINAW/ EAST LANSING MI 48823/ (517) 351-2530 (OFFICE)/ (517) 351-2530 (HOME)
JOHN B. EULENBERG/ COMPo SCI. DEPT./ MICHIGAN STATE U/ EAST LANSING MI 48824/ (517) 353-0831
STEVEN L. HUYSER/ COMPUTER LABORATORY/ MICHIGAN STATE U/ EAST LANSING MI 48824/ (517) 353-1800
MARK RIORDAN/ USER SERVICES/ COMPUTER LABORATORY/ MICHIGAN STATE UNIVERSITY/ EAST LANSING MI 48824/ (517) 353-1800
H. G. HEDGES/ DEPT. OF COMPo SCI./ MICHIGAN STATE U/ E. LANSING MI 48824/ (517) 353-6484
ALLAN MOLUF/ 3410 DAVIDSON/ LAMSING MI 48910/ (517) 393-8639
MARK T. O'BRYAN/ PRESTIGE APARTMENT E/ 421 STANWOOD DRIVE/ KALAMAZOO MI 49007
MARK C. KERSTETTER/ DEPT. OF MATHEMATICS/ WESTERN MICHIGAN UNI VERSITY/ KALAMAZOO MI 49008/ (616) 383-6165
JACK R. MEAGHER/ COMPUTER SCIENCE AND MATHEMATICS/ WESTERN MICHIGAN UNIV./ KALAMAZOO MI 49008/ (616) 383-0095
GORDON A. STEGINK/ COMPUTER CENTER/ 325 MANITOU HALL/ GRAND VALLEY STATE COLLEGE/ ALLENDALE MI 49401/ (616) 895-6611 X571
GEORGE O. STRAWN/ DEPT. OF COMPUTER SCIENCE/ IOWA STATE U/ AMES IA 50011/ (515) 294-2259
TOM MOBERG/ ACADEMIC COMPUTING/ GRINNELL COLLEGE/ GRINNELL IA 50112/ (515) 236-6521
LARRY CRANE/ ELECTRONIC DATA SYSTEMS CORP./ 1200 LOCUST/ DES MOINES IA 50309
MIKE BURGHER/ DIAL COMPUTER CENTER/ DRAKE UNIVERSITY/24TH AND CARPENTER/ DES MOINES IA 50311/ (515) 271-3918
EDWARD o. THORLAND/ COMPUTER CENTER/ LUTHER COLLEGE/ DECORAH IA 52101/ (319) 387-1043
ATTN: SERIALS DEPT./ UNIVERSITY LIBRARIES/ UNIVERSITY OF IOWA/ IOWA CITY IA 52242
ATTN: UCC LIBRARIAN/ UNIVERSITY COMPUTER CENTER/ LCM/ UNIVERSITY OF IOWA/ IOWA CITY IA 52242/ (319) 353-3170
MICHAEL A. BEAVER/ INSTRUMENTS DIVISION/ BUNKER RAMO/ 902 WISCONSIN ST./ DELAVEN WI 53115
JAMES S. BOTIC/ POST OFFICE BOX 423 MS/51/ JOHNSON CONTROLS INC,/ 507 EAST MICHIGAN STREET/ MILWAUKEE WI 53201/ (414) 276-9200
W. A. HINTON/ 3469 N. CRAMER ST./ MILWAUKEE WI 53211/ (414) 964-2671 (HOME)/ (414) 963-4005 (OFFICE)
BROOKS DAVID SMITH/ 4473 N. NEWHALL ST./ SHOREWOOD WI 53211/ (414) 963-6413
JOHN G. DOBNICK/ 3171 S. 83 ST./ MILWAUKEE WI 53219/ (414) 963- 5727
HERMAN BERG/ 108 E. DAYTON/ MADISON WI 53703/ (608) 255-8545
KEVIN W. CARLSON/ 1820 SUMMIT AVE/ MADISON WI 53705/ (608) 238,-3441
EDWARD H. HARRIS/ SYNNOVATION INC./ 2106 BASCOM ST./ MADISON WI 53705/ (608) 233-1984
ATTN: FRIEDA S. COHEN/ ACADEMIC COMPUTING CENTER/ U OF WISCONS·IN/ 1210 W. DAYTON ST./ MADISON WI 53706
CHARLES N. FISCHER/ MACC/ U OF WISCONSIN/ 1210 WEST DAYTON ST. 1 MADISON WI 53706/ (608) 262-7870
FRANK H. HORN/ ACADEMIC COMPUTER CENTER/ U OF WISCONSIN/ 1210 WEST DAYTON STREET/ MADISON WI 53706/ (608) 262-9841
RICHARD LEBLANC/ MADISON ACADEMIC COMPUTER CENTER/ U OF WISCONSIN/ 1210 W. DAYTON STREET/ MADISON WI 53706/ (608) 262-0138
ED GLASER/ COMPUTING SERVICES/ U OF WISCONSIN - GREEN BAY/ GREEN BAY WI 54302/ (414) 465-2309
DAVID A. NUESSE/ DEPARTMENT OF COMPUTER SCIENCE/ U OF WISCONSIN - EAU CLAIRE/ EAU CLAIRE WI 54701/ (715) 836-2526
RUDOLPH C. POLENZ/ INFORMATION SYSTEMS AND COMPUTING SERV/ U OF WISCONSIN - EAU CLAIRE/ EAU CLAIRE WI 54701/ (715) 836-4428
BRUCE A. PUMPLIN/ DEPT OF COMPUTER SCIENCE/ U OF WISCONSIN - EAU CLAIRE/ EAU CLAIRE WI 54701/ (715) 836-2315
CARL HENRY/ COMPUTER CENTER/ CARLETON COLLEGE/ NORTHFIELD MN 5)057/ (507) 645-4431 XS04
TIMOTHY W. HOEL/ ACADEMIC COMPUTER CENTER/ ST. OLAF COLLEGE/ NORTHFIELD MN 55057/ (507) 663-3096
CHRIS BOYLAN/ 14620 BISCAYNE WAY/ ROSEMOUNT MN 55068/ (612) 423-1922
JOHN E. COLLINS/ BLDG 235 F247/ 3M CENTER/ ST. PAUL MN 55101/ (612) 736-0778
GLENN FISHBINE/ GCCPC/ CCP/ 444 LAFAYETTE RD./ ST. PAUL MN 55101/ (612) 296-7543
GEOFF WATTLES/ P.O. BOX 4244/ ST. PAUL MN 55104/ (612) 331-7087
GEORGE GONZALEZ/ 1435 W. JESSAMINE APT. #305/ ST. PAUL MN 5510~/ (612) 647-0976
JAMES KREILICH/ 1408 ALBANY AVE./ ST. PAUL MN 55108/ (612) 644-1375
GLENN MILLER/ 2317 N. HENRY ST./ N. ST. PAUL MN 55109/ (612) 777-2483
DARRELL L. WONDRA/ ARH254/ CONTROL DATA CORP./ 4201 LEXINGTON AVE. N./ ARDEN HILLS MN 55112/ (612) 482-2542 (OFFICE)/ (612) 484-3804 (HOME)
PAUL K. HUNTWORK/ CONTROL DATA CORP./ 4201 LEXINGTON AVE. N./ ST. PAUL MN 55112/ (612) 482-2772
RUSS PETERSON/ ARH254/ CONTROL DATA CORP./ 4201 N. LEXINCTON/ ST. PAUL MN 55112/ (612) 482-2548
MARK RUSTAD/ 585 HARRIET AVE #213/ ST. PAUL MN 55112/ (612) 433-0589
KEVIN HAUSMANN/ MINNESOTA EDUCATIONAL COMPUTING CONSOR/ 252U II. BROADWAY/ LAUDERDALE MN 55113/ (612) 376-1119
SUE PETERSON/ COMTEN INC./ 1950 W. COUNTY RD. B2/ ROSEVILLE MN )5113/ (612) 633-8130 X249
ROBERT D. VAVRA/ 741 TERRACE DRIVE/ ROSEVILLE MN 55113/ (612) 483-6123
STEVEN W. WEINGART/ MS 4753/ SPERRY-UNIVAC/ 2276 HIGHCREST DRIVE/ ROSEVILLE MN 55113/ (612) 633-6170 X3748
ATTENTION: ROBERT E. NOVAK/ DSPL DEVELOPMENT GROUP/ SPERRY UNIVAC/ UNIVAC PARK / P.O. BOX 3525/ ST. PAUL MN 55165/ (612) 456-5551

(I)

rn
--0

-I

rn

::s:
tx:l

rn
:;0

55165
55165
55165
55303
55337
55343
55343
55343
55401
55401
55404
55404
55406
55406
55408
55409
55413
55413
55413
55414
55414
55414
55414
55414
55416
55417
55420
55421
55421
55422
55423
55424
55424
55425
55427
55427
55431
55435
55437
55440
55440
55440
55440
55440
55440
55440
55440
55440
55440
55441
55441
55454
55454
55454
55455
55455
55455
55455
55455
55455
55455
55455
55455
55455

ROBERT A. LAWLER/ MS U2M23/ UNIVAC PARK/ P.O. BOX 3525/ ST. PAUL MN 55165/ (612) 456-3107
LEO J. SLECHTA/ DSD/ SPERRY UNIVAC/ BOX 3525 MS UIU25/ ST. PAUL MN 55165/ (612) 456-2743
RAYMOND YOUNG/ M.S. U2U22/ SPERRY UNIVAC/ F.O. BOX 3525/ ST. PAUL MN 55165/ (612) 456-5517
DAVID HELFINSTINE/ 1136 5TH AVENUE SOUTH/ ANOKA MN 55303/ (612) 421-8964
HAROLD DE VORE/ 13401 MORGAN AVE. SOUTH APT. 321/ BURNSVILLE MN 55337/ (701) 746-6977
PAUL CHRISTOPHERSON/ M.S. MNll-1611/ HONEYWELL INC./ 600 SECOND STREET N./ HOPKINS MN 55343/ (612) 542-6438
GENE H. OLSON/ 421 COUNTY ROAD 3 APT 512/ HOPKINS MN 55343/ (612) 938-2454/ 941-5560 X429 (WORK)
ROSS D. SCHMIDT/ MN 11-2120/ HONEYWELL INC./ 600 2ND ST. NO.E.} HOPKINS MN 55343/ (612) 542-6741
MARK BILODEAU/ ENGINEERING SYSTEMS 4TH FLOOR/ NORTHERN STATES POWER/ 414 NICOLLET MALL/ MINNEAPOLIS MN 55401/ (612) 330-6749/ (612) 330-5899
CHRIS EASTLUND/ ENGINEERING SYSTEMS 4TH FLOOR/ NORTHERN STATES POWER/ 414 NICOLLET MALL/ MINNEAPOLIS MN 55401/ (612) 330-6749/ (612) 330-5899
RICK L. MARCUS/ 1609 11TH AVE. S./ MINNEAPOLIS MN 55404/ (612) 339-1638
JOHN STANLEY/ 607 S. 9TH ST./ MINNEAPOLIS MN 55404/ (612) 339-1728
BRUCE M. SORLIE/ 2810 29TH AVE. S./ MINNEAPOLIS MN 55406/ (612) 729-4435
INDULIS VALTERS/ 2810 E. 22ND STREET/ MINNEAPOLIS MN 55406/ (612) 341-4430 (HOME)
ABDUL RASAQ BELLO/ P.O. BOX 8681/ MINNEAPOLIS MN 55408/ (612) 330-4106
DON HAMNES/ 4215 PLEASANT AVE. SO./ MINNEAPOLIS MN 55409/ (612) 823-3030
WILLIAM C. MARSHALL/ SYSTEMS AND RESEARCH CENTER/ MN-17-2321/ HONEYWELL INC./ 2700 RIDGWAY PARKWAY/ MINNEAPOLIS MN 55413/ (612) 378-4501
BELLE SHENOY/ MS MN17-1649/ HONEYWELL INC./ 2600 RIDGWAY ROAD/ MINNEAPOLIS MN 55413/ (612) 378-5418
STANLEY C. VESTAL/ MS 2340/ HONEYWELL INC./ 2600 RIDGWAY PKWY. 1 MINNEAPOLIS MN 55413/ (612) 378-5046
ATTN: KAPPA ETA KAPPA/ 330 11TH AVE. S.E./ MINNEAPOLIS MN 55414/ (612) 331-2133
KEVIN R. DRISCOLL/ 330 SE 11TH AVENUE/ MINNEAPOLIS MN 55414/ (b12) 331-2133
JOHN FUNG/ 425 13TH AVE S.E. #1502/ MINNEAPOLIS MN 55414/ (612) 376-5464 (OFFICE)/ (612) 378-0427 (HOME)
GARY M. JACKSON/ 1008 27TH AVE. SE. APT.A/ MINNEAPOLIS MN 55414/ (612) 378-2178
WALT PERKO/ 727 15TH AVE. S.E./ MINNEAPOLIS MN 55414/ (612) 331-6984
WARREN STENBERG/ 2012 CEDAR LARE PKWY/ MINNEAPOLIS MN 55416/ (b12) 920-7465
KEITH HAUER-LOWE/ 4819 COLUMBUS AVE. SO./ MINNEAPOLIS MN 554171 (612) 633-6170 X3362 (WORK)/ (612) 824-8026 (HOME)
RICHARO HENDRICKSON/ CRAY RESEARCH INC./ 7850 METRO PARKWAY SUITE 213/ MINNEAPOLIS MN 55420/ (612) 854-7472
STEVEN N. TRAPP/ 5020 MULCARE DR/ COLUMBIA HTS. MN 55421/ (612) 571-5020
WILLIAM T. WOOD/ 3820 MACALASTER DR. NE #31i/ MINNEAPOLIS MN 55421/ (612) 788-2390
CALVIN STEVENS/ 4936 SORELL AVE. N./ MINNEAPOLIS MN 55422/ (612) 588-7724
KEITH BOLSON/ 7425 17TH AVE. SO./ RICHFIELD MN 55423/ (612) 86b-4658
JOHN ALSTRUP/ INTERDATA/ 4620 VALLEY VIEW ROAD/ EDINA MN 554241 (612) 854-4264
ROBERT A. STRYK/ 5441 HALIFAX LANE/ EDINA MN 55424/ (612) 920-~434 (HOME)/ (612) 887-4356 (OFFICE)
RON THOMAS/ DATA 100 CORPORATION/ 7725 WASHINGTON AVE. S./ MINNEAPOLIS MN 55425/ (612) 941-6500
RICHARD HOYME/ 1404 KELLY DR. N./ MINNEAPOLIS MN 55427/ (612)~45-4642
HUGO MEISSER/ 3021 WISCONSIN AVE. N./ MINNEAPOLIS MN 55427/ (612) 544-2349
JACK ANDERSON/ HART ENGINEERING CO. INC./ 9341 PENN AVENUE SOUTH/ BLOOMINGTON MN 55431/ (612) 881-8464
JONATHON R. GROSS/ CYTROL INC./ 4510 W. 77TH ST./ EDINA MN 55435/ (612) 835-4884
DENNIS NICKOLAI/ SOUTHGATE OFFICE PLAZA/ CONTROL DATA CORPORATION/ 5001 W. 80TH ST./ BLOOMINGTON MN 55437/ (612) 830-6609
RANDALL W. HANSEN/ HQS06B/ CONTROL DATA CORPORATION/ P.O. BOX 0/ MINNEAPOLIS MN 55440/ (612) 853-5466
JON HANSON/ SYSTEM DEVELOPMENT/ DATA 100 CORP/ BOX 1222/ MINNEAPOLIS MN 55440/ (612) 941-6500
GENE MARTINSON/ SYSTEM DEVELOPMENT/ DATA 100 CORP/ BOX 1222/ MINNEAPOLIS MN 55440/ (612) 941-6500
DOUG PIHL/ SYSTEM DEVELOPMENT/ DATA 100 CORP/ BOX 1222/ MINNEAPOLIS MN 55440/ (612) 941-6500
BILL SIMMONS/ SYSTEM DEVELOPMENT/ DATA 100 CORP/ BOX 1222/ MINNEAPOLIS MN 55440/ (612) 941-6500
RICHARD SPELLERBERG/ SYSTEM DEVELOPMENT/ DATA 100 CORP/ BOX 1222/ MINNEAPOLIS MN 55440/ (612) 941-6500
JERRY STODDABD/ SYSTEM DEVELOPMENT/ DATA 100 CORP/ BOX 1222/ MINNEAPOLIS MN 55440/ (612) 941-6500
TOM URSIN/ SYSTEM DEVELOPMENT/ DATA 100 CORP/ BOX 1222/ MINNEAPOLIS MN 55440/ (612) 941-6500
JAMES A. VELLENGA/ SYSTEM DEVELOPMENT/ DATA 100 CORP/ BOX 12221 MINNEAPOLIS MN '55440/ (612) 941-6500 X227
JIM VERNON/ SYSTEM DEVELOPMENT/ DATA 100 CORP/ BOX 1222/ MINNEAPOLIS MN 55440/ (612) 941-6500
DAVID C. MESSER/ 3205 N. HARBOR LANE APT 4301/ PLYMOUTH MN 55441
MIKE TILLER/ 2501 N. LANCASTER LN. #178/ PLYMOUTH MN 55441/ (612) 546-6687
TIM BONHAM/ D605/1630 S. 6TH ST. / MINNEAPOLIS MN 55454/ (612) 339-4405
JACK LAFFE/ 320 19TH AVE. S./ MINNEAPOLIS MN 55454/ (612) 336-4946
R. K. NORDIN/ 1615 SOUTH 4TH ST. APT.M3607/ MINNEAPOLIS MN 554541 (612) 339-5232 (HOME)/ (612) 482-3751 (OFFICE)
ATTENTION: PAUL C. SMITH/ CONSULTING GROUP ON INSTRUCTIONAL DESI/ 205 ELLIOTT HALL/ U OF MINNESOTA/ EAST BANK/ MINNEAPOLIS MN 55455/ (612) 373-5352
ATTENTION: STEVE REISMAN/ SCH. OF DENTISTRY/CLINICAL SYS. DIV. 1 8-440 HEALTH SCIENCE UNIT A/ U OF MINNESOTA/ EAST BANK/ MINNEAPOLIS MN 55455
(612) 376-4131
ATTN: COMPUTER SCIENCE DEPT./ 114 LIND HALL/ U OF MINNESOTA/ EAST BANK/ MINNEAPOLIS MN 55455/ (612) 373-0132
ATTN: REFERENCE ROOM/ UNIVERSITY COMPUTER CENTER/ 227 EXP ENGR 1 U OF MINNESOTA/ EAST BANK/ MINNEAPOLIS MN 55455/ (612) 373-7744
SCOTT BERTlLSON/ UNIVERSITY COMPUTER CENTER/ 227 EXP. ENGR./ U OF MINNESOTA/ UINNEAPOLIS MN 55455/ (612) 376-5262 (WORK)/ (612) 729-0059 (HOME)
BRADFORD E. BLASING/ 1308 'CENTENNIAL HALL/ UNIVERSITY OF MINNESOTA/ EAST BANK/ MINNEAPOLIS MN 55455/ (612) 376-6053
KEN BORGENDALE/ C.SCI. DEPT./ 114 LIND HALL/ U OF MINNESOTA/ E,AST BANK/ MINNEAPOLIS MN 55455/ (612) 824-3389
JEFFREY J. DRUMMOND/ UNIVERSITY COMPUTER CENTER/ LAUDERDALE/ U OF MINNESOTA/ MINNEAPOLIS MN 55455/ (612) 373-4573
RON DYKSTRA/ WEST BANK COMPUTER CENTER/ 93B BLEGEN HALL/ UNIVERSITY OF MINNESOTA/ WEST BANK/ MINNEAPOLIS MN 55455/ (612) 373-3608
JOHN T. EASTON/ SSRFC/ 25E BLEGEN HALL/ U OF MINNESOTA/ WEST BANK/ MINNEAPOLIS MN 55455/ (612) 373-5599/ (612) 373-7525

en
rn
""0
--I

rn

""0

J>
G"l

rn

......
00

55455
55455
55455
55455
55455
55455
55455
55455
55455
55455
55455
55455
55455
55455
55455
55455
55455
55455
55455
55455
55455
55455
55455
55455
55455
55455
55455
55455
55455
55455
55455
55455
55455
55455
55792
55812
55812
55901
55987
56201
56267
56301
56301
56301
56560
58202
58501
59715
59717
59801
60015
60030
60076
60201
60201
60201
60202
60439
60439
60532
60604
60625
61738
61801
61801
61801

LINCOLN FETCHER/ UNIVERSITY COMPUTER CENTER/ 227 EXP. ENCR./ U OF MINNESOTA/ MINNEAPOLIS MN 55455/ (612) 376-1637
KEVIN FJELSTED/ UNIVERSITY COMPUTER CENTER/ 227 EXP ENGR/ U OF MINNESOTA/ EAST BANK/ MINNEAPOLIS MN 55455/ (612) 373-4181
K. FRANKOWSKI/ COMPUTER SCIENCE DEPARTMENT/ 110H LIND HALL/ U OF MINNESOTA/ EAST BANK/ MINNEAPOLIS MN 55455/ (612) 373-7591
SARA K. GRAFFUNDER/ UNIVERSITY COMPUTER CENTER/ 227 EXP. ENGR. I U OF MINNESOTA/ MINNEAPOLIS MN 55455/ (612) 376-5262
KRISTINA GREACEN/ C.SCI. DEPT. / 114 LIND HALL/ U OF MINNESOTA/ EAST BANK/ MINNEAPOLIS MN 55455
JOEL M. HALPERN/ UNIVERSITY COMPUTER CENTER/ 227 EXP. ENGR./ U OF MINNESOTA/ EAST BANK/ MINNEAPOLIS MN 55455/ (612) 373-4181
BRIAN HANSON/ UNIVERSITY COMPUTER CENTER/ 227 EXP. ENGR./ U OF MINNESOTA/ EAST BANK/ MINNEAPOLIS MN 55455/ (612) 376-5262 (OFFICE)
THEA D. HODGE/ UNIVERSITY COMPUTER CENTER/ 227 EXP. ENGR./ U OF MINNESOTA/ EAST BANK/ MINNEAPOLIS MN 55455/ (612) 373-4599
TIMOTHY J. HOFFMANN/ UNIVERSITY COMPUTER CENTER/ 227 EXP. ENGR ./ U OF MINNESOTA/ MINNEAPOLIS MN 55455/ (612) 926-9330 (HOME)/ (612) 376-5262 (WORK)
PETER YAN-TEK HSU/ 475 FRONTIER HALL/ U OF MINNESOTA/ EAST BANK/ MINNEAPOLIS MN 55455/ (612) 373-7052
PATRICK L. JARVIS/ UNIVERSITY COMPUTER CENTER/ 227 EXP. ENGR./ U OF MINNESOTA/ MINNEAPOLIS MN 55455/ (612) 376-1763
GEORGE D. JELATIS/ BOX 15 MAYO/ U OF MINNESOTA/ EAST BANK/ MINNEAPOLIS MN 55455/ (612) 373-8941
MITCHELL R. JOELSON/ SSRFC/ 25 BLEGEN HALL/ U OF MINNESOTA/ WE ST BANK/ MINNEAPOLIS MN 55455/ (612) 373-9914/ (612) 373-5599
DAN LALIBERTE/ UNIVERSITY COMPUTER CENTER/ 227 EXP. ENGR./ U 0 F MINNESOTA/ EAST BANK/ MINNEAPOLIS MN 55455/ (612) 373-4181
LAWRENCE A. LIDDIARD/ UNIVERSITY COMPUTER CENTER/ 227 EXP. ENG. BLDG./ U OF MINNESOTA/ EAST BANK/ MINNEAPOLIS MN 55455/ (612) 373-5239
DENNIS R. LIENKE/ UNIVERSITY COMPUTER CENTER/ 227 EXP. ENGR./ U OF MINNESOTA/ EAST BANK/ MINNEAPOLIS MN 55455/ (612) 373-1572
SHIHTA LIN/ UNIVERSITY COMPUTER CENTER/ 227 EXP ENGR/ U OF MIN NESOTA/ EAST BANK/ MINNEAPOLIS MN 55455/ (612) 373-4886
JOHN E. LIND/ 139 TERRITORIAL HALL/ UNIVERSITY OF MINNESOTA/ EAST BANK/ MINNEAPOLIS MN 55455
MICHAEL MEISSNER/ C.SCr. DEPT./ 114 LlNO HALL/ U OF MINNESOTA/ EAST BANK/ MINNEAPOLIS MN 55455
ANDY MICKEL/ UNIVERSITY COMPUTER CENTER/ 227 EXP. ENGR./ U OF MINNESOTA/ EAST BANK/ MINNEAPOLIS MN 55455/ (612) 376-7290
JAMES F. MINER/ SSRFC/ 25 BLEGEN HALL/ U OF MINNESOTA/ WEST BANK/ MINNEAPOLIS MN 55455/ (612) 373-9916
TOM MOHER/ COMPUTER SCIENCE DEPT./ 114 LIND HALL/ UNIV. OF MINNESOTA/ EAST BANK/ MINNEAPOLIS MN 55455/ (612) 373-7746
JOHN NAUMAN/ 901 MIDDLEBROOK HALL/ U OF MINNESOTA/ WEST BANK/ MINNEAPOLIS MN 55455/ (612) 376-6596
DAVID PERLMAN/ COMPUTER SCIENCE DEPARTMENT/ 114 LIND HALL/ U 0 F MINNESOTA/ EAST BANK/ MINNEAPOLIS MN 55455/ (612) 373-7581
MICHAEL PRIETULA/ MISRC/ 93 BLEGEN HALL/ U OF MINNESOTA/ WEST BANK/ MINNEAPOLIS MN 55455/ (612) 373-4973
TIMOTHY J SALOl UNIVERSITY COMPUTER CENTER/ LAUDERDALE/ U OF MINNESOTA/ MINNEAPOLIS MN 55455/ (612) 376-5607
BOB SCARLETT/ PHYSICS DEPT./ 148 PHYSICS/ U OF MINNESOTA/ EAST BANK/ MINNEAPOLIS MN 55455/ (612) 373-0243
G. MICHAEL SCHNEIDER/ C.SCI. DEPT./ 114 LIND HALL/ U OF MINNESOTA/ EAST BANK/ MINNEAPOLIS MN 55455/ (612) 373-7582
JOHN P. STRAIT/ UNIVERSITY COMPUTER CENTER/ 227 EXP. ENGR./ U OF MINNESOTA/ EAST BANK/ MINNEAPOLIS MN 55455/ (612) 376-7290
JOHN URBANSKI/ WEST BANK COMPUTER CENTER/ BLEGAN HALL/ U OF MI NNESOTA/ MINNEAPOLIS MN 55455/ (612) 377-3198/ (612) 373-3608 (WORK)
KAREN WAGGONER/ UNIVERSITY COMPUTER CENTER/ 129 SPACE SCIENCE CENTER - SICL/ U OF MINNESOTA/ EAST BANK/ MINNEAPOLIS MN 55455/ (612) 373-5168
WARREN J. WARWICK/ DEPT. OF PEDIATRICS/ BOX 184 MAYO/ U OF MIN NESOTA/ EAST BANK/ MINNEAPOLIS MN 55455/ (612) 373-8886
PETER H. ZECHMEISTER/ UNIVERSITY COMPUTER CENTER/ 227 EXP. ENGR./ U OF MINNESOTA/ EAST BANK/ MINNEAPOLIS MN 55455/ (612) 373-4181
ATTN: SSRFC LIBRARY/ SSRFC/ 25 BLEGEN HALL/ U OF MINNESOTA/ WEST BANK/ MINNEPOLIS MN 55455/ (612) 373-5599
DAVID SARANEN/ 117 7TH ST. SO./ VIRGINIA MN 55792/ (218) 741-1378
ATTENTION: DAN BURROWS/ UMO COMPUTER CENTER/ 178 M.W.ALWORTH HALL/ U OF MINNESOTA - DULUTH/ DULUTH MN 55812/ (218) 726-7587
MARK LUKER/ DEPT. OF MATH SCIENCES/ U OF MINNESOTA - DULUTH/ DULUTH MN 55812/ (218) 726-8240
L. W. YOUNGREN/ 1505 N.W. 41ST ST. APT. 18F/ ROCHESTER MN 55901/ (507) 285-9696
GERALD W. CICHANOWSKI/ DEPT. COMPUTER SCIENCE/ ST. MARY'S COLLEGE/ P.O. BOX 56/ WINONA MN 55987/ (507) 452-4430 X229
JAMES F. MARTINSON/ 1210 WILLMAR AVE/ WILLMAR MN 56201/ (612) 796-2342
ANDY LOPEZ/ COMPUTER CENTER/ U OF MINNESOTA - MORRIS/ MORRIS MN 56267/ (612) 589-1665 X321
LARRY GROVER/ 330 ANGUSHIRE APTS #127 RT 1/ ST. CLOUD MN 56301 I (612) 252-0290
PAUL HELVIG/ 314 4TH AVE. S./ ST. CLOUD MN 56301/ (612) 253-80~1
R. WARREN JOHNSON/ DEPT. OF MATH AND COMPo SCI./ ST. CLOUD STA TE U/ ST. CLOUD MN 56301/ (612) 255-2141
C R CORNER/ 514 SOUTH 9TH ST/ MOORHEAU MN 56560/ (218) 233-113 4
R. I. JOHNSON/ COMPo SCI. DEPT./ U OF NORTH DAKOTA/ BOX 8181 UNIVERSITY STATION I GRAND FORKS ND 58202/ (701) 177-4107
GARY J. BOOS/ 517 N. lTH STREET/ BISMARCK ND 58501/ (701) 223-0441 (WORK)
ATTN: COMPUTING CENTER/ MONTANA STATE UNIVERSITY/ BOZEMAN MT 59715
JAMES C. WILLIAMS/ COMPUTING CENTER/ MONTANA STATE UNIVERSITY/ BOZEMAN MT 59117/ (406) 994-3042
ATTN: COMPUTER SCIENCE DEPARTMENT/ UNIVERSITY OF MONTANA/ MISSOULA MT 59801/ (406) 243-2883
MARK S. NIEMCZYK/ HEWITT ASSOCIATES/ 102 WILMOT ROAD/ DEERFIELD IL 60015/ (312) 945-8000
DANIEL M. O'BRIEN/ 665 PIERCE CT./ GRAYSLAKE IL 60030
JOSEPH LACHMAN/ COMPUTER SYSTEMS AND SOFTWARE/ LACHMAN ASSOCIATES/ 8931 BRONX AVENUE/ SKOKIE IL 60016/ (312) 614-5685 (WORK)
FRED E. HALLARD/ 2139 LINCOLNWOOD DRIVE/ EVANSTON IL 60201/ (312) 491-0951 (HOME)/ (312) 822-7921 (WORK)
JOHN L. NORSTAD/ VOGELBACK COMPUTING CENTER/ NORTHWESTERN UNIVERSITY/ 2129 SHERIDAN RD./ EVANSTON IL 60201/ (312) 492-5369
ALBERT STEINER/ VOGELBACK COMPUTING CENTER/ NORTHWESTERN U/ 2129 SHERIDAN ROAD/ EVANSTON IL 60201/ (312) 492-3682
BRIT J. BARTTER/ 850A FOREST AVENUE/ EVANSTON IL 60202
MARTIN R. KRAlMER/ B221-B241/ ARGONNE NATIONAL LAB. / 9100 S. CASS AVE. / ARGONNE IL 60439/ (312) 739-7711 X3660
TRUMAN C. PEWITT/ APPLIED MATH DIVISION/ BLDG. 221/ ARGONNE NATIONAL LABORATORY/ 9700 SOUTH CASS AVENUE/ ARGONNE IL 60439/ (312) 739-7711
TERRY E. WEYMOUTH/ 4102 BEAU BIEN LANE EAST/ LISLE IL 60532
JONATHAN SACHS/ TRANS UNION SYSTEMS CORPORATION/ III WEST JACKSON BLVD/ CHICAGO IL 60604/ (312) 431-3330
DAVID E. CARLTON/ DEPT. OF INFO. SCI./ NORTHEASTERN ILLINOIS U I 5500 N. ST. LOUIS AVE./ CHICAGO IL 60625
MIKE LEMON/ 168 WEST THIRD STREET/ EL PASO IL 61138/ (309) 521-4342
ATTN: CONSULTING OFFICE/ COMPUTING SERVICES OFFICE/ 116 DIGITAL COMPUTER LAB'/ U OF ILLINOIS/ URBANA IL 61801/ (217) 333-6133
RICHARD HALOCCA/ 114B DIGITAL COMPUTER LAB/ U OF ILLINOIS/ URBANA IL 61801/ (217) 344-5284
ROGER GULBRANSON/ PHYSICS DEPT./ U OF ILLINOIS/ URBANA IL 61801/ (217) 344-4162 (HOME)/ (211) 333-3191 (OFFICE)

--0
):>
U')

n
):>

r

U')

rn
--0

-t

rn
:;:
tel

rn
;:0

I-'
lD

'.J
'.J

61801
61801
61820
61820
61820
62025
62708
62901
63110
63110
63188
64108
64108
64108
65401
66045
66045
66502
67220
68005
68022
68101
68123
68588
70118
70122
70125
70504
70504
70504
70504
70504
70504
70504
72143
72143
72204
73019
73034
73034
73070
73106
73110
74171
75023
75042
75075
75075
75080
75080
75081
75081
75081
75081
75081
75214
75220
75222
75222
75222
75229
75229
75234
75234
75240
75240

M. D. MICKUNAS! 297 DCL! U OF ILLINOIS! URBANA IL 61801! (217) 333-6351
CARLTON MILLS! MILLS INTERNATIONAL! 203 NORTH GREGORY! URBANA IL 61801! (217) 328-2436 (HOME)
ATTN: RECEIVING CLERK/ CERL - SOC! U.S. ARMY! P.O. BOX 4005! ClVU~AIGN IL 61820! (217) 352-6511
FRED P. BAKER! 302 E. GREGORY! CHAMPAIGN IL 61820! (217) 344-7)11
AVRUM ITZKOWITZ! 505 E. CLARK APT. 22! CHAMPAIGN IL 61820! (217) 359-9644 (HOME)! (217) 352-6511 (WORK)
WALT PARRILL! MID. ILLINOIS COMPUTER CO-OP/ COTTONWOOD ROAD! EDWARDSVILLE IL 62025! (618) 288-7268
DONALD S. KLETT! SANGAMON STATE UNIV.! SPRINGFIELD IL 62708! (217) 786-6549
THOMAS MELLMAN! 603-1!2 S. WASHINGTON! CARBONDALE IL 62901! (6 18) 457-2708
GERALD c. JOHNS! COMPUTER SYSTEMS LAB! WASHINGTON UNIVERSITY! 724 S. EUCLID AVENUE! ST. LOUIS Me 63110! (314) 454-3395
JOAN ZIMMERMAN! MUMPS USERS' GROUP! BIOMEDICAL COMPUTER LABORATORY! 700 SOUTH EUCLID! ST. LOUIS Me 63110! (314) 454-3364
LEE POTTS! ATTN: DRXAL-TL/ DARCOM ALMSA! P.O. BOX 1578! ST. LO'jiS MO 63188! (314) 268-2786
LARRY D. LANDIS! UNITED COMPUTING SYSTEMS! 2525 WASHINGTON! KANSAS CITY MO 64108! (816) 942-6063
JEFFERY M. RAZAFSKY! UNITED COMPUTING SYSTEMS INC./ 500 W. 26TO! STREET! KANSAS CITY Me 64108! (816) 221-9700
ROBERT TEISBERG! UNITED COMPUTING SYSTEMS! 2525 WASHINGTON! KAYSAS CITY MO 64108
HOWARD D. PYRON! MATH - C.SCI.! UOF MISSOURI - ROLLA! ROLLA MO 65401! (314) 341-4491
~HARLES J. BANGERT! COMPUTATION CENTER/ UNIVERSITY OF KANSAS! P.O. DRAWER 2007! LAWRENCE KS 66045! (913) 864-4291
STEVEN S. MUCHNICK/ DEPARTMENT OF COMPUTER SCIENCE! U OF KANSAS! LAWRENCE KS 66045
DAVID NEAL! 1534 COLLEGE AVE UC10/ MANHATTAN KS 66502/ (913) 539-9209/ (913) 532-6350 (WORK)
RODNEY M. BATES! 4732 N. GLENDALE/ WICHITA KS 67220! (316) 744-2847! (316) 687-5275
KEN RITCHIE! 508 BEAMAN DR.! BELLEVUE NE 68005/ (402) 291-7224 (HOME)! (402) 291-5400 (WORK)
JERRY L. RAY! 21320 OLDGATE RD.! ELKHORN NE 68022/ (402) 289-3381/ (402) 291-5400
LYNNE J. BALDWIN/ DEPT. OF MATH!COMP. SCI./ U OF NEBRASKA/ BOX 688/ OMAHA NE 68101! (402) 554-2836
RONALD G. MARTIN/ 12430 WALKER DRIVE/ OMAHA NE 68123! (402) 294-3253
SHARAO C. SETH! DEPT. OF COMPo SCI.! U OF NEBRASKA! LINCOLN NE 68588/ (402) 472-3488
D. B. KILLEEN! COMPUTER LAB! RICHARDSON BLDG.! TULANE UNIVERSITY! NEW ORLEANS LA 70118
FRED A. HOSCH! COMPUTER RESEARCH CENTER/ UNIV. OF NEW ORLEANS! NEW ORLEANS LA 70122/ (504) 283-0347
SAM HILLS/ 3514 LOUISIANA AVE. PKWY.! NEW ORLEANS LA 70125/ (504) 821-1737
ATTN: SERIALS DEPT.! U. OF S.W. LOUISIANA LIBRARIES! 302 E. ST. MARY BLVD.! LAFAYETTE LA 70504
WARREN JOHNSON! U OF SOUTHWESTERN LOUISIANA/ BOX 4-2770 USL STATION/ LAFAYETTE LA 70504! (318) 234-7349
ED KATZ/ COMPUTER SCIENCE DEPT.! U OF SOUTHWESTERN LOUISIANA! BOX 4-4330 USL STATION/ LAFAYETTE LA 70504/ (318) 233-6840/ (318) 233-6767
STEVE LANDRY/ COMPUTER CENTER/ U OF SOUTHWESTERN LOUISIANA! P.O. BOX 4-2770/ LAFAYETTE LA 70504/ (318) 234-7349
DAVID LANDSKOV! U OF SOUTHWESTERN LOUISIANA! USL BOX 4-4154! LAFAYETTE LA 70504/ (318) 234-7640
A. I. STOCKS! P.O. BOX 4-1039! USL STATION/ LAFAYETTE LA 70504/ (318) 233-3850 X538
TERRY M. WALKER/ cOMPUTER SCIENCE DEPT.! U OF SOUTHWESTERN LOUISIANA! P.O. BOX 4-4330/ LAFAYETTE LA 70504/ (318) 234-7640
MIKE CHALENBURG! HARDING COLLEGE/ BOX 4/ SEARCY AR 72143! (501) 268-6161 X322
JOHN NUNNALLY! HARDING COLLEGE/ BOX 744/ SEARCY AR 72143/ (501) 268-6161 X440
DENNIS DANCE/ COMPUTER SCIENCE DEPT.! UNIVERSITY OF ARKANSAS AT LITTLE ROCK! 33RD AND UNIVERSITY! LITTLE ROCK AR 72204! (501) 569-3252
RICHARD V. ANDREE! MATH DEPT./ U OF OKLAHOMA! NORMAN OK 73019! (405) 325-3410
MARY DEE FOSBERG/ 600 TIMBER LANE/ EDMOND OK 73034
ARDOTH H. WILSON! COMPUTER CENTER/ CENTRAL STATE UNIVERSITY/ EDMOND OK 73034/ (405) 341-2980 X321
RALPH HOWENSTINE/ P.O. BOX 1327/ NORMAN OK 73070
DAVID HUSNIAN! 1731 N.W. 29TH/ OKLAHOMA CITY OK 73106! (213) 521-1547
STEPHEN A. PITTS! 305 EAST JARMAN DRIVE! MIDWEST CITY OK 73110, (405) 732-4060
DAVE R. ELAND! ORAL ROBERTS UNIVERSITY/ 7777 SOUTH LEWIS! TULSA OK 74171/ (918) 492-6161
ROGER R. BATE! 3428 MISSION RIDGE! PLANO TX 75023/ (214) 238-3U52
JOE C. ROBERTS! 1529 MEADOWCREST! GARLAND TX 75042
GILBERT J. HANSEN! 3104 BONNIEBROOK DRIVE/ PLANO TX 75075/ (214) 423-7837
BRIAN W. JOHNSON! 1525 WESTLAKE! PLANO TX 75075! (214) 690-2885
ATTN: COMPUTER SERVICES - F01.3/ U. OF TEXAS AT DALLAS! P.O. BOX 688! RICHARDSON TX 75080/ (214) 690-2651
GEORGE LIGLER! 1000 W. SPRING VALLEY RD. APT. 263! RICHARDSON TX 75080! (214) 231-0825
FRANK DUNN! 1912 E. SPRING VALLEY ROAD! RICHARDSON TX 75081! (214) 231-3423
DAVE HABERMAN! 1806 AUBURN DRIVE! RICHARDSON TX 75081/ (214) 238-4446! (214) 238-5357
J. P. HARVELL! ADV. SYSTEMS DEVELOPMENT 410-260! ROCKWELL INTERNATIONAL/ 1200 N. ALMA ROAD! RICHARDSON TX 75081/ (214) 783-3854
DOUGLAS S. JOHNSON! 907 EDGEWOOD DR/ RICHARDSON TX 75081! (214) 238-4092 (TI)
KENNETH L. WILLIAMS! 614 CLEARWOOD DR.! RICHARDSON TX 75081/ (214) 341-6278
cu.KK A. SCHROEDER/ 6451 VANDERBILT! DALLAS TX 75214/ (214) 824- 0834
DEXTER COOK/ 3040 PARK LANE APT. 106/ DALLAS TX 75220! (214) 3)8-3794
DONNA K. DUNAWAY/ TEXAS INSTRUMENTS INC.! P.O. BOX 5936 - MS132/ DALLAS TX 75222! (214) 238-2635
TED FISHMAN! TEXAS INSTRUMENTS/ P.O. BOX 6015 (MS 3101)/ DALLAS TX 75222! (214) 689-4111 X330
DENNIS J. FRAILEY/ COMPo SCI. DEPT./ SOUTHERN METHODIST UNIV.! DALLAS TX 75222
DAVID E. BREEDING! HARRIS DATA COMM DIV! 11262 INDIAN TRAIL/ DALLAS TX 75229/ (214) 620-4294
JERRY SCHIEFFER/ HARRIS CORPORATION! 11262 INDIAN TRAIL/ DALLAS TX 75229! (214) 620-4237
T. W. EKBERG! HARRIS DATA COMMUNICATIONS! 11262 INDIAN TRAIL! DALLAS TX 75234/ (214) 620-4208
SAM LISOOK! HARRIS DATA COMMUNICATIONS DIV./ 11262 INDIAN TRAIL - P.O. BOX 44076! DALLAS TX 75234! (214) 620-4225
JOHN EARLS! SUITE 509W/ ARTHUR A. COLLINS INC./ 13601 PRESTON RD.! DALLAS TX 75240/ (214) 661-2928
GERALD A. SHOULTS! 13336 MAHAN RD. APT. 138/ DALLAS TX 75240! (214) 238-4458 (OFFICE)! (214) 234-2182 (HOME)

75243
75248
75275
75275
75275
75961
76011
76019
76114
76201
77001
77001
77001
77001
77027
77030
77043
77098
77550
77843
78284
78705
78712
78712
78712
78712
78712
78721
/8721
78723
78751
78753
78758
78767
78769
79015
79409
79409
79601
79601
80201
S0201
~0215

110225
110225
110302
80302
80302
1l0302'
80303
80303
80307
110309
~0309

110309
80309
110401
80523
110523
~0537

~2071
~3401
~3843

114112
114112

W. J. MEYERS/ 4-214S THE TIMBERS/ 13447 N. CENTRAL EXPR./ DALLAS TX 75243/ (214) 231-4869
JOE COINTMENT / 7709 QUEENS GARDEN DR. / DALLAS TX 75248/ (214) 387-0468
JOHN J. ALLAN 111/ CENTER FOR SPECIAL STUDIES/ 118 CARUTH HALL/ SOUTHERN METHODIST UNIV./ SCHOOL OF ENGR. AND APPL. SCIENCE/ DALLAS TX 75275
(214) 692-3058
GARY CEDERQUIST/ SOUTHERN METHODIST UNIV./ BOX 2112/ DALLAS TX 15275
JANET TAYLOR/ USER SERVICES/ COMPUTING CENTER/ SOUTHERN METHODIST UNIVERSITY/ DALLAS TX 75275/ (214) 692-2900
JESSE D. MIXON/ DEPT. OF COMPUTER SCIENCE/ STEPHEN F. AUSTIN STATE U/ P.O. BOX 6167 SFA STATION/ NACOGDOCHES TX 75961/ (713) 569-2508
MICHAEL SETTLE/ 751 WASHINGTON #115/ ARLINGTON TX 76011
PHILIP STEPHENSON/ COMPUTER TRAINING & DEVELOPMENT/ UNIV. OF TEXAS-ARLINGTON/ BOX 19608/ ARLINGTON TX 76019/ (817) 273-3666
RANDY BEST/ 5878 CALLOWAY DR. NORTH/ FT. WORTH TX 76114/ (817) 731-4974
EDWARD E FERGUSON/ 1222 AUSTIN AVE/ DENTON TX 76201/ (214) 231-9736
ATTENTION: COLIN G. CAMPBELL/ MS / 781/ TEXAS INSTRUMENTS/ P.O. BOX 1444/ HOUSTON TX 77001
S. BALASUBRAMANIAN/ SHELL DEVELOPMENT COMPANY/ PO BOX 481/ HOUSTON TX 77001/ (713) 667-5661
GINGER KELLY/ ICSA/ RICE UNIVERSITY/ HOUSTON TX 77001/ (713) 527-4965
TONEY MORELOCK/ TEXAS EASTERN TRANSMISSION/ P.O. BOX 2521/ HOUSTON TX 77001/ (713) 651-0161
CHARLES L. HETHCOAT 111/ C/O PIPELINE TECHNOLOGISTS INC./ P.O. BOX 22146/ HOUSTON TX 77027/ (713) 622-3456 X334 (WORK)/ (713) 626-7737 (HOME)
JAMES A. KENDALL/ MHMR/TRIMS/ TEXAS MEDICAL CENTER/ HOUSTON TX 77030/ (713) 797-1976
JOHN EARL CRIDER/ 2918 KEVIN LANE/ HOUSTON TX 77043/ (713) 665-3016
SCOTT K. WARREN/ ROSETTA ALGORITHMS/ 2414 BRANARD IID/ HOUSTON TX 77098/ (713) 526-0849
RUSSELL W ZEARS/ BIOMETRY LAB/ 449 ADMINISTRATION BLDG R7/ UNIVERSITY OF TEXAS MEDICAL BRANCH/ GALVESTON TX 77550/ (713) 765-1813
RICHARD HUBER/ DEPT. OF INDUSTRIAL ENGINEERING/ TEXAS A&M UNIVERSITY/ COLL. STATION TX 77843/ (713) 845-5531 X256
MIKE GREEN/ DATAPOINT CORPORATION/ 9725 DATAPOINT DRIVE/ SAN ANTONIO TX 78284/ (512) 699-7345
WILLETT KEMPTON/ 2512 SAN GABRIEL ST./ AUSTIN TX 78705
ATTN: DOROTHY SMITH - REFERENCE LIBRAR/ COMPUTATION CENTER/ U OF TEXAS AUSTIN/ AUSTIN TX 78712/ (512) 471-3242
WILHELM BURGER/ DEPT. OF COMPUTER SCIENCES/ 328 PAINTER HALL/ UNIV. OF TEXAS - AUSTIN/ AUSTIN TX 78712/ (512) 471-1902
TOM KEEL/ COMPUTATION CENTER/ UN IV • OF TEXAS - AUSTIN/ AUSTIN TX 78712
WAYNE SEIPEL/ BOX 8259 U.T. STA./ AUSTIN TX 78712/ (512) 472-1773
WALLY WEDEL/ COMPUTATION CENTER/ U OF TEXAS AUSTIN/ AUSTIN TX 78712/ (512) 471-3242
EDWARD P. STRITTER/ V BLDG./ MOTOROLA/ 3501 ED BLUESTEIN BLVD. / AUSTIN TX 78721/ (512) 928-2600 XS01
DONALD G. WEISS/ 3501 ED BLUESTEIN BLVD./ AUSTIN TX 78721/ (512) 928-2600
JOEL BONEY/ 6707 LASALLE/ AUSTIN TX 78723/ (512) 928-4649
DAVID W. HOGAN/ 4104 AVENUE F/ AUSTIN TX 78751
TERRY RITTER/ 12002B POLLYANNA AVE./ AUSTIN TX 78753/ (512) 92~-2600 XS32
WILLIAM L. COHAGAN/ SUITE 211/ S/B/P & C ASSOCIATES/ 8705 SHOAL CREEK BLVD./ AUSTIN TX 78758/ (512) 458-2276
ATTENTION: MILES RICKARD/ MS / 2201/ TEXAS INSTRUMENTS/ P.O. BOX 2909/ AUSTIN TX 78767
DAVID N. GRAY/ MS 2188/ TEXAS INSTRUMENTS/ P.O. BOX 2909/ AUSTIN TX 78769/ (512) 258-5121 X2377
HARRY P. HAIDUK/ DEPT. OF COMPo INFO. SYSTEMS/ WEST TEXAS STATE U/ CANYON TX 79015/ (806) 656-3966
MAURICE BALLEW/ COMPUTER SERVICES/ TEXAS TECH UNIVERSITY/ BOX 4519/ LUBBOCK TX 79409/ (806) 742-2900
LEONARD H. WEINER/ DEPT. OF MATH AND COMPo SCI./ TEXAS TECH. U/ P.O. BOX 4319/ LUBBOCK TX 79409/ (806) 742-2571
D. A. CAUGHFIELD/ 609 E. N. 21ST/ ABILENE TX 79601/ (915) 672-1604
JOHN TUCKER/ 628 E.N. 16TH ST./ ABILENE TX 79601/ (915) 673-2840
GREGG E. MARSHALL/ P.O. BOX 2784/ DENVER CO 80201/ (303) 499-1000 X4482
NORMAN T. OLSEN/ C/O AUTO TROL CORP./ 5650 N. PECOS/ DENVER CO 80201/ (303) 458-5900
DAVID M. WARNER/ 755 VISTA LANE/ LAKEWOOD CO 80215/ (303) 238-U900
ATTN: CHIEF BRANCH OF DATA SYSTEM SERV/ HSAC-POB 25367/ MINE ENFORCEMENT AND SAFETY ADM./ DENVER FEDERAL CENTER/ DENVER CO 80225/ (303) 234-3025
ATTN: LIBRARY/ 67 DENVER FEDERAL CENTER/ BUREAU OF RECLAMATION / DENVER CO 80225
ATTN: KARIN & MICHELE - PASCAL DISTRIB/ COMPUTING CENTER LIBRARY/ UNIVERSITY OF COLORADO/ 3645 MARINE STREET/ BOULDER CO 80302/ (303) 492-8131
HOWARD BUSSEY JR./ NATIONAL OCEANIC AND ATMOSPHERIC ADMIN/ BLDG. 1 RM 4557/ U.S. DEPARTMENT OF COMMERCE/ BOULDER CO 80302
RAYNER K. ROSICH/ OT/ITS/ U.S. DEPT. OF COMMERCE/ 325 BROADilAi / BOULDER CO 80302/ (303) 499-1000 X3109
JOE WATKINS/ 2895 18TH STREET/ BOULDER CO 80302/ (303) 443-859~
DENNIS R. ELLIS/ C/O CRAY RESEARCH/ 75 MANHATTAN DR. - SUITE #3/ BOULDER CO 80303/ (303) 499-3055
VINCENT B. WAYLAND/ C/O CRAY RESEARCH INC./ 75 MANHATTAN DRIVE SUITE 3/ BOULDER CO 80303/ (303) 499-3055
BRUCE K. RAY/ POLYMORPHIC COMPUTER SYSTEMS/ P.O. BOX 3581/ BOULDER CO 80307/ (303) 443-5362
LLOYD D. FOSDICK/ DEPARTMENT OF COMPUTER SCIENCE/ ECOT 7-7/ U OF COLORADO/ BOULDER CO 8309/ (303) 492-7514
GEORGE H. RICHMOND/ COMPUTING CENTER/ UNIVERSITY OF COLORADO/ 3645 MARINE STREET/ BOULDER CO 80309/ (303) 492-8131
TERRY L. SPEAR/ CLIPR/ E318 MUENZINGER/ UNIV. OF COLORADO/ BOULDER CO 80309/ (303) 492-6991
WILLIAM M. WAITE/ ELECTRICAL ENGINEERING DEPT./ SOFTWARE ENGINEERING GROUP/ UNIVERSITY OF COLORADO/ BOULDER CO 80309
HERBERT RUBENSTEIN/ 401 GARDEN STREET/ GOLDEN CO 8041/ (303) 278-3469
ATTN: USER SERVICES GROUP/ UNIVERSITY COMPUTER CENTER/ COLORADO STATE U/ FORT COLLINS CO 80523/ (303) 491-5133
DALE H. GRIT/ DEPARTMENT OF COMPUTER SCIENCE/ COLORADO STATE U/ FT. COLLINS CO 80523/ (303) 491-7033
JEFF EASTMAN/ CALCULATOR PRODUCTS DIV./ HEWLETT PACKARD/ P.O. BOX 301/ LOVELAND CO 80537
HENRY R. BAUER 111/ COMPUTER SCIENCE DEPT./ UNIVERSITY OF WYOMING/ BOX 3682/ LARAMIE WY 82071/ (307) 766-5134
KYU Y. LEE/ E.G.& G. IDAHO INC./ P.O. BOX 1625/ IDAHO FALLS ID ~3401/ (208) 526-0111 X321
JOHN DICKINSON/ DEPT. OF ELECTRICAL ENGR./ 214 BEL/ UNIV. OF IDAHO/ MOSCOW ID 83843/ (208) 885-6554/6555
ATTN: B1700 PROTEUS PROJECT/ COMPUTER SCIENCE DEPT./ 3160 MEB/ U OF UTAH/ SALT LAKE CIT UT 84112/ (801) 581-8224
MARTIN L GRISS/ COMPUTER SCIENCE DEPT/ U OF UTAH/ SALT LAKE CIT UT 84112/ (801) 581-6542

~4112

~4112
~4112
~4601

~4601
~4602
~4602
~5061
~5260
~5281
~5721
~5726
~5726

•

~5731
~6301
~7002
~7106

~7109
~7114

87115
IS 71 15
87115
~7117
~7544
~7545
~7545

~7545
~7801

87801
~7801
~8003
~8003

~9154
~9154
~9507
~9507

89509
90007
90007
90009
90020
90024
90024
90024
90036
90048
90064
90066
90068
90230
90260
90274
90274
90278
90278
90278
90278
90291
90403
90501
90503
90746
91016
91101
91103
91107

M. A. KLEINERT/ COMPo SCI. DEPT./ 3160 MERRILL ENG. BLDG./ U OF UTAH/ SALT LAKE CIT UT 84112
GARY LINDSTROM/ COMPUTER SCIENCE DEPT./ U OF UTAH/ SALT LAKE CIT UT 84112/ (801) 581-8224
ED SHARP/ COMPUTER CENTER/ U OF UTAH/ SALT LAKE CIT UT 84112/ (801) 581-6802
DENNIS FAIRCLOUGH/ EYRING RESEARCH INSTITUTE/ 1455 WEST 820 NORTH/ PROVO UT 84601/ (801) 375-2434
PAUL GODFREY/ 41 SOUTH 500 WEST/ PROVO UT 84601/ (801) 377-4331
THEODORE A. NORMAN/ COMPo SCI. DEPT./ BRIGHAM YOUNG UNIVERSITY/ PROVO UT 84602/ (801) 374-1211 X3027
RICHARD ORRAN/ ELECTICAL ENGINEERING DEPT/ 459 ESTB/ BRIGHAM YOUNG UNIVERSITY/ PROVO UT 84602/ (801) 374-1211 X4012
E. W. ERRICKSON/ P.O. BOX 11472/ PHOENIX AZ 85061/ (602) 242-3420
DENNIS KODlMER/ SUITE 100/ TERAK CORPORATION/ 14425 N. SCOTTSDALE RD./ SCOTTSDALE AZ 85260/ (602) 991-1580
BRIAN D. LOCKREY/ COMPUTER SERVICES ECA-109/ ARIZONA STATE UNIVERSITY/ TEMPE AZ 85281/ (602) 965-7327
PATRICK PECORARO/ UNIVERSITY COMPUTER CENTER/ U OF ARIZONA/ TUCSON AZ 85721/ (602) 884-2901
R. W. MILKEY/ KITT PEAK NATIONAL OBSERVATORY/ P.O. BOX 26732/ TUCSON AZ 85726/ (602) 327-5511
W. RICHARD STEVENS/ KITT PEAK NATIONAL OBSERVATORY/ P.O. BOX 26732/ TUCSON AZ 85726/ (602) 327-5511
JOHN E. WAHL/ P.O. BOX 18078/ TUCSON AZ 85731/ (602) 747-0700 X307
NEAL H. CHAMPION/ 435 S. GRANITE/ PRESCOTT AZ 86301
TOM SANDERSON/ RFD 1 BOX 459/ BELEN NM 87002
BOB WALSH/ 817 LAFAYETTE DR. NE/ ALBUQUERQUE NM 87106/ (505) 268-1654
DON H. ROWLAND/ 5805 TORREON DR./ ALBUQUERQUE NM 87109/ (505) 1S21-9207 (HOME)/ (505) 264-9149 (OFFICE)
ATTENTION: ARMENELLA VINSON/ E.G. & G. INC./ PO BOX 10218 - ALAMEDA STA./ ALBUQUERQUE NM 87114/ (505) 898-8000 EXT 246
ALFRED J. HULBERT/ INHALATION TOXICOLOGY RESEARCH INST. / P.O. BOX 5890/ ALBUQUERQUE NM 87115/ (505) 264-2030
BRUCE LINK/ DIVISION 1712/ SANDIA LABORATORIES/ ALBUQUERQUE NM ~7115
NANCY RUIZ/ ORG. 5166/ SANDIA LABS/ ALBUQUERQUE NM 87115/ (505) 264-3690
ATTN: AIR FORCE WEAPONS LABORATORY/ DYM (HARRY M. MURPHY JR.)/ KIRTLAND AFB NM 87117/ (505) 264-9317
KAY A. HANSBOROUGH/ 2377B 45TH ST./ LOS ALAMOS NM 87544/ (505) 662-9369 (HOME)/ (505) 667-5275 (OFFICE)
BILL BUZBEE/ LOS ALAMOS SCIENTIFIC LABORATORY/ C-DO MS-260/ UNIVERSITY OF CALIFORNIA/ P.O. BOX 1663/ LOS ALAMOS NM 87545
ROBERT T. JOHNSON/ C-11 MAIL STOP 296/ LOS ALAMOS SCIENTIFIC LABORATORY/ P.O. BOX 1663/ LOS ALAMOS NM 87545/ (505) 667-5014
JOHN MONTAGUE/ GROUP C11/ MAIL STOP 296/ LOS ALAMOS SCIENTIFIC LABORATORY/ LOS ALAMOS NM 87545
JAMES DARLING/ NEW MEXICO TECH/ BOX 2139 CAMPUS STATION/ SOCORRO NM 87801/ (505) 835-5455
T. A. NARTKER/ NEW MEXICO INSTITUTE OF MINING AND TEC/ SOCORRO NM 87801/ (505) 835-5126
KIM L. SHIVELEY/ NEW MEXICO TECH./ P.O. BOX 2129 C.S./ SOCORRO NM 87801/ (505) 835-5766
J. MACK ADAMS/ COMPo SCI. DEPT./ NEW MEXICO STATE U/ BOX 3CU/ LAS CRUCES NM 88003/ (505) 646-3723
ATTN: USER SERVICES LIBRARIAN/ UNIVERSITY COI1PUTER CENTER/ NEW MEXICO STATE UNIVERSITY/ BOX 3AT/ LAS CRUCES NM 88003/ (505) 644-4433
ATTN: RESEARCH PROGRAMMING ADVISOR/ COMPUTING CENTER/ U. OF NEVADA - LAS VEGAS/ 4505 MARYLAND PARKWAY/ LAS VEGAS NV 89154/ (702) 739-3557
JOHN WERTH/ DEPT. OF MATH/ U OF NEVADA LAS VEGAS/ LAS VEGAS NV ~9154/ (702) 739-3715
ATTENTION: ROY MAXION-PROGRAMMING ADVI/ UNS COMPUTING CENTER/ 22 WR/ U OF NEVADA/ BOX 9068/ RENO NV 89507/ (702) 784-4008
GARY CARTER/ SEISMOLOGY DEPT./ MACKAY SCHOOL OF MINES/ U OF NEVADA RENO/ RENO NV 89507
WILLIAM R. BONHAM/ SIERRA DIGITAL SYSTEMS/ 1440 WESTFIELD AVE. / RENO NV 89509/ (702) 329-9548
ATTN: ACADEMIC SERVICES/ UNIVERSITY COMPUTER CENTER/ U OF SOUTHERN CALIFORNIA/ 1020 W. JEFFERSON BLVD./ LOS ANGE~ES CA 90007/ (213) 746-2957
JORGEN STAUNSTRUP/ COMPUTER SCIENCE DEPT./ UNIV. OF SOUTHERN CALIFORNIA/ UNIVERSITY PARK/ LOS ANGELES CA 90007/ (213) 748-1977
FREDERICK C. COWAN/ MAIL STATION A2-2043/ THE AEROSPACE CORP./ P.O. BOX 92957/ LOS ANGELES CA 90009/ (213) 648-6482
~~NN~lti luUNG/ 3311 WEST 3RD ST. APT. 1-319/ LOS ANGELES CA 90020/ (213) 383-9666
ERIC PUGH/ 632 LEVERING AVE. APT. D/ LOS ANGELES CA 90024/ (213) 479-1352
KARL H. RYDEN/ HEALTH SCIENCES COMPUTING FACILITY/ 23 DEPT OF BIOMATH/ UCLA/ LOS ANGELES CA 90024/ (213) 825-5200
BRUCE SEILER/ DEPT. OF CHEMISTRY/ UCLA/ 405 HILGARD AVENUE/ LOS ANGELES CA 90024/ (213) 825-3818
WILLIAM MOSKOWITZ/ INSTRUCTIONAL SUPPORT GROUP/ CALIFORNIA STATE UNIVERSITY/ 5670 WILSHIRE BOULEVARD/ LOS ANGELES CA 90036/ (213) 852-5780
STEVEN BARRYTE/ 6620 W. 5TH STREET/ LOS ANGELES CA 90048/ (213) 653-8697
DAVID G. CLEMANS/ 2830 SEPULVEDA APT.20/ LOS ANGELES CA 90064/ (213) 473-7961
ERWIN BOOK/ 3169 COLBY AVENUE/ LOS ANGELES CA 90066
HOWARD H. METCALF/ 2590 GLEN GREEN #4/ HOLLYWOOD CA 90068
ARTHUR I. SCHWARZ/ BLDG. 150/MS A222/ HUGHES AIRCRAFT CO./ CULVER CITY CA 90230
ATTN: LAL CHAN DANI ENTERPRISES/ COMPUTER LAND/ 16919A HAWTHORNE BLVD./ LAWNDALE CA 90260
JIM HIGHTOWER/ 4947 BROWNDEER LANE/ RANCHO PALOS CA 90274/ (213) 541-4662
MARK L. ROBERTS/ RYAN MCFARLAND CORPORATION/ 608 SILVER SPUR ROAD/ ROLL.H.ESTATE CA 90274/ (213) 377-0491
JOHN R. DEALY/ BLDG. R3/1072/ TRW DSSG/ ONE SPACE PARK! REDONDO BEACH CA 90278/ (213) 535-0833
WILEY GREINER/ 90/2178/ TRW DSSG/ ONE SPACE PARK/ REDONDO BEACH CA 90278/ (213) 535-0313
J. B. HEIDEBRECHT/ 2178 BLD. 90/ TRW DSSG/ ONE SPACE PARK/ REDONDO BEACH CA 90278/ (213) 535-0313
DENNIS HEIMBIGNER/ 2500 CARNEGIE LANE HB/ REDONDO BEACH CA 90278/ (213) 535-0833
RALPH L. LONDON/ INFORMATION SCIENCES INSTITUTE/ U OF SOUTHERN CALlFORNIA/ 4676 ADMIRALTY WAY/ MARINA DEL RE CA 90291/ (213) 822-1511 X195
MICHAEL TEENER/ TECHNOLOGY SERVICE CORP./ 2811 WILSHIRE BLVD./ SANTA MONICA CA 90403/ (213) 829-7411 X244
WILLIAM E. FISHER/ 2074 SANTA FE AVENUE/ TORRANCE CA 90501
JOHN R. BARR/ 22014 REYNOLDS DRIVE/ TORRANCE CA 90503/ (213) 648-8295/ (213) 540-1381
PHYLLIS A. REILLY/ 19711 GALWAY AVENUE/ CARSON CA 90746/ (213) 321-5215
CLARK M. ROBERTS/ 219 VIOLET AVENUE/ MONROVIA CA 91016/ (213) 456-3858 (HOME)/ (213) 658-2405 (WORK)
E. E. SIMMONS/ 455 SOUTH OAKLAND AVE/ PASADENA CA 91101
CHARLES L. LAWSON/ JET PROPULSION LABORATORY/ MS 125/128/ CALIFORNIA INSTITUTE OF TECHNOLOGY/ 4800 OAK GROVE DR./ PASADENA CA 91103/ (213) 354-4321
ROBERT M. LANSFORD/ 3620 GREENHILL ROAD/ PASADENA CA 91107/ (213) 351-0206

(/)

rn
-0

--l

rn

91109
91330
91335
Yl702
91711
91711
91711
91740
91775
92025
92026
92067
92093
92093
92093
92103
92111
92121
92121
92122
92152
92152
92324
92408
92507
92507
92626
92634
92653
92663
92675
92101
92704
92704
92704
92704
92705
92713
92713
92713
92714
92714
92714
92714
92715
92717
92717
92805
92807
92807
93lOl

93105
93109
93401
93407
93407
93453
93555
93940
93940
93940
93940
94022
94022
94025
94025

ATTN: LIBRARY/ BURROUGHS CORP./ 460 SIERRA MADRE VILLA/ PASADENA CA 91109/ (213) 351-6551 X505
KEN MODESITT/ COMPUTER SCIENCE DEPT./ CALIFORNIA STATE UNIV./ 18111 NORDHOFF ST./ NORTHRIDGE CA 91330
MARK T. MARSHALL/ 18229 TOPHAM ST./ RESEDA CA 91335/ (213) 345-1739
ED KEITH/ CITRUS COLLEGE/ 18824 E. FOOTHILL BLVD./ AZUSA CA· 91702/ (213) 335-0521 X313/ (213) 963-1052
GERALD BRYAN/ SEAVER COMPUTER CENTER/ CLAREMONT COLLEGES/ CLAREMONT CA 91711/ (714) 626-8511 X3228
CHRIS P. LINDSEY/ COMPUTING/ HARVEY MUDD COLLEGE/ CLAREMONT CA 91711/ (.714) 626-8511 X2897
STANLEY E. LUNDE/ 890 HOOD DRIVE/ CLAREMONT CA 91711/ (714) 626-9977
DAVID C. FITZGERALD/ 652 S. CULLEN/ GLENDORA CA 91740/ (213) 335-6055
TOM GREER/ 224 N•. ALABAMA ST./ SAN GABRIEL CA 91775
MARK J. KAUFMAN/ 916 E WASHINGTON APT. 108/ ESCONDIDO CA 92025! (714) 743-5911
K. DOUGLAS JOHNSTON/ 1375 N BROADWAY APT F-2/ ESCONDIDO CA 92026/ (714) 743-5830/ (714) 485-2309 (WORK)
LANCE A. LEVENTHAL/ P.O. BOX 1258/ RANCHO SANTAF CA 92067/ (714) 755-6541
KEN BOWLES/ APIS DEPT./ C-21/ U OF CALIFORNIA - SAN DIEGO/ LA JOLLA CA 92093/ (714) 755-7288/ 452-4526
JIM MADDEN/ C-010 COMPUTER CENTER/ UNIV. OF CALIFORNIA - SAN ~IEGO/ LA JOLLACA 92093/ (714) 452-4067
MARK OVERGAARD/ APIS DEPT./ C-014/ U OF CALIFORNIA - SAN DIEGO! LA JOLLA CA 92093/ (714) 452-4723
DAVID M. BULMAN/ PRAGMATICS INC./ BOX 33228/ SAN DIEGO CA 92143/ (714) 565-0565
WARREN EDWARD LOPER/ 6542 ALCALA KNOLLS DR. / SAN DIEGO CA 9211!l/ (714) 560-0718 (HOME) / (714) 225-2480 (WORK)
LOUIS A. BENTON/ STAFF COMPUTER TECHNOLOGY CORP./ 10457 J ROSE'LLE ST./ SAN DIEGO CA 92121/ (714) 453-0303
CRAIG MAUDLIN/ SUITE M/ RENAISSANCE SYSTEMS/ 11760 SORRENTo' VALLEY RD./ SAN DIEGO CA 92121/ (714) 452-0681
GORDON J. WOOD/ 5818 MOTT ST./ SAN DIEGO CA 92122/ (714) 453-8167
MICHAEL S. BALL/ CODE 632/ NAVAL OCEAN SYSTEMS CENTER/ SAN DIEGO CA 92152
KENNETH O. LELAND/ R&D CENTER/ NAVY PERSONNEL/ CODE 9303/ SAN DIEGO CA 92152/ (714) 225-7388/ 933-7388 (DEF. DEPT. AV)
DAVID H. WELCH/ P.O. BOX 721/ COLTON CA 92324
TED C. PARK/ SYSTEMS DEVELOPMENT/ SUITE 302/ MEDICAL DATA CONSJLTANTS/ 1894 COMMERCENTER WEST/ SAN BERNARDIN CA 92408/ (714) 825-2683
ATTN: COMPUTER SCIENCES INSTITUTE/ U OF CALIFORNIA/ RIVERSIDE CA 92507
KURT COCKRUM/ 3398 UTAH/ RIVERSIDE CA 92507/ (714) 682-1907
ATTENTION: A.S. WILLIAMS/ LIBRARY/ TECHNOLOGY MARKETING INC./ 3170 RED HILL AVE./ COSTA MESA CA 92626/ (714) 979-1100
SEYMOUR SINGER/ BLDG 606/M.S. K110/ HUCHES AIRCRAFT CO./ P.O. BOX 3310/ FULLERTON CA 92634
ED HIRAHARA/ 25062 GRISSOM RD,/ LAGUNA HILLS CA 92653/ (714) 8/1-3232 X3073/ OR X3989
L. M. FOSTER/ COLLINS GOV!. TELECOMM. DIV. TECH. INF/ ROCKWELL INTERNATIONAL CORP./ 4311 JAMBOREE ROAD (501-105)/ NEWPORT BEACH CA 92663/ (714) 388-4389
ROBERT L. JARDINE/ BURROUGHS CORP./ 25725 JERONIMO ROAD/ MISSION VIEJO CA 92675/ (714) 768-2370
ROBERT L. HARTMAN/ 1425 E. FRANZEN AVE./ SANTA ANA CA 92701/ (714) 646-7466
COLE A. CHEVALIER/CONTROL DATA CORPORATION/ 3519 W. WARNER/ SANTA ANA CA 92704/ (714) 754-4134
CHARLES J. FETE/ W-14/ C/O CONTROL DATA CORP./ 3519 W. WARNER AVE./ SANTA ANA CA 92704/ (714) 754-4155
JIM FONTANA/ CONTROL DATA CORPORATION/ 3519 W. WARNER AVE./ SANTA ANA CA 92704/ (714) 754-4102
S. J. PACKER/ CONTROL DATA CORPORATION/ 3519 W. WARNER AVE./ SANTA ANA CA 92704/ (714) 754-4129
WALTER KOSINSKI/ INFORMATION SCIENCES CONSULTING/ 1654 SE SKYLINE DRIVE/ SANTA ANA CA 92705/ (714) 838-9387
GREGORY L. HOP\,OOD/ MINICOMPUTER OPERATIONS/ SPERRY UNIVAC/ 2722 MICHELSON DRIVE/ IRVINE CA 92713/ (714) 833-2400
BOB HUTCHINS/ COMPUTER AUTOMATION INC./ 18651 VON KARMAN/ IRVINE CA 92713/ (714) 833-8830 X335
ERIC OLSEN/ VARIAN DATA MACHINES/ 2722 MICHELSON DRIVE/ IRVINE CA 92713/ (714) 833-2400
WILLIAM E. CROSBY/ 15381 ORLEANS CIR./ IRVINE CA 92714/ (714) ~51-5632
RUDY L. FOLDEN/ 14681 COMET ST./ IRVINE CA 92714/ (714) 552-0398
STEVE LUNDQUIST/ 5142 CHATEAU CIRCLE/ IRVINE CA 92714/ (714) 871-3232 X4352
DONALD D. PECKHAM/ PERTEC COMPUTER CORP./ 17112 ARMSTRONG AVE.! SANTA ANA CA 92714/ (714) 540-8340
WILLIAM J. EARL/ 6 LEMON TREE/ IRVINE CA 92715/ (714) 552-1543
JOHN M. GRAM/ COMPUTING FACILITY/ U OF CALIFORNIA/ IRVINE CA 92717/ (714) 833-6844
JON F. HUERAS/ DEPT. OF INFORMATION AND COMPo SCI./ U OF CALIFORNIA IRVINE/ IRVINE CA 92717/ (714) 833-2400
WILLIAM L. COOPER/ ORG 4400/ INTERSTATE ELECTRONICS/ 707 E. VERMONT I ANAHEIM CA 92805/ (714) 772-2811 X1848
DAVID W. GIEDT/ 5421 WILLOWICK CIR./ ANAHEIM CA 92807/ (714) 7/2-2811
D. MARCUS/ GTE INFORMATION SYSTEMS/ 5300 E. LA PALMA/ ANAHEIM CA 92807/ (714) 524-4461
JIM MCCORD/ SYSTEMETRICS INC./ 120 E. DE LA GUERRA STREET/ SANTA BARBARA CA 93101/ (805) 963-8941
ATTENTION: NANCY BROOKS/ SCIENCE AND TECHNOLOGY DIVISION/ GENERAL RESEARCH CORPORATION/ 5383 HOLLISTER AVE./ SANTA BARBARA CA 93105/ (805) 964-7724
ROBERT ALAN DOLAN/ SPEECH COMMUNICATIONS RESEARCH LAB/ 800A MIRAMONTE DRIVE/ SANTA BARBARA CA 93109/ (805) 965-3011
NEIL W. WEBRE/ DEPT. OF COMPo SCI. AND STAT./ CALIF. POLY. STATE UNIV./ SAN LUIS OBIS CA 93401/ (805) 546-2986
JAMES L. BEUG/ DEPT. OF COMPo SCI./ CALIFORNIA POLYTECHNIC STATE U/ SAN LUIS OBIS CA 93407/ (805) 546-1255
DANA A. FREIBURGER/ COMPUTER CENTE/ CALIFORNIA POLYTECHNIC ST. UNIV./ SANLUIS OBISP CA 93407/ (805) 546-2005
H. MARC LEWIS/ PO BOX 505/ SANTA MARGARI CA 93453/ (805) 546-2009
GARY BABCOCK/ 110-E RICHMOND ROAD/ CHINA LAKE CA 93555/ (714) 939-3661
ATTN: COMPUTER SCIENCE DEPT. A/ CODE 52/ NAVAL POSTGRADUATE SCHOOL/ MONTEREY CA 93940
ATTN: COMPUTER SCIENCE DEPT. B/ CODE 52/ NAVAl POSTGRADUATE SCHOOL/ MONTEREY CA 93940
GORDON BRADLEY/ COMPUTER SCIENCE DEPT./ NAVAL POSTGRADUATE SCHOOL/ MONTEREY CA 93940
SUSAN FEUERMAN/ W.R. CHURCH COMPUTER CENTER/ CODE 0141/ NAVAL POSTGRADUATE SCHOOL/ MONTEREY CA 93940
HORACE ENEA/ HEURISTICS INC./ 900 N. SAN ANTONIO ROAD/ LOS ALTOS CA 94022/ (415) 948-2542
DAVID ELLIOT SHAWl STRUCTURED SYSTEMS CORPORATION/ 343 SECOND STREET - SUITE K/ LOS ALTOS CA 94022/ (415) 321-8111
DENNIS R. ALLISON/ 169 SPRUCE AVENUE/ MENLO PARK CA 94025/ (41~) 325-2962
GENE AUTREY-HUNLEY/ 318-8/ SRI INTERNATIONAL/ 333 RAVENSWOOD AVE./ MENLO PARK CA 94025/ (415) 326-6200 X2629

z
rn

94025
94025
94035
94035
94040
94041
94086
94086
94086
94086
94086
94086
94086
94086
94086
94086
94086
94087
94088
94088
94088
94111
94114
94143
94304
94304
94304
94304
94305
94305
94305
94305
94305
94538
94545
94550
94550
94550
94566
94596
94611
94613
94621
94703
94704
94720
94720
94720
94720
94720
94903
95003
95008
95014
95014
95014
95014
95014
95014
95050
95050
95051
95051
95051
95051
95051

APRIL MILLER CONVERSE/ SEISMIC ENGINEERING BRANCH/ M/S 87/ U.S.G.S./ 345 MIDDLEFIELD ROAD/ MENLO PARK CA 94025
JEFFRY G. SHAWl P.O. BOX 2678/ MENLO PARK CA 94025
ZAY CURTIS/ P.O. BOX 235/ MOFFETT FIELD CA 94035/ (415) 964-9900
CARL S. ROSENBERG/ AMES RESEARCH CENTER/ MAIL STOP 239-19/ MOFFETT FIELD CA 94035/ (415) 965-6436 (WORK)/ (415) 967-7000 (HOME)
J. R. BAICHTAL/ PCM SWITCHING ENGINEERING/ TRW/VIDAR/ 77 ORTEGA AVENUE/ MOUNTAIN VIEW CA 94040/ (415) 961-1000
WARREN VAN CAMP/ 178 CENTRE #14/ MT. VIEW CA 94041/ (415) 967-3170
RICH ALTMAIER/ 655 S. FAIROAKS AVE. APT. G101/ SUNNYVALE CA 94086
DENNIS S. ANDREWS/ COMPUTING SERVICES/ AMDAHL CORP./ 1250 E. A~~ue~ AV~I 'UNNYVALE CA 94086/ (408) 735-4011
GL~N T. EDENS/ DAGONICS DIV./ XEROX/ 350 POTRERO AVENUE/ SUNNYVALE CA 94086/ (408) 738-4800 (DACONICS)/ (415) 494-4464 (XEROX/PARC)
DENNIS ERNST/ INSTITUTE FOR ADVANCED COMPUTATION/ 1095 E. DUANE/ SUNNYVALE CA 94086/ (408) 735-0635
DENNIS GRAHAM/ AMDAHL CORP./ 1250 E. ARQUES AVE./ SUNNYVALE CA 94086/ (408) 735-4602
ROBERT S. LENT/ AMDAHL CORPORATION/ P.O. BOX 5070/ SUNNYVALE CA 94086/ (408) 735-4205
GEORGE LEWIS/ R & D/ BASIC TIMESHARING INC./ 870 WEST MAUDE AVENUE/ SUNNYVALE CA 94086/ (408) 733-1122
M. H. MACDOUGALL/ AMDAHL CORP./ P.O. BOX 5070/ SUNNYVALE CA 94086/ (408) 735-4654
FLEMING M. OLIVER/ 213 WEDDELL APT. 12/ SUNNYVALE CA 94086
ARTHUR C. WILLIS/ AMDAHL CORP./ 1250 EAST ARQUES AVE./ SUNNYV~LECA 94086/ (408) 735-4011
ANDREW HARRIS ZIMMERMAN/ 550 NORTH FAIR OAKS AVE. APT. 14/ SU~NYVALE CA 94086
ADRIAN BYRAM/ 1131 S. SAGE COURT/ SUNNYVALE CA 94087
RICHARD COREl PO BOX 61628/ SUNNYVALE CA 94088/ (408) 735-8400 X233
T. D. TELFORD! DEPT. 19-63/ BLDG 529/ LOCKHEED/ P.O. BOX 504/ SUNNYVALE CA 94088/ (408) 742-7301
GARY W. WINIGER/ P.O. BOX 60835/ SUNNYVALE CA 94088/ (415) 96(-6982/ (408) 742-5699 (WORK)
JIM ELAM/ 150 LOMBARD #601/ SAN FRANCISGO CA 94111
RICHARD H. KARPINSKI/ 3071 MARKET STREET/ SAN FRANCISCO CA 94114/ (415) 666-4529
FRANCIS KRIKORIAN/ ADMIN. INFO. SYSTEMS/ 101 BUILDING MR 4/ U.C.S.F. MEDICAL CENTER/ SAN FRANCISGO CA 94143/ (415) 666-3012
LINDA E. CROLEY/ BNR INC./ 3174 PORTER DR./ PALO ALTO CA 94304/ (415) 494-3942 X40 OR 61
SAM GEBALA/ HEWLETT PACKARD/ 3500 DEER CREEK RD./ PALO ALTO CA 94304/ (415) 494-1444 X214
H. S. MAGNUSKI/ GAMMA TECHNOLOGY/ 800 WELSH ROAD/ PALO ALTO CA 94304/ (415) 326-1661
rAuL MCJONES/ SDD/SD/ XEROX CORPORATION/ 3333 COYOTE HILL ROAD/ PALO ALTO CA 94304/ (415) 494-4522
PAUL HECKEL/ INTERACTIVE SYSTEMS CONSULTANTS/ P.O. BOX 2345/ PALO ALTO CA 94305/ (415) 965-0327
ATTN: LIBRARY / SERIALS/ BIN 82/ STANFORD LINEAR ACCELERATOR CENTER/ P.O. BOX 4349/ STANFORD CA 94305
JOHN BANNING/ MALL DROP 88/ STANFORD LINEAR ACCELERATOR CENTER/ P.O.BOX 4349/ STANFORD CA 94305/ (415) 854-3300 X2802 (OFFICE)/ (415) 325-9226 (HOME)
DAVID C. LUCKHAM/ COMPo SCI. DEPT./ A.I. LABORATORY/ STANFORD UNIVERSITY/ STANFORD CA 94305/ (415) 497-4971
HUGH MCLARTY/ BOX 10291/ STANFORD CA 94305/ (415) 322-4822
BRIAN MCGUIRE/ P.O. BOX 1371/ FR~roNT CA 94538
WILLIAM F. RAGSDALE/ DORADO SYSTEMS/ 20956 CORSAIR BLVD./ HYW ARD CA 94545/ (415) 783-0289
JOHN C. BEATTY/ L-73/ LAWRENCE LIVERMORE LAB/ BOX 808/ LIVERMCRE CA 94550/ (415) 447-1100 X3114
S. T. HEIDELBERG/ DIVISION 8323/ SANDIA LABORATORIES/ LIVERMORE CA 94550/ (415) 455-2179
WILLIAM P. TAYLOR/ L-315/ UNIVERSITY OF CALIFORNIA/ P.O. BOX 808/ LIVERMORE CA 94550/ (415) 455-6729
J. E. POLLACK/ 435 ABBIE STREET/ PLEASANTON CA 94566
RALPH W. SWEARINGEN/ VIRTUAL SYSTEMS INC./ 1500 NEWELL AVE. #406/ WALNUT CREEK CA 94596/ (415) 254-1147
PAUL S. GERKEN/ PROGRAMMING METHODS/ INFORMATICS/ 120 RONADA AVE./ PIEDMONT CA 94611/ (415) 655-4499
RITA MAY LIFF/ DEPT. OF MATH AND COMPUTER SCIENCE/ MILLS COLLEGE/ OAKLAND CA 94613/ (415) 632-2700 X308
BRYAN L. HIGGINS/ SCIENCE APPLICATIONS INC./ 8201 CAPWELL DRIVE/ OAKLAND CA 94621/ (415) 562-9163
JAMES A. WOODS/ 2014A WOOLSEY ST./ BERKELEY CA 94703
JIM MERRITT/ P.O. BOX 4655/ BERKELEY CA 94704/ (415) 845-4866
JEFFREY BARTH/ COMPo SCI. DIVISION/ 573 EVANS HALL/ U OF CALIFORNIA/ BERKELEY CA 94720/ (415) 642-4948
BLAND EWING/ DEPT. OF ENTYMOLOGY/ 137 GIANNINI HALL/ U OF CALIFORNIA/ BERKELEY CA 94720/ (415) 642-6660
ED FOURT/ C/O LBL LIBRARY/ 134 BLDG 50/ LAWRENCE BERKELEY LAB/ BERKELEY CA 94720/ (415) 843-2740 X5293
SUSAN L. GRAHAM/ COMPo SCI. DIVISION-EECS/ 511 EVANS HALL/ U OF CALIFORNIA/ BERKELEY CA 94720
LAWRENCE A. ROWE/ DEPT. OF EE AND CS - TEOI/ EVANS HALL/ U OF CALIFORNIA/ BERKELEY CA 94720
CHRIS K. PHILLIPS/ P.O. BOX 6283/ TERRA LINDA CA 94903/ (415) 494-7900 X357
ROBERT C. NICKERSON/ 517 SANTA MARGUARITA/ APTOS CA 95003/ (408) 688-9735
THOMAS A. ROLANDER/ 1012 SMITH AVE./ CAMPBELL CA 95008/ (408) 378-5785
A. G. CARRICK/ MS970/ FOUR-PHASE SYSTEMS INC./ 10700 N. DEANZA BLVD./ CUPERTINO CA 95014/ (408) 255-0900 X281
FAY CHONG/ 10405 DEMPSTER AVENUE/ CUPERTINO CA 95014/ (408) 987-1655
R. GREINER/ MS970/ FOUR-PHASE SYSTEMS INC./ 19333 VALLCO PARKWAY/ CUPERTINO CA 95014/ (408) 255-0900 X231
DONALD E. GRlMES/ TYMSHARE INC./ 20705 VALLEY GREEN DRIVE/ CUPERTINO CA 95014/ (408) 446-6586
P. LIAO/ MS970/ FOUR-PHASE SYSTEMS INC./ 19333 VALLCO PARKWAY/ CUPERTINO CA 95014/ (408) 255-0900 X302
JOHN P. STALLINGS/ TECHNICAL DIVISION/ TYMSHARE/ 20705 VALLEY GREEN DRIVE/ CUPERTINO CA 95014/ (408) 446-6000
JOHN DENNIS COUCH/ GSD/ HEWLETT-PACKARD/ 5303 STEVENS CREEK BLVD./ SANTA CLARA CA 95050/ (408) 249-7020 EXT.2949
LARRY WALSH/ ROLM CORPORATION/ 4900 OLD IRONSIDES DRIVE/ SANTA CLARA CA 95050/ (408) 988-2900
JOHN W. BURNETT/ M/S 690/ NATIONAL SEMICONDUCTOR CORP./ 2900 SEMICONDUCTOR DR./ SANTA CLARA CA 95051/ (408) 737-5228
RONALD L DANIELSON/ DEPARTMENT OF EECS/ UNIVERSITY OF SANTA CLARA/ SANTA CLARA CA 95051/ (408) 984-4181
AL HARTMANN/ INTEL CORPORATION/ 3065 BOWERS AVENUE/ SANTA CLARA CA 95051/ (408) 246-7501
DEAN SCHULZ/ INTEL CORPORATION/ 3065 BOWERS AVENUE/ SANTA CLARA CA 95051/ (408) 246-7501
E. HAROLD WILLIAMS/ M.S. 690/ NATIONAL SEMICONDUCTOR CORP./ 2900 SEMICONDUCTOR DRIVE/ SANTA CLARA CA 95051/ (408) 737-5228

95054
95060
95121
95131
95133
95153
95376
95404
95521
95819
95926
96822
97005
97005
97068
97077
97077
97077
97077
97077
97077
97077
97123
97210
97210
97212
97217
97221
97229
97331
97331
97331
>l4u3
97403
98004
98004
98006
98043
98055
98055
98105
98117
98124
98124
98124
98177
98195
98195
98195
98225
99163
2006
2006
2006
2007
2033
2033
2232
2308
2308
2308
2500
2600
2600
2600
2601

FRITHJOF KOLBERG/ BOX 4802/ SANTA CLARA CA 95054/ (408) 255-0900 X2794
TYLER/ 200 SEABURG PLACE/ SANTA CRUZ CA 95060/ (408) 925-0206
DADO BANATAO/ 3060 BILBO DRIVE/ SAN JOSE CA 95121/ (408) 227-9027
D. H. SPRINGER/ COMPUTER SYSTEMS DIVISION/ ANDERSON JACOBSON INC./ 521 CHARCOT AVENUE/ SAN JOSE CA 95131/ (408) 263-8520
JOHN H. SPANTON/ 2351 RAVINE DRIVE/ SAN JOSE CA 95133/ (408) 258-6763
TOM PITTMAN/ ITTY BITTY COMPUTERSrp.O. BOX 23189/ SAN JOSE CA 95153
TOM HORSLEY/ 1750 MELLO COURT/ TRACY CA 95376
GARY LOWELL/ 2625 HIDDEN VALLEY/ SANTA ROSA CA 95404/ (707) 544-6373
KENNETH A. DICKEY! 1662 STROMBERG/ ARCATA CA 95521/ (707) 822-3986
DAVID HILL/ COMPUTER CENTER/ SCI 319/ CALIFORNIA STATE UNIV. _ SACREMENTO/ 6000 J STREET/ SACRAMENTO CA 95819
ORLANDO S. MADRIGAL/ DEPARTMENT OF COMPUTER SCIENCE/ CALIFORNIA STATE UNIVERSITY AT CHICO/ CHICO CA 95926/ (916) 895-6442
W. W. PETERSON/ DEPT OF ICS/ U OF HAWAII/ 2565 THE MALL/ HONOLULU HI 96822/ (808) 948-7420
STEPHEN A. DUM/ 16820 S.W. CAMBRIDGE COURT/ BEAVERTON OR 97005! (503) 642-1168
PETER H. MACKIE/ PHM AND ASSOCIATES/ P.O. BOX 427/ BEAVERTON OR 97005/ (503) 645-2282
WILLIAM C. PRICE/ 28282 SW MOUNTAIN ROAD/ WEST LINN OR 97068
ROY CARLSON/ (50-454)/ TEKTRONIX/ P.O. BOX 500/ BEAVERTON OR 97077
TERRY HAMM/ M.S. 60-456/ TEKTRONIX INC./ P.O. BOX 500/ BEAVERTON OR 97077/ (503) 638-3411 X2579
DON HARVEY/ MSG-WILSONVILLE/ 60-171 TEKTRONIX/ BOX 500/ BEAVERTON OR 97077
NORM P. KERTH/ MS 58-736/ TEKTRONIX INC./ P.O. BOX 500/ BEAVERTON OR 97077
PAUL L. MCCULLOUGH/ TEKTRONIX 60/666/ P.O. BOX 500/ BEAVERTON OR 97077/ (503) 638-3411 X2397
LYNN SAUNDERS/ MS 39-135/ TEKTRONIX INC./ P.O. BOX 5001 BEAVERTON OR 97077/ (503) 644-0161 X6640
ROD STEEL/ MS 60-456/ TEKTRONIX INC./ P.O. BOX 500/ BEAVERTON OR 97077/ (503) 638-3411 X2516
JOHN L. RUTIS/ RT 3 BOX 292/ HILLSBORO OR 97123
ATTENTION: EVAN L. SOLLEY/ THE LIFE SUPPORT SYSTEMS GROUP LTD.! 2432 NW JOHNSON/ PORTLAND OR 97210/ (5U3) 226-3515
PAUL O-BRIEN/ P.O. BOX 10572/ PORTLAND OR 97210/ (503) 244-753~
BOB PHILLIPS/ 2009 N.E. BRAZEE/ PORTLAND OR 97212/ (503) 284-8369
DAVID WOLFE/ 7019 N. CHASE AVE./ PORTLAND OR 97217/ (503) 289-1228
DARRY SMITH/ COMPUTING/ OREGON MUSEUM OF SCIENCE AND INDUSTRY/ 4015 SW CANYON ROAD/ PORTLAND OR 97221/ (503) 248-5923
DAVID ROWLAND/ ELECTRO SCIENTIFIC INDUSTRIES/ 13900 N.W. SCIEN'CE PARK DRIVE/ PORTLAND OR 97229
ATTENTION: WILLIAM HUNTEMAN/ COMPUTER CENTER/ OREGON STATE U/ CORVALLIS OR 97331/ (503) 754-2494
DAVID F. CANTLEY I DEPT. OF COMPUTER SCIENCE/ OREGON STATE UNIV.! CORVALLIS OR 97331
KURT KOHLER/ MILNE COMPUTER CENTER! OREGON STATE UNIV.! CORVALLIS OR 97331! (503) 754-3474
ATTN: DOCUMENTS ROOM/ COMPUTER SCIENCE DEPARTMENT/ U OF OREGON,! EUGENE OR 97403/ (503) 686-4394
VERNON CHI/ ELECTRONICS SHOP/SCIENCE SERVICES/ 4 SCIENCE 1/ UNIVERSITY OF OREGON/ EUGENE OR 97403
BILLY R. CASON/ 11521 NE 20TH STREET/ BELLEVUE WA 98004/ (206) 454-4846
Lt.~LIE R. KERR/ SOFTWARE DESIGN/ 10545 WOODHAVEN LANE/ BELLEVU'E WA 98004/ (206) 455-3068
JOHN D. WOOLLEY/ 6722 128TH AVE. SE/ BELLEVUE WA 98006/ (206) 641-3443
GARY S. ANDERSON/ JOHN FLUKE MFG. CO. INC./ P.O. BOX 43210 M.S. 16/ MOUNTLAKE TER WA 98043/ (206) 774-2211 X353
R. A. LOVESTEDT/ 20427 SE 192/ RENTON WA 98055/ (206) 237-1397
RICHARD N. TAYLOR/ 10411'S.E. 174TH #3444/ RENTON WA 98055/ (206) 255-5856
ATTN: COMPUTER CENTER USER SERVICES! UNIVERSITY ,OF WASHINGTON/ 3737 BROOKLYN AVE. N.E. RM 15! SEATTLE WA 98105
ERIC SCHNELLMAN/ HONEYWELL MARINE SYSTEMS/ 5303 SHILSHOLE NW/ SEATTLE WA 98117
ATTENTION: BLAIR BURNER/ MS 73-03/ BOEING COMPUTER SERVICES INC./ P.O. BOX 24346/ SEATTLE WA 98124/ (206) 773-8683
ATTN: BOEING COMPANY/ 87-67 KENT TECHNICAL LIBRARY/ P.O. BOX 3999/ SEATTLE WA 98124
DAVID DEMOREST/ M/S 8M-71/ BOEING COMPUTER SERVICES/ P.O. BOX 24346/ SEATTLE WA 98124/ (206) 244-6923/ (206) 773-2019
CHARLES A. CASTELLOW! 203 NW 176TH PLACE/ SEATTLE WA 98177/ (206) 546-1579
HELLMUT GOLDE/ DEPT. OF COMPo SCI./ FR-35/ U OF WASHINGTON/ SEATTLE WA 98195! (206) 543-9264
JOE KELSEY/ COMPUTER SCIENCE TEACHING LABORATORY/ UNIVERSITY OF WASHINGTON/ MAIL STOP FR-35/ SEATTLE WA 98195/ (206) 543-2697
JOHN S. SOBOLEWSKI/ RG-20/ LOCKE COMPUTER/ UNIVERSITY OF WASHINGTON/ SEATTLE WA 98195/ (206) 543-9275
MARLIN PROWELL/ 3925 SILVER BEACH AVE./ BELLINGHAM WA 98225/ (206) 676-1554
ROBERT E LORD/ COMPUTER CENTER/ WASHINGTON STATE UNIV./ PULLMAN WA 99163
A. J. GERBER/ BASSER DEPT. OF COMPUTER SCIENCE/ UNIVERSITY OF SYDNEY/ SYDNEY N.S.W. 2006/ AUSTRALIA
CARROLL MORGAN/ BASSER DEPT. OF COMPUTER SCIENCE/ U OF SYDNEY/ SYDNEY N.S.W. 2006/ AUSTRALIA
BRIAN G. ROWSWELL/ UNIVERSITY COMPUTER CENTRE/ UNIVERSITY OF SYDNEY/ SYDNEY N.S.W. 2006/ AUSTRALIA/ 692 3491
E. H. DOBELL/ COMPUTER CENTRE/ NSW INSTITUTE OF TECHNOLOGY/ P.O. BOX 123/ BROADWAY N.S.W. 2007/ AUSTRALIA/ (02) 218 9438
ATTN: LIBRARIAN/ COMPUTING SERVICES UNIT/ UNIV. OF N.S.W./ P.C. BOX 1/ KENSINGTON N.S.W. 2033/ AUSTRALIA
KEN ROBINSON/ DEPT. OF COMPUTER SCIENCE/ UNIVERSITY OF NEW SOlTH WALES/ P.O. BOX 1/ KENSINGTON N.S.W. 2033/ AUSTRALIA/ 663 0351
JEFFREY TOBIAS/ APPLIED MATHS AND COMPUTING DIV./ AUST. ATOMIC ENERGY COMM. RES. EST./ PRIVATE MAIL BAG/ SUTHERLAND N.S.W. 2232/ AUSTRALIA/ 531-0111
ATTN: SERIALS LIBRARY/ AUCHMUTY LIBRARY/ UNIVERSITY OF NEWCASILE/ NEWCASTLE N.S.W. 2308/ AUSTRALIA/ 685745
J. A. CAMPBELL/ MATHEMATICS DEPT./ UNIVERSITY OF NEWCASTLE/ NEWCASTLE N.S.W. 2308/ AUSTRALIA
JOHN A. LAMBERT/ COMPUTING CENTRE/ UNIVERSITY OF NEWCASTLE/ NEWCASTLE N.S.W. 2308/ AUSTRALIA
J. REINFELDS/ COMPUTING SCIENCE/ UNIVERSITY OF WOLLONGONG/ P.O. BOX 1144/ WOLLONGONG N.S.W. 2500/ AUSTRLIA/ (042) 297311
ATTN: PURCHASING OFFICE/ RESEARCH SCHOOL OF PHYSICAL SCIENCES/ AUSTRALIAN NATIONAL UNIVERSITY/ P.O. BOX 4/ CANBERRA A.C.T. 2600/ AUSTRALIA/ 492143
A. J. HURST/ DEPT. OF COMPUTER SCIENCE/ AUSTRALIAN NATIONAL UNIVERSITY/ P.O. BOX 4/ CANBERRA A.C.T. 2600/ AUSTRALIA/ (062) 49 4625
MALCOLM C. NEWEY/ COMPUTER CENTRE/ AUSTRALIAN NATIONAL UNIV./ P.O. BOX 4/ CANBERRA A.C.T. 2600/ AUSTRALIA/ 81-6376 / 49-4216
ATTN: THE LIBRARIAN/ CSIRO/ DIV. OF COMPUTING RES./ P.O. BOX 1800/ CANBERRA CITY A.C.T. 2601/ AUSTRALIA

w.

AUSTRALIA
AUSTRALIA
AUSTRALIA
AUSTRALIA
AUSTRALIA
AUSTRALIA
AUSTRALIA
AUSTRALIA
AUSTRALIA
AUSTRALIA
AUSTRALIA
AUSTRALIA
AUSTRALIA
AUSTRALIA
AUSTRALIA

N
Vl

2616
3000
3001
3052
3052
3052
3052
3083
3165
4067
5000
5001
5001
5001
)001
;006
6005
6009

AUSTRALIA
AUSTRALIA
AUSTRALIA
AUSTRALIA
AUSTRALIA
AUSTRALIA
AUSTRALIA
AUSTRALIA
AUSTRALIA
AUSTRALIA
AUSTRALIA
AUSTRALIA
AUSTRALIA
AUSTRALIA
AUSTRALIA
AUSTRALIA
AUSTRALIA
AUSTRALIA
1001 AUSTRALIA
7001 AUSTRALIA
A-1040 AUSTRIA
A-I040 AUSTRIA
A-1l50 AUSTRIA
A-4060 AUSTRIA
A-5020 AUSTRIA
BELGIUM
B-1170 BELGIUM
B.,.2000 BELGIUM
B-3030 BELGIUM
B-3030 BELGIUM
13100 BRAZIL
13100 BRAZIL
13100 BRAZIL
13100 BRAZIL
13560 BRAZIL
A1C 5S7 CANADA
A1C 5S7 CANADA
A1C 5S7 CANADA
G1W 2P3 CANADA
H1 Y 3C3 CANADA
H1 Z 3P 1 CANADA
H3C 3J7 CANADA
H3C 3J7 CANADA
tuC 3J7 CANADA
H3G 1M8 CANADA
H3G 1M8 CANADA
H3G 2C8 CANADA
H3P 3B9 CANADA
H4 V 2H3 CANADA
H9R 1G1 CANADA
H9R 1G1 CANADA
J 1K 2R1 CANADA
K1A ON8 CANADA
KlJ 6L2 CANADA
K1N 6N5 CANADA
K1N 6N5 CANADA
K1S 5G3 CANADA
K2E 6T7 CANADA
K2K 1K2 CANADA
K7L 3N6 CANADA
K7L 3N6 CANADA
K7L 3N6 CANADA
L8N 3W3 CANADA
L8S 4K1 CANADA
L85 4K1 CANADA
M3J 1P3 CANADA

ATTN: SCHOOL OF INFORMATION SCIENCES/ CANBERRA COLLEGE OF ADV4NCED EDUCATION/ P.O. BOX NO. 1/ BELCONNEN A.C.T. 2616/ AUSTRALIA
G. J. KNOX/ COMPUTER CENTRE/ ROYAL MELBOURNE INSTITUTE OF TECHNOLOG/ 124 LATROBE STREET/ MELBOURNE VICTORIA 3000/ AUSTRALIA/ 341.2292
ATTN: CENTRAL LIBRARY/ FLOOR 1 CASEY WING/ ROYAL MELBOURNE INSTITUTE OF TECHNOLOG/ 376-392 SWANSTON STREET/ MELBOUKNE VICTORIA 3001/ AUSTRALIA
PETER RICHARDSON/ COMPUTER SCIENCE DEPT./ UNIV. OF MELBOURNE/ "~LBOURNE VICTORIA 3052/ AUSTRALIA/ (03) 3415225
ATTN: LIBRARIAN/ SCHOOL OF MATHEMATICAL SCIENCES/ RICHARD BERRY BUILDING/ UNIVERSITY OF MELBOURNE/ PARKVILLE VICTORIA 3052/ AUSTRALIA
ANTHONY P. KYNE! DEPT. OF CO~WUTER SCIENCE/ UNIVERSITY OF MELBOURNE/ PARKVILLE VICTORIA 3052/ AUSTRALIA/ 345 1844
PRABHAKER MATELI/ DEPT. OF COMPUTER SCIENCE/ UNIV. OF MELBOURNE/ PARKVILLE VICTORIA 3052/ AUSTRALIA/ (03)341-6459
ATTN: COMPUTER CENTRE/ LA TROBE UNIVERSITY/ BUNDOORA VICTORIA 3083/ AUSTRALIA/ 478 3122
GEOFFREY A. CLEAVE/ 18 NEIL COURT/ E. BENTLEIGH VICTORIA 3165/ AUSTRALIA
D. B. JOHNSTON/ DEPT. OF COMPUTER SCIENCE/ UNIV. OF QUEENSLAND/ ST. LUCIA QUEENSLAND 4067/ AUSTRALIA/ 07/3706930
c. A. RUSBRIDGE/ SOUTH AUSTRALIA INSTITUTE OF TECHNOLOG/ P.O. BOX 1/ INGLE FARM S.A. 5000/ AUSTRALIA/ AUSTRALiA 260-2055
ATTN: PROGRAM LIBRARIAN/ COMPUTING CENTRE/ UNIVERSITY OF ADELAIDE/ BOX 498 G.P.O./ ADELAIDE S.A. 5001/ AUSTRALIA/ 61 82, 34333 X2720/X2099
YOUNG J. CHOI/ DEPT. OF COMPUTING SCIENCE/ UNIV. OF ADELAIDE/ ADELAIDE S.A. 5001/ AUSTRALIA/ 223-4333
B. KIDMAN/ DEPT OF COMPUTER SCIENCE/ UNIVERSITY OF ADELAIDE/ GPO BOX 498/ ADELAIDE S.A. 5001/ AUSTRALIA/ 223 4333
C. D. MARLIN/ COMPUTING SCIENCE DEPT./ UNIVERSITY OF ADELAIDE/ G.P.O. BOX 498/ ADELAIDE S.A. 5001/ AUSTRALIA/ 223 4333 X2762
I. N. BLAVINS/ KATHLEEN LUMLEY COLLEGE/ FINNIS STREET/ NORTH ADELAID S.A. 5006! AUSTRALIA
PETER R. SUMNER/ INTERDATA COMPUTERS PTY. LTD./ 30 KINGS PARK RD./ WEST PERTH W.A. 6005/ AUSTRALIA/ (09) 322-3391
J. S. ROHL/ DEPT. OF COMPUTER SCIENCE/ U OF WESTERN AUSTRALIA/ NEDLANDS W.A. 6009/ AUSTRALIA
ATTN: SECRETARY! DEPARTMENT OF INFORMATION SCI,ENCE/ UNIVERSITY OF TASMANIA/ GPO BOX 252C/ HOBART TASMANIA 7001/ AUSTRALIA
A. H. J. SALE/ DEPT. OF INFORMATION SCIENCE/ UNIVERSITY OF TAStIANIA/ BOX 252C/ HOBART TASMANIA 7001/ AUSTRALIA/ 23 0561
HELMUT SCHAUER/ TU WEIN/ ARGENTINIERSTR. 8/ WIEN A-1040/ AUSTRIA/ 0222/6587 31 316
ADA SZER/ INSTITUT F. INFORMATIONS-SYSTEME/ ARGENTINIERSTR. 8/ WIEN A-1040/ AUSTRIA/ 65 87 31/313
KONRAD MAYER/ REICHSAPFELG 13/8/ VIENNA A-1150/ AUSTRIA
KARL PRAGERSTORFER/ EDERACKERSTRASSE 11/7/ LEONDING A-4060/ AUSTRIA
FRANZ W. MAIER/ ZENTRUM FUER EDV/ UNIVERSITAET SALZBURG/ PETERSBRUNNSTR. 19/ SALZBURG A-5020/ AUSTRIA/ 06222/44511/343
o. BEAUFAYS/ MATHEMATIQUES APPLIQUEES/ C P I 165/ UNIVERSITE LIBRE DE BRUXELLES/ AVENUE F.-D. ROOSEVELT 50/ BRUXELLES B-1050/ BELGIUM
ALAIN PIROTTE/ MBLE/RESEARCH LABORATORY/ AVENUE EM. VAN BECELAERE 2/ BRUSSELS B-1170/ BELGIUM/ 673.41.90/ 673.41.99
RAYMAOND BOUTE/ FRANKRIJKLEI 96A - BUS 24/ ANTWERP EN B-2000/ BELGIUM! 031/317445
JOHAN LEWI/ AFD. TOEGEPASTE WISKUNDE EN PROGRAMMAT/ KATHOLIEKE UNIV. LEUVEN/ CELESTUNENLAAN 200B/ HEVERLEE B-3030/ BELGIUM/ 0032/16/235821
P. VERBAETEN/ APPLIED MATH. AND PROGRAMMING DIV./ K U LEUVEN/ CELESTYNERLAAN 200B/ HEVERLEE B-3030/ BELGIUM
JOSE OSVALDO FERRARI/ lMECC/ UNICAMP/ C.P. 1170/ CAMPINAS SP 13100/ BRAZIL/ 31-4555
ROGERIO BURNIER FILHO/ RUA MARIA MONTEIRO 223/ CAMPINAS SP 13100/ BRAZIL
PALTONIO DAUN FRAGA/ IMECC/ UNICAMP/ C.P. 1170/ CAMPINAS SP 13100/ BRAZIL/ PABX 31-4555
FERNANDO ANTONIO VANINI/ lMECC/ UNICAMP/ C.P. 1170/ CAMPINAS SP 13100/ BRAZIL/ 31-4555
SERGIO DE MELLO SCHNEIDER/ DEPARTAMENTO DE COMPUTACAO/ UNIVERSIDADE FEDERAL DE SAO CARLOS/ SAO CARLOS SP 13560/ BRAZIL
R. JAMES DAWE/ MATH STAT AND COMPo SCI./ MEMORIAL UNIV. OF NEWFOUNDLAND/ ST. JOHN'S NEWFOUNDLA A1C 5S7/ CANADA/ (709) 753-1200 EXT. 2767
RANDY DODGE/ COMPUTING SERVICES/ MEMORIAL UNIVERSITY/ ST. JOHN'S NEWFOUNDLA A1C 5S7/ CANADA/ (709) 753-1200 X2746
F. G. PAGAN/ COMPUTER SCIENCE/ MEMORIAL UNIVERSITY/ ST. JOHN'S NEWFOUNDLA AlC 5S7/ CANADA
JEAN CASTONGUAY/ 3140 AVENUE FRANCE-PRIME #202/ STE-FOY QUEBEC G1W 2P3/ CANADA
CARLO LOCICERO/ 6426 MOLSON/ MONTREAL QUEBEC H1Y 3C3/ CANADA/ (514) 727-3110
SERGE FROMENT/ 9142 QUINZIEME AVENUE/ MONTREAL QUEBEC H1Z 3P1/ CANADA/ (514) 321-2482
JEAN VAUCHER/ DEPARTEMENT D'INFORMATIQUE/ UNIVERSITE DE MONTREAL/ C.P. 6128 - STATION A/ MONTREAL QUEBEC H3C 3J7/ CANADA/ (514) 343-7092
PATRICK WARD/ CENTRE DE CALCULI UNIVERSITE DE MONTREAL/ C.P. 6128/ MONTREAL QUEBEC H3C 3J7/ CANADA/ (514) 343-6866
PIERRE DESJARDINS/ INFORMATIQUE! UNIVERSITE DE MONTREAL/ C.P. 6128/ MONTREAL 101 QUEBEC H3C 3J7/ CANADA/ (514) 343-7662
DAVID KARL PROBST/ COMPUTER SCIENCE DEPT./ CONCORDIA UNIVERSITy/ 1455 DE MAISONNEUVE W./ MONTREAL QUEBEC H3G IM8/ CANADA/ (514) 733-4921
J. W. ATWOOD/ DEPT OF COMPo SCI.:H963-10/ CONCORDIA UNIVERSITY/ 1455 DE MAISONNEUVE BLVD. WEST/ MONTREAL QUEBEC H3G 1M8/ CANADA/ (514) 879-8130
ERIC MELBARDIS/ 3467 AVE. DU MUSEE - #206/ MONTREAL QUEBEC H3~ 2C8/ CANADA
IAN MACMILLAN/ P.O. BOX 128/ MOUNT ROYAL QUEBEC H3P 3B9/ CAN~1~
PETER GROGONO/ THE SOUND MACHINE/ 4877 ROSEDALE AVENUE/ MONTL\L QUEBEC H4V 2H3/ CANADA/ (514) 489-9995/ (514) 879-4251 (WORK)
RICHARD WEST/ SMALL TERMINAL ENGINEERING/ COMTERM LIMITED/ 14! HYMaS BLVD./ MONTREAL QUEBEC H9R 1Gl/ CANADA/ (514) 697-0810 X227
EDWIN TSE/ 525 DELMAR ST./ POINTE CLAIRE QUEBEC H9R 1G1/ CANAlA/ (514) 697-1320
JACQUES HAGUEL/ FACULTE DES SCIENCES/ UNIVERSIIE DE SHERBROOKE/ SHERBROOKE QUEBEC J1K ZR1/ CANADA/ (819) 563-4635
BARRY SEARLE/ SECTION TASX/ TOWER C FLOOR 10C/ TRANSPORT CANAn A/ PLACE DE VILLE/ OTTAWA ONTARIO K1A ON8/ CANADA/ (613) 996-0218
D. B. COLDRICK/ COMPUTATION CENTRE/ BLDG. M-60/ NATIONAL RESEARCH COUNCIL/ MONTREAL ROAD/ OTTAWA ONTARIO K1J 6L2/ CANADA/ (613) 993-3870
LUIGI LOGRIPPO/ COMPo SCI. DEPT./ U OF OTTAWA/ OTTAWA ONTARIO K1N 6N5/ CANADA
H. TAYLOR/ COMPUTING CENTRE/ APPLICATIONS DEPT./ U OF OTTAWA/ OTTAWA ONTARIO K1N 6N5/ CANADA
SAM WILMOTT/ APT. 501/ 463 CAMBRIDGE SOUTH/ OTTAWA ONTARIO K1S )G3/ CANADA
ATTENTION: DONALD LINDSAY/ DYNALOGIC CORPORATION LIMITED/ 141 BENTLEY AVENUE/ OTTAWA ONTARIO K2E 6T7/ CANADA/ (613) 226-1383
FRANKLIN B. DE GRAAF/ 6 CARMICHAEL COURT/ KANATA ONTARIO K2K IK2/ CANADA/ (613) 592-5793
ATTN: REFERENCE ROOM/COMPUTING AND INF. SCI./ QUEEN'S UNIVERSITY/ KINGSTON ONTARIO K7L 3N6/ CANADA
JACK HUGHES/ COMPUTING CENTRE/ DUPUIS HALL/ QUEEN'S UNIVERSITY/ KINGSTON ONTARIO K7L 3N6/ CANADA/ (613) 547-2800
R. D. TENNENT/ DEPT. OF COMPUTING AND INFORMATION SCI/ QUEENS UNIVERSITY/ KINGSTON ONTARIO K7L 3N6/ CANADA
MARK GREEN/ #904 - 123 CHARLTON AVE. E/ HAMILTON ONTARIO L8N 3W3/ CANADA/ (416) 522-2512
N. SOLNTSEFF/ DEPT. OF APPLIED MATH./ MCMASTER UNIVERSITY/ HAMILTON ONTARIO L8S 4K1/ CANADA/ (416) 525-9140 X4689
ATTENTION: CHRIS BRYCE/ APPLIED MATH. COMPUTER LAB/ MCMASTER UNIVERSITY/ HAMILTON ONTARIO L85 4K1/ CANADA/ (416) 525-9140 X4689
GEOFFREY HUNTER/ CHEMISTRY DEPT./ YORK UNIVERSITY/ DOWNSVIEW ONTARIO M3J 1P3/ CANADA/ (416) 667-3852

N

en

M3M 3B9 CANADA
M5S lA7 CANADA
M5V
MSW
N1G
N2J
N2L
N2L
N2L
N6A
N6A
N6A
N9B
R3T
R3T
57K
T2N
T2N
T2N
T6G
T6G
VSN
V6T
V6T
V6X
V6X
V7W
V8P

259
lN5
2Wl
4T2
3B8
3Gl
3Gl
SB7
SB7
SB7
3P4
2N2
2N2
3P7
lN4
lN4
lN4
2J8
2NS
3Xl
lWS
lWS
2Z9
2Z9
2J6
SJ2

DK-1601
DK-ZOOO
DK-2100
DK-2100
DK-2200
DK-2300
DK-2S00
DK-2650
DK-26S0
DK-2730
DK-2800
DK-2800
DK-2800
DK-2880
DK-8000
DK-8000
DK-8000
DK-8200
DK-9000
DK-9000
DK-9000
SF-00130
SF-00330
SF-20S00
SF-33101
F-06034
F-31077
F-31077
F-34000
F-3S031
F-38040
F-S4042
F-7S00S
F-7S230
0-1000

CANADA
CANADA
CANADA
CANADA
CANADA
CANADA
CANADA
CANADA
CANADA
CANADA
CANADA
CANADA
CANADA
CANADA
CANADA
CANADA
CANADA
CANADA
CANADA
CANADA
CANADA
CANADA
CANADA
CANADA
CANADA
CANADA
CHILE
DENMARK
DENMARK
DENMARK
DENMARK
DENMARK
DENMARK
DENMARK
DENMARK
DENMARK
DENMARK
DENMARK
DENMARK
DENMARK
DENMARK
DENMARK
DENMARK
DENMARK
DENMARK
DENMARK
DENMARK
DENMARK
FINLAND
FINLAND
FINLAND
FINLAND
FRANCE
FRANCE
FRANCE
FRANCE
FRANCE
FRANCE
FRANCE
FRANCE
FRANCE
GERMANY

ATTENTION: MARTIN TUORI/ BEH. SCI. DIV./ DEFENCE AND CIVIL INST. OF ENVIRONMENT/ P.O. BOX 2000/ DOWNSVIEW ONTARIO M3M 3B9/ CANADA
(416) 633-4240 X204 (OFFICE) / )C238 (LAB)
ATTN: M. DOHERTY/ 128 TECHNICAL REFERENCE CENTER/ UNIVERSITY OF TORONTO COMPUTER CENTER/ 10 KINGS COLLEGE ROAD/ TORONTO ONTARIO MSS lA7/ CANADA
(416) 978-8995
MIKE KIMBER/ DATA CENTRE/ THE GLOBE AND MAIL/ 444 FRONT ST. WEST/ TORONTO ONTARIO MSV 2S9/ CANADA
HENRY SPENCER/ SP SYSTEMS/ BOX 5255 STATION A/ TORONTO ONTARIO MSW lNS/ CANADA
ANNE STOCCO/ COMPo AND INFO. SCIENCE/ 108 I.C.S./ UNIVERSITY OF GUELPH/ GUELPH ONTARIO N1G 2Wl/ CANADA/ ••••••••• X22S9
CHARLES H. FORSYTH/ APT. 2-304/ 300 REGINA ST. N./ WATERLOO ONTARIO N2J 4T2/ CANADA/ (519) 884-7531
DELE AYENI/ 316-102 SEAGRAM DRIVE/ WATERLOO ONTARIO N2L 3B8/ CANADA/ (509) 884-4679
W. MORVEN GENTLEMAN/ MATHEMATICS COMPUTING FACILITY/ UNIVERSITY OF WATERLOO/ WATERLOO ONTARIO N2L 3Gl/ CANADA/ (519) 578-8866
KAY HARRISON/ COMPUTER CENTER/ 1088B M AND C/ U OF WATERLOO/ WATERLOO ONTARIO N2L 3Gl/ CANADA
ATTN: PROGRAM LIBRARY/ COMPUTING CENTER/ 223 NATURAL SCIENCE CENTER/ U OF WESTERN ONTARIO/ LONDON ONTARIO N6A SB7/ CANADA/ (519) 679-2151
F. CELLINI/ DEPT. OF COMPUTER SCIENCE/ UNIVERSITY OF WESTERN ONTARIO/ LONDON ONTARIO N6A SB7/ CANADA/ (519) 679-6051
S. WILLIAMSON/ NATURAL SCIENCE CENTRE/ 223 COMPUTING CENTER/ UNIVERSITY OF WESTERN ONTARIO/ LONDON ONTARIO N6A SB7/ CANADA/ (519) 679-2151
L. C. PORTIL/ COMPUTER CENTRE/ U OF WINDSOR/ WINDSOR ONTARIO N9B 3P4/ CANADA/ (519) 253-4232 X645
G. D. DERHAK/ COMPUTER CENTRE/ U OF MANITOBA/ WINNIPEG MANITOBA R3T 2N2/ CANADA
W. BRUCE FOULKES/ DEPARTMENT OF COMPUTER SCIENCE/ THE UNIVERSITY OF MANITOBA/ WINNIPEG MANITOBA R3T 2N2/ CANADA/ (204) 269-3363
WILLIAM BLAMPIED/ SED SYSTEMS LTD/ P.O. BOX 1464/ SASKATOON SASK. S7K 3P7/ CANADA/ (306) 244-0976 X37
STEPHEN SOULE/ DEPT. OF COMPo SCL/ U OF CALGARY/ CALGARY ALBERTA T2N lN4/ CANADA/ (403) 284-6780
BRIAN W. UNGER/ COMPUTER SCIENCE DEPT./ UNIVERSITY OF CALGARYl CALGARY ALBERTA T2N lN4/ CANADA/ (403) 284-6316
B. VENKATESAN/ DEPT. OF COMPUTER SERVICES/ U OF CALGARY/ 2920 24TH AVE. N.W./ CALGARY ALBERTA T2N lN4/ CANADA/ (403) 284-6207
ATTN: LIBRARY/ PERIODICALS SECTION/ UNIVERSITY OF ALBERTA/ EDMONTON ALBERTA T6G 2J8/ CANADA
C. A. MILLER/ DEPT. OF PHYSICS NUCLEAR RES. CTR./ UNIV. OF ALBERTA/ EDMONTON ALBERTA T6G 2N5/ CANADA
ALAN LILLICH/ 3477 BELLA VISTA/ VANCOUVER B.C. V5N 3Xl/ CANAD~
ROBERT A. FRALEY/ DEPT. OF COMPUTER SCIENCE/ U OF BRITISH COLUMBIA/ VANCOUVER B.C. V6T lWS/ CANADA! (604)~22~-Z083
BARY w. POLLACK/ DEPT. OF COMPo SCI./ U OF BRITISH COLUMBIA/ 2075 WESBROOK PLACE/ VANCOUVER B.C. V6T lW5/ CANADA/ (604) 228-6794
WAYNE FUNG/ NOOTKA BLDG./ MACDONALD DETTWILER AND ASSOC. LTD./ 10280 SHELLBRIDGE WAY/ RICHMOND B.C. V6X 2Z9/ CANADA/ (604) 278-3411
DOUG TEEPLE/ NOOTKA BUILDING/ MACDONALD DETTWILER & ASSOC. LTD'/ 10280 SHELLBRIDGE WAY/ RICHMOND B.C. V6X 2Z9/ CANADA/ (604) 278-3411
DOUG DYMENT/ 6442 IMPERIAL AVE./ W. VANCOUVER B.C. V7W 2J6/ CANADA/ (604) 921-7954 (HOME)
GORDON STUART/ TECHNICAL AND VOCATIONAL INST./ CAMOSUN COLLEGEI 1950 LANSDOWNE RD./ VICTORIA B.C. V8P 5J2/ CANADA/ (604) 592-1281 X248
ATTN: CENTRO DE CIENCIAS DE LA COMPUTA/ UNIVERSIDAD CATOLICA DE CHILE/ CASILLA 114-0/ SANTIAGO/ CHILE/ 513548
LARS EKMAN/ EDB-SEKRETARIATET/ DANISH POST AND TELEGRAPH OFFIC E/ VESTER FARMAGSGADE 37.3/ KOBENHAVN V DK-1601/ DENMARK/ (01) 14 51 66
PHILIP PARKER/ VAGTELVEJ 59 ST. MF./ COPENHAGEN F DK-2000/ DENMARK/ (01) 34 00 58
ATTN: SOFTWARE/HARDWARE GROUP/ EMlLIUS MOLLER AS-NCR/ TEGLVAERKSGADE 31/ COPENHAGEN DK-Zl00/ DENMARK/ (01) 29 15 55
JORGEN OXENBOLL/ RC4000 AFDELINGEN/ H.C. ORSTED INSTITUTET/ UNIVERSITETSPARKEN 5/ KOBENHAVN 0 DK-2100/ DENMARK
ATTN: DATALOGISK INSTITUT/ COPENHAGEN UNIVERSITY/ SIGURDSGADE 41/ COPENHAGEN N DK-2200/ DENMARK
ANDERS WEBER/ EBERTSGADE 2 - 3STH/ KOBENHAVN S. DK-2300/ DENMARK
ATTENTION: JAN LAUGESEN V. 3-357/ I/S DATACENTRALUM AF 1959/ RETORTVEJ 8/ VALBY DK-2500/ DENMARK/ (01) 46 81 22
G. RICHARD BLADEN/ GILLESAGER 226 ST TV / HUIDOVRE DK-26S0/ DENMARK/ (01) 75 79 15
NIELS WINTHER/ REBAEK SOPARK 5-544/ HVIDOVRE DK-26S0/ DENMARK
JENS PETER RINGGAARO/ CHRISTIAN ROVSING A/S/ MARIELUNDVEJ 46 BI HERLEV DK-2730/ DENMARK/ 02 91 88 33
ATTN: BIBLIOTEKET/ NEUCC/ BUILDING 305/ TECHNICAL UNIV. OF DENMARK/ LYNGBY DK-2800/ DENMARK/ 02 88 12 77
KELD' HELBIG HANSEN/ NEUCC/ TECHNICAL UNIV. OF DENMARK/ BUILDING 3bs/ LYNGBY DK-2800/ DENMARK/ (02) 88 12 77
GUNNAR JOHANSEN/ DEPT. OF CHEMISTRY AND CHEM. ENG./ DANISH ENGINEERING ACADEMY/ BYGNING 375/ LYNGBY DK-2800/ DENMARK
LARS CHRISTENSEN/ ALDERSHVILEVEJ 16/ BAGSVAERO DK-2880/ DENMARK/ 009 45 2 98 20 09
ATTN: RECAU/ NY MUNKEGADE/ AARHUS C DK-8000/ DENMARK/ 06-128355
u. HAMMELEFF/ DET REGIONALE EDB-CENTER/ RECAU/ AARHUS UNIVERSITET/ NY MUNKEGADE/ AARHUS C DK-8000/ DEN~~RK/ 45 6 12 8355
ATTN: RECAU (B)/ NY MUNKEGADE/ AARHUS C. DK-8000/ DENMARK/ 06-12 83 55
HOLGER NIELSEN/ OSLOGADE 6 11/ AARHUS N DK-8200/ DENMARK
UFFE MOLLER/ DATANOMUDDANNELSEN/ SOHNGAAROSHOLMSVEJ 57/ AALBORG DK-9000/ DENMARK/ (08) 14 12 06
PREBEN TAASTI/ COMPUTER CENTER/ UNIVERSITY OF AALBORG/ STRANDVEJEN 19/ AALBORG DK-9000/ DENMARK/ (08) 138 788
KLAUS ILLUM/ INSTITUT 4/ ALBORG UNIVERSITETSCENTER/ BADEHUSVEJ lB/ ALBORG DK-9000/ DENMARK/ 08-138788
HEIKKI KASKELMA/ OY SOFTPLAN AB/ EROTTAJANKATU 9 A/ HELSINKI SF-00130/ FINLAND/ 90-644306
ANTTI SALAVA/ MUNKKINIEMEN PUISTOTIE 17 - A 13/ HELSINKI 33 SF-00330/ FINLAND/ 90-486288
MARKKU SUNIl COMPUTER CENTRE/ UNIVERSITY OF TURKU/ TURKU SO SF-20S00/ FINLAND/ 921-335 599
JUHA HEINANEN/ COMPUTER CENTER/ UNIVERSITY OF TAMPERE/ P.O. BOX 607/ TAMPERE 10 SF-33101/ FINLAND/ 931-651595
O. LECARME/ I.M.A.N./ UNIVERSITE DE NICE/ PARe VALROSE/ NICE CEDEX F-06034/ FRANCE/51 91 00
MICHEL GALINIER/ INFORMATIQUE/ UNIVERSITE P. SABATIER/ 118 ROUTE DE NARBONNE/ TOULOUSE CEDEX F-31077/ FRANCE/ 16-61~53 11 20
P. MAURICE/ INFORMATIQUE/ UNIVERSITE PAUL SABATIER/ 118 ROUTE DE NARBONNE/ TOULOUSE CEDEX F-31077/ FRANCE
ATTN: C.R.I.G./ INSTITUT UNIVERSITAIRE DE TECHNOLOGIE/ MONTPELLIER F-34000/ FRANCE
JEAN BEZIVIN/ DEPARTEMENT DE MATHEMATIQUES & INFORMA/ UNIVERSITE DE RENNES/ RENNES CEDEX F-3S031/ FRANCE/ 36.48.15
JEAN-PIERRE FAUCHE/ DEPARTMENT INFORMATIQUE/ IREP/ BOlTE POSTALE 47/ GRENOBLE CEDEX F-38040/ FRANCE
ALAIN TISSERANT/ DEPARTEMENT INFORMATIQUE/ ECOLE DES MINES/ PARC DE SAURUPT/ NANCY CEDEX F-54042/ FRANCE
DIDIER THIBAULT/ 17 RUE GAY-LUSSAC/ PARIS F-7S005/ FRANCE/ 527 16 85
JACQUES FARRE/ T 55.65/ INSTlTUT DE PROGRAMMATION/ 4 PLACE JUSSIEU/ PARIS CEDEX OS F-75230/ FRANCE/ 336 25 25 X58 77
HUBERT LEYGRAF/ INSTITUT FUR ETALLURGIE/ TECHNISCHE UNIVERSIT AT BERLIN/ JOACHIMSALER STR. 31/32/ BERLIN D-l000/ GERMANY

:z
rn
::E
(/)

(/)

rn
"""tJ

--I

rn

:::s:
tJ;:!

rn
::0

N
'-J

0-1000 GERMANY
0-1000 GERMANY
0-1000 GERMANY
0-1000 GERMANY
0-1000 GERMANY
0-1000 GERMANY
0-1000 GERMANY
0-1000 GERMANY
0-1000 GERMANY
0-2000 GERMANY
0-2000 GERMANY
0- 2000 GERMANY
0-2000 GERMANY
0-2000 GERMANY
0-2000 GERMANY
0-2000 GERMANY
0-2000 GERMANY
0-2000 GERMANY
0-2000 GERMANY
0-3000 GERMANY
0- 3000 GERMANY
0-5000 GERMANY
0-5100 GERMANY
0-5205 GERMANY
0-5300 GERMANY
0-6100 GERMANY
0-6300 GERMANY
0-6750 GERMANY
0-6750 GERMANY
0-7000 GERMANY
0-7408 GERMANY
0-7500 GERMANY
0-7500 GERMANY
0-7500 GERMANY
0-7500 GERMANY
0-7500 GERMANY
0-7500 GERMANY
0-7500 GERMANY
0-7500 GERMANY
0-7750 GERMANY
0-8000 GERMANY
0-8000 GERMANY
0-8000 GERMANY
0-8000 GERMANY
0-8000 GERMANY
0-8000 GERMANY
0-8000 GERMANY
0-8000 GERMANY
0-8000 GERMANY
0-8000 GERMANY
0-8000 GERMANY
0-8012 GERMANY
0-8012 GERMANY
0-8031 GERMANY
0-8520 GERMANY
0-8551 GERMANY
500762 INOlA
2 IRELANO
ISRAEL
ISRAEL
ISRAEL
ISRAEL
ISRAEL
ISRAEL
ISRAEL
ISRAEL

ALBRECHT BIEDL/ INSTITUT FUR SOFTWARE/ OV-GRUNDAUSBILDUNG/ TECHNISCHE UNIVERSITAT BERLIN / VSH 5/ OTTO-SUHR-ALLEE 18/20/ BERLIN 100-1000/ GERMANY
ROLF SCHUMACHER/ JEBENSSTR. 1/ BERLIN 10 0-1000/ GERMANY/ 030 393 18 12
THOMAS HABERNOLL/ TURMSTR. 19/ BERLIN 21 0-1000/ GERMANY/ (030) 394 56 91
WOLFGANG HAMPE/ WILHELMSHAVENER STR. 47/ BERLIN 21 0-1000/ GERMANY
LUTZ CHRISTOPH/ SCHUTZALLEE 52/ BERLIN 37 D-I000/ GERMANY/ (030) 811-1743
WERNER F. PRAUTSCH/ ALBERTINENSTRASSE 29/ BERLIN 37 D-1000/ GERMANY/ (030) 801 11 88
THOMAS WAGNER/ AHORNSTRASSE 16/ BERLIN 41 0-1000/ GERMANY/ (03U) 7925361
KAY BITTERLING/ SCHOENBURGSTR. 1/ BERLIN 42 D-1000/ GERMANY/ (U30) 7524517
PETER NELLESSEN/ MARTIN-OPITZ STR. 20/ BERLIN 65 0-1000/ GERMANY/ (030) 39393593
ATTN: INSTITUT FUER INFORMATIK/ UNIVERSIIAT HAMBURG/ SCHLUETERSIRASSE 70/ HAMBURG 13 D-2000/ GERMANY
GERHARD FRIESLAND/ INSTITUT FUER INFORMATIK/ UNIVERSITAT HAMBURG/ SCHLUTERSTRASSE 66-72/ HAMBURG 13 0-2000/ GERMANY/ 040-4123 X4170
H.-H. NAGEL/ INSIlTUT FUER INFORMATIK/ UNIVERSITAT HAMBURG/ SCHLUTERSTRASSE 66-72/ HAMBURG 13 D-2000/ GERMANY
THOMAS BERNER/ BURGERWEIDE 77/ HAMBURG 26 D-2000/ GERMANY/ 040-2506602
PETER KLAUBERG/ C/O HAMBURGISCHE ELECTRICITAETS-WERKE/ UEBERSEERING 12/ HAMBURG 60 D-2000/ GERMANY/ 040 636 2614
CARSTEN KOCH/ OISTRIKT NORD/ CONTROL DATA GMBH/ UBERSEERING 131 HAMBURG 6002000/ GERMANY/ 630 80 21 - 25
CARSTEN KOCH (B)/ OERTZWEG 32/ HAMBURG 60 D-2000/ GERMANY/ 6901884
BERND BRUGGE/ VIELOHWEG 164/ HAMBURG 61 0-2000/ GERMANY
KLAUS LIEBENWALD/ BOHMESTRASSE 8/ HAMBURG 70 D-2000/ GERMANY/ U40-686036
BERNHARD NEBEL/ STEGLIIZER SIR. 17F/ HAMBURG 70 D-2000/ GERMANY/ 040/664911
ROLF SONNTAG/ RICHARD WAGNER SIR. 27/ HANNOVER 1 0-3000/ GERMANY
G. MARQUARDT/ REGIONALES RECHENZENTRUM/ WUNSTORFER SIR. 14/ HANNOVER 91 D-3000/ GERMANY
DIETRICH KREKEL/ RECHEN ZENTRUM/ UNIVERSITAT ZU KOLN/ ROBERT KOCH STR 10/ KOLN 41 D-5000/ GERMANY/ 0221/478/5587
ATE PHUNG/ KREFELOER STR. 23/ AACHEN D-5100/ GERMANY
HORST SANTO/ POSIFACH 1240/ GMD MBH/ SCHLOSS BIRLINGHOVEN/ ST. AUGUSTIN 10-5205/ GERMANY
G. ENGELIEN/ MAX-PLANCK-INSTITUI FUR RAOIOASTRONOMl/ AUF OEM HUGEL 69/ BONN 1 D-5300/ GERMANY
H.-J. HOFFMANN/ FACHBEREICH INFORMATIK/ TECHNISCHE HOCHSCHULE DARMSTADT/ STEUBENPLATZ 12/ OARMSTADT D-6100/ GERMANY/ (06151) 163410
DIETER WEISS/ HOCHSCHULRECHENZENTRUM (HRZ)/ DER JUSTUS LIEBIG-UNIVERSITAT/ LEIHGESTERNER WEG 217/ GIESSEN D-6300/ GERMANY/ (0641) 702-2514
ATTN: BIBLIOTHEK/ UNIVERSITAT KAISERSLAUTERN/ P.O. BOX 2040/ KAISERSLAUIER 0-6750/ GERMANY/ (0631) 8541
HAN.S-WILM WIPPERMANN/ INFORMATIK/ Fl3/ UNIV. OF KAISERSLAUTERN / PFAFFENBERGSIR. 95/ KAISERSLAUTER D-6750/ GERMANY/ (0631) 854 2635
WALTER WEHINGER/ LANGUAGES AND PROCESSORS GROUP/ RECHENZENTRUMI UNIVERSITAT STUTTGART/ PFAFFENWALDRING 64/ STUTTGART 80 D-7000/ GERMANY/ 0711-784 2507
ASHOK N. ULLAL/ GOETHESTR. 10/ KUSTERDINGEN D-7408/ GERMANY
KARLHEINZ KAPP/ ANGEW. INFORMATIK/ UNIVERSITAET KARLSRUHE/ TRANSPORT-U. VERKEHRSSYSTEME/ KARLSRUHE D-7500/ GERMANY/ (0721) 608-3170/3898
ROLF G. KNOEPKER/ GESELLSCHAFT FUER KERNFORSCHUNG/IOT/ P.O.B. 3640/ KARLSRUHE D-7500/ GERl~Y
MANFRED SEIFERT/ INFORMATIK 111/ UNIVERSITAT KARLSRUHE/ ZIRKEL 2/ KARLSRUHE D-7500/ GERMANY/ 0721/608-3982
ATTN: INST. FUR ANGEWANOTE MATHEMATIK/ UNIVERSITAT KARLSRUHE (TH)/ KAISERSTR. 12 - POSTFACH 6380/ KARLSRUHE 1 D-7500/ GERMANY
LUCIEN FEIEREISEN/ HAID-&-NEU-STR. 16 / W 81/ KARLSRUHE 1 D-7500/ GERMANY
GERHARD GOOS/ INSTITUT FUER INFORMATIK 11/ UNIVERSITAT KARLSRUHE/ POSTFACH 6380/ KARLSRUHE 1 D-7500/ GERMANY/ 0721/608-3970
8RUNO LORTZ/ RECHENZENTRUM/ UNIVERSITAET KARLSRUHE/ ZIRKEL 2/ KARLSRUHE 1 0-7500/ GERMANY
KLAUS R. OITTRICH/ UNIVERSITY KARLSRUHE/ DURMERSHElMER STR. 77 1 KARLSRUHE 21 0-7500/ GERMANY/ 0721-555506
DIRK KRONIG/ AEG-TELEFUNKEN/ POSTFACH 2154/ KONSTANZ 0-7750/ GERMANY/ 07531-862066
MANFRED SOMMER/ DEPARTMENT 0 AP GE/ SIEMENS AG/ HOFFMANNSTRASSE/ MUENCHEN D-8000/ GERMANY/ 089-722-61276
HELLMUT WEBER/ LEIBNIZ-RECHENZENTRUM/ BARERSTRASSE 21/ MUENCHEN 2 D-8000/ GERMANY/ (089) 2105-8489
PETER RAUSCHMAYER/ LUITPOLO-GYMNASIUM/ SEEAUSTR. 1/ MUENCHEN 22 0-8000/ GERMANY/ 226587
MANFRED LUCKMANN/ ALEMANNENSTR. 24/ MUENCHEN 90 0-8000/ GERMAN Y
E. OENERT/ SOFTLAB GMBH/ SEDERANGER 4-6/ MUNCHEN 22 D-8000/ GERMANY/ 089/347051-55
S. ROHLFS/ SOFTLAB GMBH/ SEDERANGER 4-6/ MUNCH EN 22 0-8000/ GERMANY/ 089/347051-55
P. SCHNUPP/ SOFTLAB GMBH/ SEDERANGER 4-6/ MUNCHEN 22 0-8000/ GERMANY/ 089/347051-55
ATTENTION: JAN WITT/ ZFE FL SAR/ SIEMENS AG/ HOFMANNSTR. 51/ MUNCHEN 70 0-8000/ GERMANY/ (089) 722-22651
WERNER REMMELE/ ZFE FL SAR 12/ SIEMENS AG/ HOFMANNSTR. 51/ MUNCHEN 70 0-8000/ GERMANY
ATTN: INSTITUT FUR MEO. OATENVERARBEIT/ STRAHLEN- UND UMWELTFO.RSCHUNG GMBH/ ARABELLASTR. 4/1/ MUNCHEN 81 0-8000/ GERMANY/ (089) 911061-68
ROLANO F. BLOMER/ IMD OER GSF/ ARABELLASTR 4/1/ MUNICH 81 0-8000/ GEID1ANY/ 089/ 91 10 66
BERNHARD H. BEITINGER/ INDUSTRIEANLAGEN-BETRIEBSGESELLSCHAFT/ EINSTEINSTRASSE/ OTTOBRUN 0-8012/ GERMANY
HERBERT F. BISCHELTSRIEDER/ C/O INOUSTRlEANLAGEN-BETRIEBS GMBH 1 ABTEILUNG SZF/ OTTOBRUNN 0-8012/ GERMANY
RAINER R. LATKA/ AN OER GRUNOBREITE 1/ WESSLING D-8031/ GERMANY/ 089/229131 (CSIO MUNICH)
ATTN: REGIONALES RECHENZENTRUM/ UNIVERSITAET ERLANGEN-NURNBERGI MARTENSSTR. 1/ ERLANGEN 0-8520/ GERMANY/ 09131/85 7410
REINHOLO WEICKER/ WEIHERSTR. 14/ HEMHOFEN 0-8551/ GERMANY
ATTENTION: N. V. KOTESWARA RAO/ COMPUTER TEG. UNIT/ ELECTRONICS CORPORATION OF INOIA/ HYOERABAD (AP) 500762/ INOIA/ 71611
O. ABRAHAMSON/ OEPT. OF COMPUTER SCIENCE/ TRINITY COLLEGE/ 200 PEARSE ST./ OUBLIN 2/ IRELANO
MICHAEL Z. HANANI/ COMPUTATION CENTER/ BEN GURIAN UNIVERSITY OF THE NEGEV/ BEER-SHEVA/ ISRAEL
ATTN: THE LIBRARY/ MINISTRY OF DEFENCE/ P.O.BOX 962/ HAIFA/ ISRAEL
MENACHEM SZUS/ ART ANO SCIENCE/ BEZALEL ACADEMY OF ART ANO OESIGN/ 10 SHMUEL HANAGIO ST./ JERUSALEM/ ISRAEL/ JERUSALEM 32579
RUTH WEINBERG/ COMPUTATION CENTER/ HEBREW UNIVERSITY OF JERUSALEM/ JERUSALEM/ ISRAEL/ 02-32011/280
GIDEON YUVAL/ COMPUTER SCIENCE/ THE HEBREW UNIVERSITY/ JERUSALEM/ ISRAEL
ATTENTION: M. MALKOSH/ DEPT OF APPLIED MATHEMATICS - GOLEM GR/ WEIZMANN INST. OF SCIENCE/ REHOVET/ ISRAEL/ (03) 951721 X2124
SAM LIBAI/ SDS COMPUTERS LTD./ P.O. BOX 29663/ TEL AVIV/ ISRAEL/ 53054
IRVING N. RABINOWITZ/ OEPT. OF COMPo SCI./ TECHNION-ISRAEL INSTITUTE OF TECHNOLOG/ TECHNION CITY HAIFA/ ISRAEL

(/)

rn
-0
-l

rn
::s:
tel

rn
:;c

-0
):>

G>

rn
N

00

1-34100
1-40122
1-40122
1-56100
113
113
143
182
210

ITALY
ITALY
ITALY
ITALY
JAPAN
JAPAN
JAPAN
JAPAN
JAPAN

222 JAPAN
400 JAPAN
~OO JAPAN
560 JAPAN
LIBYA
MALAYSIA
NEW ZEALAND
NEW ZEALAND
N-2007 NORWAY
1 NORWAY
3 NORWAY
00901 POLAND
PORTUGAL
SOUTH AFRICA
0001 SOUTH AFRICA
4000 SOUTH AFRICA
4001 SOUTH AFRICA
b140 SOUTH AFRICA
12 SPAIN
14 SPAIN
S-100 44 SWEDEN
S-100 44 SWEDEN
S-126 25 SWEDEN
S-145 72 SWEDEN
S-161 54 SWEDEN
S-l72 04 SWEDEN
S-220 07 SWEDEN
S-220 07 SWEDEN
S-223 62 SWEDEN
S-281 00 SWEDEN
5-341 00 SWEDEN
S-402 20 SWEDEN
S.,.431 20 SWEDEN
S-431 39 SWEDEN
S-434 00 SWEDEN
S-461 01 SWEDEN
S-581 83 SWEDEN
S-603 78 SWEDEN
S-751 21 SWEDEN
S-751 21 SWEDEN
S-751 21 SWEDEN
S-752 23 SWEDEN
CH-1007 SWITZERLAND
CH-1007 SWITZERLAND
CH-1200 SWITZERLAND
CH-1200 SWITZERLAND
CH-1205 SWITZERLAND
CH-1207 SWITZERLAND
CH-1211 SWITZERLAND
CH-1211 SWITZERLAND
CH-1211 SWITZERLAND
CH-1211 SWITZERLAND
CH-1211 SWITZERLAND
CH-1211 SWITZERLAND
CH-2000 SWITZERLAND
CH-3000 SWITZERLAND

MATTIA HMELJAK/ CENTRO DI CALCOLO/ UNIVERSITA DI TRIESTE/ VIA DEL RONCO 11/ TRIESTE 1-34100/ ITALY/ 040-733033
MAORO MONTESI/ TEMA SPA/ VIA MARCONI 29/1/ BOLOGNA 1-40122/ ITALY/ 051-267285
GUISEPPE SELVE/ TEMA S.P.A./ VIA MARCONI 29/1/ BOLOGNA 1-40122/ ITALY/ 051-267285
MARCO SOMMANI/ C/O CNUCE/ VIA SANTA MARIA 36/ PISA 1-56100/ ITALY/ (050) 45245
TERUO HIKITA/ DEPT. OF INFO. SCI./ U OF TOKYO/ BUNKYO-KU/ TOKYO 113/ JAPAN/ 03-812-2111 X2947
EIlTI WAOA/ DEPARTMENT OF MATHEMATICAL ENGINEERING/ UNIVERSITY. OF. T!JKyoLBUNKlrOKU TOKYO 113/ JAPAN/ (03) 812-2111 X7486
TOSHIAKI SAISHO/ 1-25-7 KITAMAGOME/ OOTA-KU TOKYO 143/ JAPAN
MASATO TAKEICHI/ DEPT. OF COMPUTER SCIENCE/ THE UNIV. OF ELECTRO-COMMUNIC~TIONS/ 1-5-1 CHOFUGAOKA/ CHOFU-SHI TOKYO 182/ JAPAN
SUSUMU YOSHIMURA/ INFORMATION SYSTEMS LAB./ 1 KOMUKAI TOSHIBA-CHO, TOSHIBA RESEARCH AND DEVELOPMENT/ SAIWAI-KU KAWASAKI-CITY 210r JAPAN
(044) 511 2111 X2489
MASARU WATANABE/ 9-16 SHINOHARADAI/ KOHOKU-KU YOKOHAMA 222/ JAPAN/ (045) 401-9324
Ml

en
n
:J>

r
:z
rn
:::E

en

en
rn

-c
-I

rn
3:
tx:I

rn
;;0

.....
lD

.......
.......

-c
:J>
G>

rn
N
lD

CH-8021
CH-8027
CH-8035
CH-8092
CH-8092
CH-8092
CH-8092

SWITZERLAND
SWITZERLAND
SWITZERLAND
SWITZERLAND
SWITZERLAND
SWITZERLAND
SWITZERLAND
CH~8092 SWITZERLAND
CH-8092 SWITZERLAND
CH-9470 SWITZERLAND
THE NETHERLANDS
THE NETHERLANDS
THE NETHERLANDS
THE NETHERLANDS
THE NETHERLANDS
THE NETHERLANDS
THE NETHERLANDS
THE NETHERLANDS
THE NETHERLANDS
THE NETHERLANDS
THE NETHERLANDS
THE NETHERLANDS
THE NETHERLANDS
THE NETHERLANDS
THE NETHERLANDS
THE NETHERLANDS
THE NETHERLANDS
THE NETHERLANDS
THE NETHERLANDS
THE NETHERLANDS
THE NETHERLANDS
THE NETHERLANDS
THE NETHERLANDS
THE NETHERLANDS
THE NETHERLANDS
1005 THE NETHERLANDS
2005 THE NETHERLANDS
2076 THE NETHERLANDS
2231 XE THE NETHERLANDS
2506 THE NETHERLANDS
9321 THE NETHERLANDS
UNITED KINGDOM
UNITED KINGDOM
UNITED KINGDOM
UNITED KINGDOM
UNITED KINGDOM
UNITED KINGDOM
AB9 2UB UNITED KINGDOM
ALI 1NF UNITED KINGDOM
ALI lRZ UNITED KINGDOM
AL10 9AB UNITED KINGDOM
AL10 9AB UNITED KINGDOM
BH22 8HL UNITED KINGDOM
BN1 9QT UNITED KINGDOM
BN2 4GJ UNITED KINGDOM
BN2 6RD UNITED KINGDOM
BN3 IRA UNITED KINGDOM
BS9 4PL UNITED KINGDOM
BT37 OQB UNITED KINGDOM
BT7 INN UNITED KINGDOM
BT9 SEQ UNITED KINGDOM
B15 ZIT UNITED KINGDOM
CB2 1RP UNITED KINGDOM
CV4 7AL UNITED KINGDOM
DE3 6RU UNITED KINGDOM

E. MARMlER/ ORGANISATION AND AUTOMATION/ SWISS CREDIT BANK/ ZURICH CH-8021/ SWITZERLAND
P. J. ERARD/ FIDES COMPUTING CENTER/ BLEICHERWEG 33/ ZURICH CH-8027/ SWITZERLAND/ (41) 12027840
ATTENTION: MAX SEVCIK/ COMPUTER ASSOCIATES INTL. LTD./ STAMPFENBACHSTR. 52 - P.o. BOX/ ZURICH CH-8035/ SWITZERLAND/ 01-60 42 52
URS AMMANN/ INSTITUT FUER INFORMATIK/ ETH - ZENTRUM/ ZUERICH CH-8092/ SWITZERLAND/ 01-32 62 11 X2214
CHRISTIAN JACOBI/ INSTITUT FUER INFORMATIK/ ETH - ZENTRUM/ ZUERICH CH-8092/ SWITZERLAND/ 41 1 32 62 11 X2217
SVEND ERIK KNUDSEN/ INSTITUT FUER INFORMATIK/ ETH - ZENTRUM/ ZUERICH CH-8092/ SWITZERLAND/ (01) 32 62 11 X2217
NIKLAUS WIRTH/ INSTITUT FUER INFORMATIK/ ETH - ZENTRUM/ ZUERICH CH-8092/ SWITZERLAND
ATTN: RZ - BIBLIOTHEK/ ETH - ZENTRUM/ ZURICH CH-8092/ SWITZERLAND/ 01-32 62 11
HANS-HEINRICH NAGELI/ INSTITUT FUER INFORMATIK/ E.T.H. - ZENTRUM/ ZURICH CH-8092/ SWITZERLAND/ 01/32 62 11
HELMUT SANDMAYR/ NED-TECHNIKUM BUCHS/ BUCHS CH-9470/ SWITZERLAND/ CH-085/6 45 24
ATTN: SARA-LIBRARY/ P.O. BOX 7161/ AMSTERDAM/ THE NETHERLANDS/ 020-5484911
W. DE VRIES/ C/O I.K.O./ POSTBOX 4395 - OOSTERRINGDIJK 18/ AMSTERDAM/ THE NETHERLANDS
D. GOSMAN/ ZEEMAN LABORATORIUM/ UNIVERSITEIT VAN AMSTERDAM/ PLANTAGE MUIDERGRACHT 4/ AMSTERDAM/ THE NETHERLANDS/ 020-5222177
A. C. W. LEYEN/ DEPARTMENT MSE/ C/O KONINKLIJKE/ SHELL-LABORATORIUM/ P.O. BOX 3003/ AMSTERDAM/ THE NETHERLANDS/ 070-203264
ANDREW S. TANENBAUM/ WISKUNDIG SEMINARIUM/ VRIJE UNIVERSITEIT/ DE BOELELAAN 1081/ AMSTERDAM/ THE NETHERLANDS/ 020 548 24 10
R. P. VAN DE RIET/ VRIJE UNIVERSITEIT/ DE BOELELAAN 1081/ AMST ERDAM/ THE NETHERLANDS/ 020-5482410
P. VAN EMUE BOAS/ ITW / VPW UVA/ ROETERSSTRAAT 15/ AMSTERDAM C, THE NETHERLANDS/ 020-522 3065
STEPHEN G. S. PROUT/ MeR. BUCKXSTRAAT 18/ BORN (L)/ THE NETHERLANDS/ 04498-2481
G. E. VAN BEINUM/ TNO-iBBe/ POSTBOX 49/ DELFT/ THE NETHERLANDS, 015-138222 EXT 250
ATTN: BIBLIOTHEEK 05627/ TECHNISCHE HOGESCHOOL/ POSTBUS 513/ EINDHOVEN/ THE NETHERLANDS
LEO C. NOORDHUIZEN/ GLOEILAMPEN - FABRIEKEN/ BUILDING VN-521/ N.V. PHILIPS/ EINDHOVEN/ THE NETHERLANDS/ 040-783634
J. J. VAN AMSTEL/ COMPUTING CENTRE/ EINDHOVEN ONIVERSITY OF TECHNOLOGY/ P.O. BOX 513/ EINDHOVEN/ THE NETHERLANDS/ (040) 474547
C. BRON/ DEPT. OF ELECTRICAL ENGINEERING/ TECHNISCHE HOGESCHOOL !WENTE/ POSTBUS 217/ ENSCHEDE/ THE NETHERLANDS/ (031) 53 894451
S. D. SWIERSTRA/ TECHNISCHE HOGESCHOOL TWENTE/ P.O. BOX 217/ ENSCHEDE/ THE NETHERLANDS/ 31-53-894441
ATTN: DSM/ CENTRAL LIBRARY/ P.O. BOX 18/ GELEEN/ THE NETHERLANDS
LOU H. KRAMER/ CALLUNALAAN 8/ GOUDA/ THE NETHERLANDS/ 070 - 264221
D. D. DE VRIES/ LANDLEVEN 1/ REKENCENTRUM R.U.G./ P.O. BOX 800, GRONINGEN/ THE NETHERLANDS
TOM VAN DER HOEVEN/ HAGEDOORNSWEG/ NIEBERT/ THE NETHERLANDS
P. F. KLOK/ COMPUTER GRAPHICS/ KATHOLlEKE UNIVERSITEIT/ TOERNO OIVELD/ NIJMEGEN/ THE NETHERLANDS/ 080-558833 X3201
L. S. C. STATEMA/ UNIVERSITY COMPUTING CENTRE/ TOURNOOIVELD 1/ NIJMEG&~/ THE NETHERLANDS/ 080-558833 X2590
ATTN: INSTITUTE TNO FOR MATHEMATICS/ COMPUTER CENTRE/ INFORMATION PROCESSING AND STATISTICS/ KONINGIN MARIALAAN 21/ THE HAGUE/ THE NETHERLANDS
070-824161
D. SANDEE/ PHYSICS LABORATORY TNO/ P.O. BOX 2864/ THE HAGUE/ THE NETHERLANDS/ (070) 264221
P. A. SLATS/ INFORMATION PROCESSING AND STATISTICS/ INST. TNOFOR MATHEMATICS/ KON. MARIALAAN 21/ THE HAGUE/ THE NETHERLANDS
P. J. VAN DER HOFF / PIJPERSTRAAT 5/ BERKEL EN RODENRIJS/ THE NETHERLANDS
H. VAN .LOON/ ACADEMlSCH COMPUTER CENTRUM UTRECHT/ BUDAPESTLAAN 6/ DE UITHOF UTRECHT/ THE NETHERLANDS/ 030-531436
ATTN: LIBRARY/ MATHEMATISCH CENTRUM/ 2E BOERHAAVESTRAAT 49/ AMSTERDAM 1005/ THE NETHERLANDS
ATTN: BOEKHANDEL VERWIJS EN STAM B.V./ PRINSESSEGRACHT 2/ 'S-GRAVENHAGE 2005/ THE NETHERLANDS
N. D. BREWER/ MATHEMATICS AND COMPUTER DIV./ SHAPE TECHNICAL CENTRE/ P.O. BOX 174/ THE HAGUE 2076/ THE NETHERLANDS/ 070-24.55.50
JEAN-PIERRE BOUCHEZ/ ELZENLAAN 6/ RIJNSBURG 2231 XE/ THE NETHERLANDS
J. A. ALANEN/'VAKGROEP INFORMATICA R.U. / BUDAPESTLAAN 6/ UTREC.T 2506/ THE NETHERLANDS
T. J. VAN WEERT/ ELZENLAAN 28/ PEIZE GN 9321/ THE NETHERLANDS
C. B. KING/ PHILIPS RESEARCH LABORATORIES/ CROSS OAK LANE / REDHILL/ SURREY ENGLAND/ UNITED KINGDOM/ HORLEY 6377
ATTN: THE DOCUMENTATION OFFICER/ COMPUTING LABORATORY/ UNIVERSITY OF KENT/ CANTERBURY KENT/ UNITED KINGDOM
STEPHEN L. BREIBART/ EASTCOTE/ 12 ELM AVENUE/ PINNER MIDDLESEX, UNITED KINGDOM
MAURICE O'FLARERTY/ ANTRIM/ 444 MEVILLE GARDEN VILLAGE/ NEWTOWNABBEY N. IRELAND/ UNITED KINGDOM
ROBERT G. CLARK/ DEPT. OF COMPUTING SCIENCE/ UNIVERSITY OF STI RLING/ STIRLING SCOTLAND/ UNITED KINGDOM
N. J. FIDDIAN/ DEPT. OF COMPUTING MATHEMATICS/ UNIVERSITY COLLEGE CARDIFF/ CARDIFF WALES/ UNITED KINGDOM/ 44211 CARDJFF X2669
DENIS M. WILSON/ DEPARTMENT OF COMPUTING SCIENCE/ UNIVERSITY 0 F ABERDEEN/ KING-S COLLEGE/ OLD ABERDEEN SCOTLAND AB9 2UB/ UNITED KINGDOM
J M JENKIN/ 23 HART ROAD/ ST ALBANS HERTS. ALI 1NF/ UNITED KINGDOM/ 68026
M. I. JACKSON/ 165 RIVERSIDE ROAD/ ST ALBANS HERTS. ALI 1RZ/ UNITED KINGDOM/ HATFIELD 68100 X252
BOB DICKERSON/ COMPUTER SYSTEMS GROUP/ THE HATFIELD POLYTECHNIC/ PO BOX 109 COLLEGE LANE/ HATFIELD HERTS AL10 9AB/ UNITED KINDOM/ HATFIELD 68100
JOHN W. LEWIS/ SCHOOL OF INFORMATION SCIENCES/ HATFIELD POLYTECHNIC/ P.O. BOX 109/ HATFIELD HERTS AL10 9AB/ UNITED KINGDOM/ 68100 X237
DAVID SPENCER/ 29 DORSET AVE./ FERNDOWN DORSET BH22 8HL/ UNITED KINGDOM/ 0202 875571
R. L. GRIMSDALE/ SCHOOL OF'APPLIED SCIENCES/ UNIVERSITY OF SUS SEX/ FALMER/ BRIGHTON ENGLAND BN1 9QT/ UNITED KINGDOM/ (0273).66755
ATTENTION: B.S. MOSSAKOWSKI/ DEPT. OF COMPUTING AND CYBERNETICS/ BRIGHTON POLYTECHNIC/ MOULSECOOMB/ BRIGHTON ENGLAND BN2 4GJ/ UNITED KINGDOM
D. A. JOSLIN/ WOODINGDEAN/ 40 BATEMANS ROAD/ BRIGHTON SUSSEX BN2 6RD/ UNITED KINGDOM/ BRIGHTON 37772
B. WILLIAML/ 67 DAVIGDOR ROAl)/ HOVE SUSSEX BN3 1RA/ UNITED KINGDOM
ALAN BLANNIN/ WESTBURY-ON-TRYM/ 28 HARBURY ROAD/ BRISTOL ENGLAND BS9 4PL/ UNITED KINGDOM/ (0272) 624808
C. J. COPELAND/ SCHOOL· OF COMPUTER SCIENCE/ ULSTER COLLEGE/ JORDANSTOWN/ NEWTOWNABBEY N.IRELAND BT37 OQB/ UNITED KINGDOM/ 0231-65131 X2131
JIM WELSH/ DEPARTMENT OF COMPUTER SCIENCE/ QUEEN'S UNIVERSITY/ BELFAST N.IRELAND BT7 1NN/ UNITED KINGDOM
ATTN: SCIENCE LIBRARY/ QUEEN'S UNIVERSITY/ BELFAST N. IRELAND BT9 5EQ/ UNITED KINGDOM
ALAN REED/ COMPUTER CENTRE/ UNIVERSITY OF BIRMINGHAM/ BIRMINGHAM ENGLAND B15 2TT/ UNITED KINGDOM
C. A. LANG/ PITT BUILDING/ CAMBRIDGE UNIVERSITY PRESS/ TRUMPINGTON ST./ CAMBRIDGE ENGLAND CB2 1RP/ UNITED KINGDOM/ 0223-53301
ATTN: COMPUTER UNIT/ COMPUTER CENTER/ UNIVERSITY OF WARWICK/ COVENTRY ENGLAND CV4 7AL/ UNITED KINGDOM/ (0203) 24011 X2754
G. OAKES/ 45 HAMILTON ROAD/ DERBY ENGLAND DE3 6RU/ UNITED KINGDOM

DH1
EC3V
EH1
E1

3LE
1LP
2HW
4NS
E14
GU16 5HJ
GU16 5HJ
G12 8QQ
G12 8QQ
G12 8QQ
HA4 9DP
HA6 3DZ
HP2 5HG
HR1 1TY
HU6 7RX
KIl2 5NF
KY16
LA1 4YB
LA1 4YX
LA1 4YX
LA1 4YX
LA1 4YX
LA1 4YX
LA1 4YX
LA1 4YX
LA1 4YX
LA1 4YX
LA1 4YX
LE1 7RH
LS2 9JT
MK40 2PN
M13 9PL
M13 9PL
M13 9PL
M20 9QL
M5 4WT
M60 1QD
M60 1QD
NPT 1XG
NR4 7TJ
NW3
Nw3 7ST
N10
N8
OX 11 OQX
OX11 OQX
PE17 3QB
RG1 7QN
RG6
SA2
SE1
S09
S09
S09
S09
509
S09
ST5

2LH
8PP
OAA
5NH
5NH
5NH
5NH
5NH
5NH
5BG
SWll
SW7 2AZ
SW7 2AZ
SW7 2AZ

UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED

KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM

UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED
UNITED

KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM
KINGDOM

SW7 2AZ UNITED KINGDOM
SW7 2AZ UNITED KINGDOM

H. F. TIBBALS! COMPUTER UNIT! SCIENCE LABORATORIES! DURHAM UNlV.! DURHAM ENGLAND DH1 3LE! UNITED KINGDOM! DURHAM 64971
PHILIP J. MALCOLM! C!O BANK OF ADELAIDE! 11 LEADENMALL ST.! LONDON ENGLAND EC3V 1LP! UNITED KINGDOM! 01-323 0637!0
A. BALFOUR! COMPUTER CENTRE! HERIOT-WATT UNIVERSITY! 37-39 GRASSMARKET! EDINBURGH SCOTLAND EH1 2HW! UNITED KINGDOM
JOHN HUTCHINSON! COMPUTER CENTRE! QUEEN MARY COLLEGE! MILE END ROAD! LONDON ENGLAND E1 4NS! UNITED KINGDOM! 01-980-4811 X778
ISAMU HASEGAWA! 7 STAINSBURY ROAD! LONDON ENGLAND E14! UNITED KINGDOM
ANTHONY LESLIE GOLBORN! SYSTEMS DESIGNERS LIMITED! SYSTEMS HOU SEt '57-61 HIGH STREET! FRIMLEY SURREY GU16 5HJ! UNITED KINGDOM
VIC STENNING! SYSTEMS DESIGNERS LTD.! 57-61 HIGH STREET! FRIMLEY SURREY GU16 5HJ! UNITED KINGDOM
BILL FINDLAY! COMPUTING SCIENCE DEPARTMENT! UNIVERSITY OF GLASGOW! GLASGOW SCOTLAND G12 8QQ! UNITED KINGDOM! 339 8855 X7391
D. G. JENKINS! COMPUTING SCIENCE DEPT.! THE UNIVERSITY! GLASGOW SCOTLAND G12 8QQ! UNITED KINGDOM! (041) 339-8855 X478!7458
DAVID WATT! COMPUTING SCIENCE DEPT.! UNIVERSITY OF GLASGOW! GLASGOW SCOTLAND G12 8QQ! UNITED KINGDOM! 041-339 8855 X7458
ROBERT KIRKBY! RUISLIP MANOR! 44 WHITBY ROAD! MIDDLESEX ENGLAN D HA4 9DP! UNITED KINGDOM
N ROBINSON! 1 THE FAIRWAY! NORTHWOOD MIDDLESEX! LONDON ENGLAND HA6 3DZ! UNITED KINGDOM
C. B. A. PRICE! CBAP SERVICES! 67 FIGTREE HILL! HEMEL! HEMPSTEAD HERTS HP2 5HG! UNITED KINGDOM! 0442 57340
A. J. FISHER! 2 ELGAR AVENUE! HEREFORD ENGLAND HR1 1TY! UNITED KINGDOM
B. J. CORNELIUS! DEPT. OF COMPo STUDIES! UNIVERSITY OF HULL! HULL ENGLAND HU6 7RX! UNITED KINGDOM! (0482) 497951
DAN C.C. HAMM! HERSHAM! 85 QUEENS ROAD! WALTON-ON-THA SURREY KT12 5NF! UNITED KINGDOM! WALTON-ON-THAMES 43639
B. T. MITCHELL! COMPUTING LABORATORY! UNIVERSITY OF ST. ANDREWS! NORTH HAUGH ST. ANDREWS! FIFE SCOTLAND KY16! UNITED KINGDOM
D. R. ALLUM! DEPT. OF PHYSICS! UNIVERSITY OF LANCASTER! LANCASTER ENGLAND LA1 4YB! UNITED KINGDOM! LANCASTER 65201 X4178
ATTN: THE LIBRARIAN! DEPT. OF COMPUTER STUDIES! U OF LANCASTER/ BAILRIGG! LANCASTER ENGLAND LA1 4YX! 'UNITED KINGDOM! (0524) 65201 X4133
ANN V. BARROW! DEPT. OF COMPUTER STUDIES! UNIVERSITY OF LANCASTER! BAILRIGG! LANCASTER ENGLAND LA1 4YXi UNITED KINGDOM! (0524) 65201
BOB E. BERRY! DEPT. OF COMPUTER STUDIES! UNIVERSITY OF LANCASTER! BAILRIGG! LANCASTER ENGLAND LA1 4YX! UNITED KINGDOM! (0524) 65201
MIKE W. CORNELIUS! DEPT. OF COMPUTER STUDIES! UNIVERSITY OF LANCASTER! BAILRIGG! LANCASTER ENGLAND LA1 4YX! UNITED KINGDOM/ (0524) 65201 X4120
ARTHUR FOSTER! DEPT. OF COMPUTER STUDIES! UNIVERSITY OF LANCASTER! BAILRIGG! LANCASTER ENGLAND LA1 4YX! UNITED KINGDOM! (0524) 65201 X4123
BRIAN A. E. MEEKINGS! DEPT. OF COMPUTER STUDIES! UNIVERSITY OF LANCASTER! BAILRIGG! LANCASTER ENGLAND LA1 4YX! UNITED KINGDOM! (0524) 65201
CHRIS D. PAICE! DEPT. OF COMPUTER STUDIES! UNIVERSITY OF LANCASTER! BAILRIGG! LANCASTER ENGLAND LA1 4YX! UNITED KINGDOM! (0524) 65201
HIKMET SAKA! DEPT. OF COMPUTER STUDIES! UNIVERSITY OF LANCASTER! BAILRIGG! LANCASTER ENGLAND LA1 4YX! UNITED KINGDOM! (0524) 65201 X4120
S. P. J. WAGSTAFF! DEPT. OF COMPUTER STUDIES! UNIVERSITY OF LANCASTER! BAILRIGG! LANCASTER ENGLAND LA1 4YX! UNITED KINGDOM! (0524) 65201
CHI YIP! DEPT. OF COMPUTER STUDIES! UNIVERSITY OF LANCASTER! BAILRIGG! LANCASTER ENGLAND LA1 4YX! UNITED KINGDOM! (0524) 65201
H. J. ROWE! COMPUTER LABORATORY! LEICESTER UNIVERSITY! LEICESTER ENGLAND LE1 7RH! UNITED KINGDOM
TONY MITCHELL! DEPT. OF COMPUTER STUDIES! LEEDS UNIV.! LEEDS ENGLAND LS2 9JT! UNITED KINGDOM
B. HALE! THE MERTON CENTRE! PRIME COMPUTER INC.! ST. PETERS STREET! BEDFORD ENGLAND MK40 2PN! UNITED KINGDOM! 0234-65121
A. M. ADDYMAN! DEPARTMENT OF COMPUTER SCIENCE! THE UNIVERSITY! OXFORD ROAD! MANCHESTER ENGLAND M13 9PL! UNITED KINGDOM! 061-273 5466 X6
RIC COLLINS! REGIONAL COMPUTER CENTRE! UNIVERSITY OF MANCHESTER! OXFORD ROAD! MANCHESTER ENGLAND M13 9PL! UNITED KINGDOM! 061-273-8252
M. A. PELL! DEPT. OF COMMUNITY MEDICINE! UNIVERSITY OF MANCHESTER! OXFORD ROAD! MANCHESTER ENGLAND M13 9PL! UNITED KINGDOM! 061-273 8241 XO-X197
GRAHAM J. WHITE! 8 KINNAIRD ROAD! MANCHESTER ENGLAND M20 9QL! UNITED KINGDOM
ATTN: DIRECTOR! COMPUTINC LABORATORY! UNIVERSITY OF SALFORD! S ALFORD ENGLAND 115 4WT! UNITED KINGDOM! 061 - 736 5843 X307
ATTN: THE LIBRARIAN! DEPT. OF COMPUTATION! UMIST! P.O. BOX 88! MANCHESTER ENGLAND M60 1QD! UNITED KINGDOM! 061-2363311 X2178
DEREK COLEMAN! DEPT. OF COMPUTATION! UMIST! P.O. BOX 88! MANCH ESTER ENGLAND M60 1QD! UNITED KINGDOM
GEOFF V KING! BUSINESS STATISTICS OFFICE! CARDIFF ROAD! NEWPORT CWENT NPT 1XG! UNITED KINGDOM! 0633 56111
S. M. JOHNSON! SCHOOL OF MATHS AND PHYSICS! UNIV. OF EAST ANGLIA! UNIVERSITY PLAIN! NORWICH ENGLAND NR4 7TJ! UNITED KINGDOM
H. J. ZELL! 14 KEMP LAY ROAD! LONDON ENGLAND NW3! UNITED KINGDu M
J. B. SLATER! COMPUTER UNIT! WESTFIELD COLLEGE! KIDDERPORE AVENUE! LONDON ENGLAND NW3 7ST! UNITED KINGDOM! 01-435-7141 X520
W. H. L. WILLIAMS! 252 COLNGY HATCH LANE! LONDON ENGLAND N10! UNITED KINGDOM! 01-405-8400
JOHN REYNOLDS! 31 BARRINGTON ROAD! LONDON ENGLAND N8! UNITED KINGDOM! 01-340-2413
ATTN: LIBRARIAN! ATLAS COMPUTING DIV.! RUTHERFORD LABORATORY! CHILTON DIDCOT! OXON ENGLAND OX11 OQX! UNITED KINGDOM! ABINGDON 21900 X6226
CHRISTOPHER S COOPER! C & A DIVISION! RUTHERFORD LABORATORY! CHILTON DIDCOT! OXON ENGLAND OXll OQX! UNITED KINGDOM! ABINGDON(0235) 21900 X6211
A. R. M. WAJIH! EARITH! 15 SCHOOL RD! HUNTINGDON ENGLAND PE17 3QB! UNITED KINGDOM
lAIN SMITH! EUROPEAN SOFTWARE ENGINEERING! FOUNTAIN HOUSE! DIGITAL EQUIPMENT CORP. LTD.! BUTTS CENTRE! READ INC ENGLAND RCl 7QN! UNITED KINGDOM
(0734) 583555
ROGER P. WRIGHT! EARLEY! 16 RAGGLESWOOD CLOSE! READING BERKS. RG6 2LH! UNITED KINGDO~! READING 663178
B. NIBLETT/ DEPT. OF COMPUTER SCIENCE/ UNIVERSITY COLLEGE OF SWANSEA/ SWANSEA ENGLAND SA2 3pP/ UNITED KINGDOM
S. T. DEVEREUX! COMPUTER CENTRE! POLYTECHNIC OF THE SOUTH BANK / BOROUGH ROAD! SOUTHWARK! LONDON ENGLAND SEl OAA! UNITED KINGDOM! 01-928 8989 X2327
ATTN: DEPT. OF MATHEMATICS C!O D.W. BA! THE UNIVERSITY! SOUTHAMPTON ENGLAND S09 5NH! UNITED KINGDOM! 0703 559122 X700
D. W. BARRON! COMPUTER STUDIES GROUP! THE UNIVERSITY! SOUTHAMPTON ENGLAND S09 5NH! UNITED KINGDOM! 0703-559122 X700
J. GOODSON! DEPARTMENT OF MATHEMATICS! THE UNIVERSITY! SOUTHAMPTON ENGLAND S09 5NH! UNITED KINGDOM! 0703-559122 X2387
JUDY MULLINS! DEPARTMENT OF MATHEMATICS! THE UNIVERSITY OF SOUTHAMPTON! SOUTHAMPTON ENGLAND S09 5NH! UNITED KINGDOM! 0703559122 X2387
MIKE J. REES! DEPT. OF MATHS.! COMPUTER STUDIES GROUP! THE UNI VERSITY! SOUTHAMPTON ENGLAND S09 5NH! UNITED KINGDOM
MORLEY W. SAGE! COMPUTING SERVICE! UNIVERSITY OF SOUTHAMPTON! SOUTHAMPTON ENGLAND S09 5NH! UNITED KINGDOM! 0703-559122 X694
K. H. BENNETT! DEPT. OF COMPUTER SCIENCE! UNIV. OF KEELE! KEEL E STAFFORDSH ST5 5BG! UNITED KINGDOM! STOKE-ON-TRENT 621111 X410
DENIS LENIHAN! BATTERSEA LABORATORY! BRITISH STEEL CORPORATION / 140 BATTERSEA PARK ROAD! LONDON ENGLAND SWll! UNITED KINGDOM! 01-622-5511 X6
P W R CLARKE! CCD! NEW HUXLEY BLDG! IMPERIAL COLLEGE! 180 QUEENSGATE! LONDON ENCLAND SW7 2AZ! UNITED KINGDOM! 01-589-5111 X2758
R. A. FRANCIS! CCD HUXLEY BUILDING! IMPERIAL COLLEGE LONDON! LONDON ENGLAND sIn 2AZ! UNITED KINGDOM
JEFF KRAMER! DEPARTMENT OF COMPUTING AND CONTROL! HUXLEY BUILDING! IMPERIAL COLLEGE! 180 QUEENSGATE! LONDON ENGLAND SW7 2AZ! UNITED KINGDOM
01-589-5111 X2754
STUART JAMES MCRAE! DEPT OF COMPUTING & CONTROL! IMPERIAL COLLEGE! 180 QUEENSGATE! LONDON ENGLAND SW7 2AZ! UNITED KINGDOM! 01-589-5111 X2706
GREG PUGH! DEPARTMENT OF COMPUTING AND CONTROL! IMPERIAL COLLEGE! 180 QUEENSGATE! LONDON ENGLAND SW7 2AZ! UNITED KINGDOM! 01-589-5111 X2758

C/l

rn
--0

---i

rn
3:
o:l

rn
:;0

--0

:»
G>

rn

SW7
SW7
SW7
S10
TSI
TWll
TW20
WCIE

2AZ
2AZ
2AZ
2TN
3BA
OLW
OEX
7HX
WCl
WCl
WCIH DAM
WlA 4SE
W8 7AM
YOI 5DD
b30090
41000
bl 000
71000

UNITED KINGDOM
UNITED KINGDOM
UNITED KINGDOM
UNITED KINGDOM
UNITED KINGDOM
UNITED KINGDOM
UNITED KINGDOM
UNITED KINGDOM
UNITED KINGDOM
UNITED KINGDOM
UNITED KINGDOM
UNITED KINGDOM
UNITED KINGDOM
UNITED KINGDOM
USSR
YUGOSLAVIA
YUGOSLAVIA
YUGOSLAVIA

DAVID SLATER/ ceo/ IMPERIAL COLLEGE/ 180 QUEENSGATE/ LONDON ENGLAND SW7 2AZ/ UNITED KINGDOM
lAIN STINSON/ DEPT. OF COMPUTING & CONTROL/ IMPERIAL COLLEGE/ 180 QUEENSGATE/ LONDON ENGLAND SW7 2AZ/ UNITED KINGDOM/ 01-589-5111 X2700
DAVE THOMAS/ DEPT. OF COMPUTING & CONTROL/ IMPERIAL COLLEGE/ LONDON ENGLAND SW7 2AZ/ UNITED KINGDOM
CHRIS MARTIN/ COMPUTING SERVICES/ THE HICKS BUILDING/ UNIVERSITY OF SHEFFIELD/ SHEFFIELD ENGLAND S10 2TN/ UNITED KINGDOM/ (0742) 78555 X263
ATTN: THE LIBRARY/ TEESIDE POLYTECHNIC/ BOROUGH ROAD - MIDDLES BROUGH/ CLEVELAND ENGLAND TS1 3BA/ UNITED KINGDOM/ 0642-44176
1. GOODE/ NATIONAL PHYSICAL LABORATORY/ DNAC/ TEDDINGTON MIDDLESEX TWll OLW/ UNITED KINGDOM/ 01-977 3222
ROY EDWARDS/ DEPT. OF STAT. AND COMPo SCI./ HOLLOWAY COLLEGE/ EGHAM HILL/ EGHAM SURREY TW20 OEX/ UNITED KINGDOM/ EGHAM 4455
J. J. FLORENTIN/ DEPARTMENT OF COMPUTER SCIENCE/ BIRKBECK COLLEGE/ MALET STREET/ LONDON ENGLAND WCIE 7HX/ UNITED KINGDOM
CHRIS LAZOU/ COMPUTER CENTRE/ UNIVERSITY OF LONDON/ 20 GUILFORD STREET/ LONDON ENGLAND WCl/ UNITED KINGDOM/ 01-405-8400
SILVIA SUSSMAN/ COMPUTER CENTRE/ UNIVERSITY OF LONDON/ 20 GUILFORD ST./ LONDON ENGLAND WCl/ UNITED KINGDOM/ (01) 405 8400
ANTHONY B. WELLER/ COMPUTER CENTRE/ UNIVERSITY COLLEGE LONDON/ 19 GORDON STREET/ LONDON ENGLAND WC1H OAH/ UNITED KINGDOM
ATTN: LIBRARIAN/ PO BOX 4SE/ LOGICA LIMITED/ 64 NEWMAN STREET/ LONDON ENGLAND W1A 4SE/ UNITED KINGDOM/ (01) 580 8361
BRIAN MEEK/ COMPUTER UNIT/ QUEEN ELIZABETH COLLEGE/ CAMPDEN HILL ROAD/ LONDON ENGLAND W8 7AH/ UNITED KINGDOM/ 01-937 5411
D. G. BURNETT-HALL/ DEPARTMENT OF COMPUTER SCIENCE/ UNIVERSITY OF YORK/ HESLINGTON/ YORK ENGLAND Y01 5DD/ UNITED KINGDOM/ (0904) 59861
S. POKROVSKY/ COMPUTING CENTRE/ USSR ACADEMY OF SCIENCES/ NOVOSIBIRSK 630090/ USSR
STJEPAN JARNJAK/ 13 PROLET. BRIG. 247/ ZAGREB 41000/ YUGOSLAVIA/ (041) 513-822/767 (OFFICE)
ROBERT REINHARDT/ FABIANIJEVA 39/ LJUBLJANA 61 000/ YUGOSLAVIA
SUAD ALAGIC/ ELEKTROTEHNICKI FAKULTET/ SARAJEVO LUKAVICA 71000, YUGOSLAVIA

ATTENTION: NANCY BROOKS
S. KAMAL ABDALI
12181
ATTENTION: N. V. KOTESWARA RAO
PUAN SHARlFAH L. ABID
MALAYSIA
ATTENTION: PAUL C. SMITH
D. ABRAHAMSON
2 IRELAND
ATTENTION: REIDAR AUNAN
JOHN W. ADAMS
18015
ATTENTION: ROBERT E. NOVAK
J. MACK ADAMS
88003
ATTENTION:
ROY
MAXION-PROGRAMMING
ADVISOR
KENNETH LERDY ADAMS
47906
ATTENTION: RUTH DROZIN
A. M. ADDYMAN M13 9PL UNITED KINGDOM
ATTENTION: R. D. BERGERON
SUAD ALAGIC
71000 yUGOSLAVIA
ATTENTION: STEVE REISMAN
J. A. ALAN EN
2506 THE NETHERLANDS
ATTENTION: WILLIAM HUNTEMAN
JOHN J. ALLAN III
75275
ATTN: ACADEMIC SERVICES
DENNIS R. ALLISON
94025
ATTN: AIR FORCE WEAPONS LABORATORY
D. R. ALLUM LAI 4YB UNITED KINGDOM
ATTN: BIBLIOTEKET
JOHN ALSTRUP
55424
ATTN: BIBLIOTHEEK 05627
RICH ALTMAIER
94086
ATTN: BIBLIOTHEK
URS AMMANN CH-8092 SWITZERLAND
ATTN: BOEING COMPANY
DAVID B. ANDERSON
18015
ATTN: BOEKRANDEL VERWIJS EN STAM B.V.
GARY S. ANDERSON
98043
ATTN: B1700 PROTEUS PROJECT
JACK ANDERSON
55431
ATTN: CENTRAL LIBRARY
PETER ANDERSON
07102
ATTN: CENTRO DE CIENCIAS DE LA COMPUTACION
RICHARD V. ANDREE
73019
ATTN: CERN LIBRARY
DENNIS S. ANDREWS
94086
ATTN: CHIEF BRANCH OF DATA SYSTEM SERVICES
MAKOTO ARISAWA
400 JAPAN
ATTN:
COMPUTER
CENTER
USER SERVICES
KARL JOHAN ASTROM S-220 07 SWEDEN
ATTN: COMPUTER CENTRE
ATTENTION: ARMENELLA VINSON
87114
ATTN: COMPUTER CENTRE
ATTENTION: A.S. WILLIAMS
92626
ATTN: COMPUTER SCIENCE DEPARTMENT
ATTENTION: BLAIR BURNER
98124
ATTN: COMPUTER SCIENCE DEPT.
ATTENTION: B.S. MOSSAKOWSKI BN2 4GJ UNITED KINGDOM
ATTN: COMPUTER SCIENCE DEPT. A
ATTENTION: CHRIS BRYCE L85 4Kl CANADA
ATTN:
COMPUTER SCIENCE DEPT. B
ATTENTION: COLIN G. CAMPBELL
77001
ATTN: COMPUTER SCIENCES INSTITUTE
ATTENTION: DAN BURROWS
55812
ATTN: COMPUTER SERVICES - F01.3
ATTENTION: DAVID MADISON
35806
ATTN: COMPUTER UNIT
ATTENTION: DONALD LINDSAY K2E 6T7 CANADA
ATTN: COMPUTING CENTER
ATTENTION: EVAN L. SOLLEY
97210
ATTN: CONSULTING OFFICE
ATTENTION: E. N. VAN DEVENTER
0001 SOUTH AFRICA
ATTN: C.R.I.G.
ATTENTION: GARRY S. MEYER
11794
ATTN:
DATALOGISK INSTITUT
ATTENTION: GORDON R. SHERMAN
37916
ATTN:
DEPARTMENT
OF
INFORMATION
SCIENCE
ATTENTION: JAN LAUGESEN V. 3-357 DK-2500 DENMARK
ATTN: DEPT. OF COMPUTER SCIENCE
ATTENTION: JAN WITT
D-8000 GERMANY
ATTN: DEPT. OF MATHEMATICS C/O D.W. BARRON
ATTENTION: JERRY W. SEGERS
30332
ATTN: DIRECTOR
ATTENTION: JO AN HUESMAN
03060
ATTN: DIRECTOR
ATTENTION: MARTIN TOORI M3M 3B9 CANADA
ATTN: DOCUMENTS ROOM
ATTENTION: MAX SEVCIK CH-8035 SWITZERLAND
ATTN: DOCUMENTS ROOM LIBRARIAN
ATTENTION: MILES RICKARD
78767
ATTN: DOROTHY SMITH - REFERENCE
ISRAEL
ATTENTION: M. MALKOSH

ATTN: DSM
93105
ATTN: FRIEDA S. COHEN
500762 INDIA
ATTN: INSTITUT FUER INFORMATIK
55455
ATTN: INSTITUT FUR MED. DATENVERARBEITUNG
N-2007 NORWAY
ATTN:
INSTITUTE TNO FOR MATHEMATICS
55165
ATTN: INST. FUR ANGEWANDTE MATHEMATIK
89507
ATTN: J. F. MCINTYRE - LIBRARIAN
17837
ATTN: KAPPA ETA KAPPA
03824
ATTN: KARIN & MICHELE - PASCAL DISTRIBUTION
55455
ATTN: LAL CHAN DANI ENTERPRISES
97331
ATTN: LIBRARIAN
90007
ATTN: LIBRARIAN
87117
DK-2800 DENMARK
ATTN: LIBRARIAN
ATTN: LIBRARIAN
THE NETHERLANDS
D-6750 GERMANY
ATTN: LIBRARIAN
98124
ATTN: LIBRARY
2005 THE NETHERLANDS
ATTN: LIBRARY
84112
ATTN: LIBRARY
3001 AUSTRALIA
ATTN: LIBRARY
CHILE
ATTN: LIBRARY
CH-1211 SWITZERLAND
ATTN: LIBRARY / SERIALS
80225
ATTN: MATH LIBRARY
98105
ATTN: MATHEMATICS DEPARTMENT
3083 AUSTRALIA
ATTN: MOD COMP LIBRARY
4001 SOUTH AFRICA
ATTN: M. DOHERTY
59801
ATTN: M. WATKINS - TECHNICAL LIBRARIAN
55455
ATTN: PRODUCTION AUTOMATION PROJECT
93940
ATTN: PROGRAM LIBRARIAN
93940
ATTN: PROGRAM LIBRARY
92507
ATTN: PURCHASING. OFFICE
75080
ATTN: READING ROOM
CV4 7AL UNITED KINGDOM
ATTN: RECAU (B)
59715
ATTN: RECAU
61801
ATTN: RECEIVING CLERK
F-34000 FRANCE
ATTN: REFERENCE ROOM
DK-2200 DENMARK
ATTN: REFERENCE ROOM
NEW ZEALAND
ATTN: REGIONALES RECHENZENTRUM
38677
ATTN: RESEARCH PROGRAMMING ADVISOR
S09 5NH UNITED KINGDOM
ATTN: RZ - BIBLIOTHEK
32611
ATTN: SARA-LIBRARY
M5 4WT UNITED KINGDOM ATTN: SCHOOL OF INFORMATION SCIENCES
97403
ATTN: SCIENCE LIBRARY
46637
ATTN: SECRETARY
LIBRARIAN
78712
ATTN: SERIALS DEPT.

THE NETHERLANDS
53706
D-2000 GERMANY
D-8000 GERMANY
THE NETHERLANDS
D-7500 GERMANY
22903
55414
80302
90260
32611
W1A 4SE UNITED KINGDOM
3052 AUSTRALIA
OX11 OQX UNITED KINGDOM
2033 AUSTRALIA
80225
01754
T6G 2J8 CANADA
1005 THE NETHERLANDS
91109
94305
02115
19085
33309
M5S 1A7 CANADA
21031
14627
5001 AUSTRALIA
N6A 5B7 CANADA
2600 AUSTRALIA
02139
DK-8000 DENMARK
DK-8000 DENMARK
61820
K7L 3N6 CANADA
55455
D-8520 GERMANY
89154
CH-8092 SWITZERLAND
THE NETHERLANDS
2616 AUSTRALIA
BT9 5EQ UNITED KINGDOM
7001 AUSTRALIA
52242

ATTN: SERIALS DEPT.
ATTN: SERIALS LIBRARY
ATTN: SOFTWARE/HARDWARE GROUP
ATTN: SSRFC LIBRARY
ATTN: THE DOCUMENTATION OFFICER
ATTN: THE LIBRARIAN
ATTN: THE LIBRARIAN
ATTN: THE LIBRARIAN
ATTN: THE LIBRARY
ATTN: THE LIBRARY
ATTN: UCC LIBRARIAN
ATTN: USER SERVICES GROUP
ATTN: USER SERVICES LIBRARIAN
J. W. ATWOOD
DAVID AULT
MARGERY AUSTIN
GENE AUTREY-HUNLEY
DELE AYENI
DANG VAN BA
GARY BABCOCK
CHARLES BACON
J. R. BAICHTAL
DWIGHT BAKER
FRED P. BAKER
SAMUEL T. BAKER
T. P. BAKER
S. BALASUBRAMANIAN
LYNNE J. BALDWIN
A. BALFOUR
EDWARD E. BALKOVICH
MICHAEL S. BALL
FRED E. BALLARD
HAURICE BALLEW
RICHARD BALOCCA
DADO BANATAO
CHARLES J. BANGERT
JOHN BANNING
WILLIAM BARABASH
JOHN R. BARR
D. W. BARRON
ANN V. BARROW
STEVEN BARRYTE
NEIL J. BARTA
JEFFREY BARTH
BRIT J. BARTTER
ROGER R. BATE
DAVID BATES
RODNEY M. BATES
HENRY R. BAUER III
JOHN C. BEATTY
o. BEAUFAYS
E. R. BEAUREGARD
MICHAEL A. BEAVER
MARK BECKER
BERNHARD H. BEITINGER
ABDUL RASAQ BELLO
STEVEN M. BELLOVIN
DAVID A. BENNETT
K. H. BENNETT
LENNERT BENSRYD
LOUIS A. BENTON
HERMAN BERG
PHILIP N. BERGSTRESSER
THOMAS BERNER
BOB E. BERRY
SCOTT BERTILSON

70504
2308 AUSTRALIA
DK-2100 DENMARK
55455
UNITED KINGDOM
LA1 4YX UNITED KINGDOM
2601 AUSTRALIA
M60 1QD UNITED KINGDOM
ISRAEL
TS 1 3BA UN ITED KINGDOM
52242
80523
88003
H3G 1M8 CANADA
22090
20037
94025
N2L 3B8 CANADA
CH-1207 SWITZERLAND
93555
20854
94040
01752
61820
37130
32304
n001

68101
EH1 2HW
06268
92152
60201
79409
61801
95121
66045
94305
11794
90503
S09 5NH
LAl 4YX
90048
48106
94720
60202
75023
CH-1200
67220
82071
94550

UNITED KINGDOM

UNITED KINGDOM
UNITED KINGDOM

SWITZERLAND

BELGIUM
02809
53115
06432
D-8012
55408
27514
13440
ST5 5BG
S-220 07
92121
53703
35758
D-2000
LA1 4YX
55455

GERMANY

UNITED KINGDOM
SWEDEN

GERMANY
UNITED KINGDOM

RANDY BEST
76114
JAMES L. BEUG
93407
JEAN BEZIVIN F-35031 FRANCE
ALBRECHT BIEDL
D-1000 GERMANY
MARK BILODEAU
55401
HERBERT F. BISCHELTSRIEDER
D-80 12 GERMANY
C. M. BISHOP
NEW ZEALAND
THOMAS P. BISHOP
14853
KAY BITTERLING
D-1000 GERMANY
GUS BJORKLUND
22091
G. RICHARD BLADEN DK-2650 DENMARK
WILLIAM BLAMPIED S7K 3P7 CANADA
ALAN BLANN IN BS9 4PL UNITED KINGDOM
BRADFORD E. BLASING
55455
1. N. BLAVINS
5006 AUSTRALIA
ROLAND F. BLOMER
D-8000 GERMANY
P. VAN EMDE BOAS
THE NETHERLANDS
KEITH BOLSON
55423
RAFAEL M. BONET
12 SPAIN
JOEL BONEY
78723
55454
TIM BONHAM
89509
WILLIAM R. BONHAM
ERWIN BOOK
90066
GARY J. BOOS
58501
KEN BORGENDALE
55455
ARNE BORTEMARK S-581 83 SWEDEN
53201
JAMES S. BOTIC
JEAN-PIERRE·BOUCHEZ 2231 XE THE NETHERLANDS
RAYMAOND BOUTE
B-2000 BELGIUM
92093
KEN BOWLES
CHRIS BOYLAN
55068
93'940
GORDON BRADLEY
DAVID E. BREEDING
75229
STEPHEN L. BREIBART
UNITED KINGDOM
RONALD F. BRENDER
01754
BILL BRENNAN
19401
N. D. BREWER
2076 THE NETHERLANDS
FRANK BREWSTER
22304
C. E. BRIDGE
19898
ROBERT L. BRIECHLE
44325
C. BRON
THE NETHERLANDS
ALBERT S. BROWN
01754
ARTHUR A. BROWN
20037
WARREN R. BROWN
02038
BOB BRUCE
33307
BERND BRUGGE
D-2000 GERMANY
ALF M. BRUNSTROM S-751 21 SWEDEN
GERALD BRYAN
917ll
DAVID M. BULMAN
92103
WILHELM BURGER
78712
MIKE BURGHER
503ll
JOHN W. BURNETT
95051
D. G. BURNETT-HALL Y01 5DD UNITED KINGDOM
HOWARD BUSSEY JR.
80302
BILL BUZBEE
87545
ADRIAN BYRAM
94087
EDWIN J. CALKA
21204
J. A. CAMPBELL
2308 AUSTRALIA
DAVID F. CANTLEY
97331
PETER G. CAPEK
10598
KEVIN W. CARLSON
53705
ROY CARLSON
970n
DAVID E. CARLTON
60625
A. G. CARRICK
95014
GARY CARTER
89507
JOHN CASEY
02115

BILLY R. CASON
CHARLES A. CASTELLOW
JEAN CASTONGUAY
D. A. CAUGHFIELD
GARY CEDERQUIST
GERALD N. CEDERQUIST
F. CELLINI
MIKE CHALENBURG
NEAL H. CHAMPION
GABRIEL CHANG
BILL CHESWICK
COLE A. CHEVALIER
PATRICK CHEVAUX
VERNON CHI
YOUNG J. CHOI
FAY CHONG
LARS CHRISTENSEN
LUTZ CHRISTOPH
PAUL CHRISTOPHERSON
GERALD W. CICHANOWSKI
RICHARD J. CICHELLI
ROBERT G. CLARK
JENNIFER CLARKE
P W R CLARKE
GEOFFREY A. CLEAVE
DAVID G. CLEMANS
KURT COCKRUM
WILLIAM L. CO HAGAN
GEORGE COHN III
JOE CO INTMENT
PETER COLBY
D. B. COLDRICK
DEREK COLEMAN
TERRENCE M. COLLIGAN
JOHN E. COLLINS
RIC COLLINS
DOUGLAS COMER
MICHAEL N. CONDICT
JAMES B. CONKLIN JR.
APRIL MILLER CONVERSE
RICHARD CONWAY
DEXTER COOK
CHRISTOPHER S COOPER
WILLIAM L. COOPER
C. J. COPELAND
F. J. CORBAro
RICHARD CORE
B. J. CORNELIUS
MIKE W. CORNELIUS
C R CORNER.
JOHN DENNIS COUCH
FREDERICK C. COWAN
LARRY CRANE
JOHN EARL CRIDER
LINDA E. CROLEY
WILLIAM E. CROSBY
DONALD B. CROUCH
ZAY CURTIS
BJARNE DACKER
LUIS M.M. DAMAS
DENNIS DANCE
RONALD L DANIELSON
JAMES DARLING
GENE A. DAVENPORT
ANN D. DAVIES
R. JAMES DAWE

98004
98in
G1W 2P3
79601
75275
30092
N6A 5B7
72143
86301
02139
18938
92704
CH-1211
97403
5001
95014
DK-2880
D-1000
55343
55987
18103

-0

CANADA

J>
(/)

n
J>

CANADA

r
z
rn
~
(/)

SWITZERLAND

'1:1:
<.D

AUSTRALIA
f

en

rn
I.N
I.N

BRUCE DAWSON
FRANKLIN B. DE GRAAF
JOHN DE ROSA JR.
HAROLD DE VORE
D. D. DE VRIES
W. DE VRIES
JOHN R. DEALY
RANCE J. DELONG
DAVID DEMOREST
E. DENERT
DOROTHY E. DENNING
TIMOTHY DENNIS
G. D. DERHAK
PIERRE DESJARDINS
S. T. DEVEREUX
BOB DICKERSON
KENNETH A. DICKEY
JOHN DICKINSON
LLOYD DICKMAN
KLAUS R. DITTRICH
E. H. DOBELL
JOHN G. DOBNICK
RANDY DODGE
ROBERT ALAN DOLAN
DAN DORROUGH
JOHN DOW
KEVIN R. DRISCOLL
JEFFREY J. DRUMMOND
ROGER A. DUE
STEPHEN A. DUM
DONNA K. DUNAWAY
FRANK DUNN
RON DYKSTRA
DOUG DYMENT
T. A. D'AURIA
R. STERLING EANES
WILLIAM J. EARL
JOHN EARLS
CHRIS EASTLUND
JEFF EASTMAN
JOHN T. EASTON
NORBERT EBEL
GLENN T. EDENS
HANK EDWARDS
ROY EDWARDS
FRED EILENSTEIN
JOHN D. EISENBERG
HOWARD EISENSTEIN
T. W. EKBERG
LARS EKMAN
JIM ELAM
DAVE R. ELAND
DENNIS R•. ELLIS
HORACE ENEA
G. ENGELIEN
DAVE ENGLANDER
PHILLIP H. ENSLOW JR.
P. J. ERARD
DENNIS ERNST
E. W. ERRICKSON
HOWARD D. ESKIN
JOHN B. EULENBERG
BLAND EWING
R. NEIL FAIMAN JR.
DENNIS FAIRCLOUGH
JAMES N. FARMER

40208
K2K 1K2 CANADA
01609
55337
THE NETHERLANDS
THE NETHERLANDS
90278
18018
98124
D-8000 GERMANY
47907
06035
R3T 2N2 CANADA
H3C 3J7 CANADA
SE1 OAA UNITED KINGDOM
AL10 9AB UNITED KINGDOM
95521
83843
01776
D-7500 GERMANY
2007 AUSTRALIA
53219
A1C 5S 7 CANADA
93109
47906
15261
55414
55455
02111
97005
75222
75081
55455
V7W 2J6 CANADA
10027
02154
92715
75240
55401
80537
55455
CH-2000 SWITZERLAND
94086
01701
TW20 OEX UNITED KINGDOM
02172
19711
29206
75234
DK-1601 DENMARK
94111
74171
80303
94022
D-5300 GERMANY
18015
30332
CH-8027 SWITZERLAND
94086
85061
10025
48824
94720
48228
84601
30332

JACQUES FARRE F-75230 FRANCE
JOSEPH H. FASEL III
47907
JEAN-PIERRE FAUCHE F-38040 FRANCE
LUCIEN FEIEREISEN
D-7500 GERMANY
EDWARD E FERGUSON
76201
LINWOOD FERGUSON
22901
JEANNE FERRANTE
02139
JOSE OSVALDO FERRARI
13100 BRAZIL
LINCOLN FETCHER
55455
CHARLES J •. FETE
92704
SUSAN FEUERMAN
93940
N. J. FIDDlAN
UNITED KINGDOM
ROGERIO BUHNIER FILHO
13100 BRAZIL
BILL FINDLAY G12 8QQ UNIIED KINGDOM
CHARLES N. FISCHER
53706
GLENN FISHBINE
55101
A. J. FISHER HR1 1TY UN IIED KINGDOM
WILLIAM E. FISHER
90501
TED FISHMAN
75222
DAVID p. FITZGERALD
91740
KEVIN FJELSTED
55455
HANS FLACK S-751 21 SWEDEN
J. J. FLORENTIN WClE 7HX UNITED KINGDOM
RUDY L•. FOLDEN
92714
JIM FONTANA
92704
CHARLES H. FORSYTH N2J 4T2 CANADA
MARY DEE FOSBERG
73034
LLOYD D. FOSDICK
80309
ARTHUR FOSTER LA1 4YX UNITED KINGDOM
92663
L. M. FOSTER
W. BRUCE FOULKES R3T 2N2 CANADA
ED FOURT
94720
PALTONIO DAUN FRAGA
13100 BRAZIL
DENNIS J. FRAILEY
75222
ROBERT A. FRALEY V6T 1W5 CANADA
20006
MIKE FRAME
REX FRANClOTTl
11530
SW7
2AZ UNITED KINGDOM
R. A. FRANCIS
K. FRANKOWSKI
55455
KURT FREDRIKSSON S-431 39 SWEDEN
TED L. FREEMAN
20705
DANA A. FREIBURGER
93407
G. FRIEDER
14226
EDWARD R. FRIEDMAN
10012
FRANK L. FRIEDMAN
19122
GERHARD FRIESLAND
D-2000 GERMANY
SERGE FROMENT H1Z 3P 1 CANADA
JOHN FUNG
55414
WAYNE FUNG V6X 2Z9 CANADA
DAN FYLSTRA
02134
MICHEL GALINIER F-31077 FRANCE
94304
SAM GEBALA
EDWARD F. GEHRINGER
47907
W. mRVEN GENTLEMAN N2L 3G1 CANADA
32806
J. D. GEORGE
A. J. GERBER
2006 AUSTRALIA
PAUL S. GERKEN
94611
13201
J. DANIEL GERSTEN
22901
ROBERT A. GIBSON
92807
DAVID W. GIEDT
01754
N. AMOS GILEADI
54302
ED GLASER
30332
JOHN J. GODA JR.
84601
PAUL GODFREY
ANTHONY LESLIE COLBORN GU16 5HJ UNITED KINGDOM
98195
HELLMUT GOL@

G. H. GOLDEN JR.
14063
DAVID A. GOMBERG
20016
GEORGE GONZALEZ
55108
I. GOODE TW11 OLW UNITED KINGDOM
RALPH S. GOODELL
01451
JOHN B. GOODENOUGH
02154
J. GOODSON S09 5NH UNITED KINGDOM
GERRARD GOOS
D-7500 GERMANY
D. GOSMAN
THE NETHERLANDS
JOHN S. GOURLAY
48105
SARA K. °GRAFFUNDER
55455
DENNIS GRAHAM
94086
JEFFREY W. GRAHAM
35223
SUSAN L. GRAHAM
94720
WILLIAM Q. GRAHAM
19711
M. J. GRALIA
20810
JOHN M. GRAM
92717
DAVID N. GRAY
78769
KRISTINA GREACEN
55455
MARK GREEN LEN 3W3 CANADA
MIKE GREEN
78284
TOM GREER
91775
R. GREINER
95014
WILEY GREINER
90278
DAVID J. GRIFFITHS
02881
DONALD E. GRIMES
95014
R. L. GRIMSDALE BN 1 9QT UN ITED KINGDOM
MARTIN L GRISS
84112
DALE H. GRIT
80523
PETER GROGONO H4V 2H3 CANADA
WILLIAM GROSKY
48202
JONATHON R. GROSS
55435
STEVE GROSS
10024
LARRY GROVER
56301
GEORGE GRUNWALD
47306
ROGER GULBRANSON
61801
S. L. GULDEN
18015
HILMAR GUTFELDT CH-3000 SWITZERLAND
PETER GUTTERMAN
20433
DAVE HABERMAN
75081
THOMAS HABEHNOLL
D-1000 GERMANY
MICHAEL HAGERTY
02174
JACQUES HAGUEL J 1K 2R1 CANADA
HARRY P. HAIDUK
79015
B. HALE MK40 2PN UNITED KINGDOM
THOMAS HALLDORSON
18353
JOEL M. HALPERN
55455
RONALD .1:. HAM
01754
DAVID E. HAMILTON
23666
DAN C.C. HAMM KI12 5NF UNITED KINGDOM
TERRY HAMM
97077
U. HAMMELEFF DK-8000 DENMARK
DON HAMNES
55409
WOLFGANG HAMPE
D-1000 GERMANY
MICHAEL Z. HANANI
ISRAEL
C. C. HANDLEY
4000 SOUTH AFRICA
SCOTT D. HANKIN
01720
KAY A. HANSBORO UGH
87544
GILBERT J. HANSEN
75075
KELD HELBIG HANSEN DK-2800 DENMARK
RANDALL W. HANSEN
55440
BRIAN HANSON
55455
JON HANSON
55440
SAM HARBAUGH
32901
20234
T. H<\RD.J
EDWARD ». HARRIS
53}05

-0

:J>

en
(""")

:J>

r-

=
rn
::e::
en
:;to
<.D

!CO

:;to
I-'
0

en
rn
-0

-I

rn
:::s:
t::C

rn
;0

I-'
<.D

'.J
'.J

-0

»

'"

rn

Vol

.J::-

KAY HARRISON
STEPHEN J. HARTLEY
ROBERT L. HARTMAN
AL HARTMANN
J. P. HARVELL
DON HARVEY
ISAMU HASEGAWA
KEITH HAUER-LOWE
KEVIN HAUSMANN
DAVID HAWK
GEORGE E. HAYNAM
JOHN HEATH
JAMES W. HEBERT
PAUL HECKEL
H. G. HEDGES
CHARLES HEDRICK
J. B. HEIDEBRECHT
S. T. HEIDELBERG
DENNIS HEIMBIGNER
JUHA HEINANEN
T. S. HEINES
DAVID HELFINSTINE
PAUL S. HELLER
CARL HELMERS
PAUL HELVIG
RICHARD HENDRICKSON
STEN HENRIKS SON
CARL HENRY
WILLIAM HENRY
MARK HERSEY
CHARLES L. HETHCOAT III
GEORGE C. HETRICK
BRYAN L. HIGGINS
STANLEY B. HIGGINS
JIM HIGHTOWER
TERUO HIKITA
DAVID HILL
TIM HILL
SAM HILLS
W. A. HINTON
ED HlRAHARA
HATTIA HMELJAK
THEA D. HODGE
TIMOTHY W. HOEL
MARILYN HOFFMAN
H. -J. HOFFMANN
TIMOTHY J. HOFFMANN
DAVID W. HOGAN
WILLIAM C. HOPKINS
GREGORY L. HOPWOOD
FRANK H. HORN
TOM HORSLEY
FRED A. HOSCH
DAVID A. HOUGH
ROSEMARY HOWBRIGG
RALPH HOWENSTINE
RICHARD HOYME
PEl HSIA
PETER YAN-TEK HSU
RICHARD HUBER
JON F. HUERAS
JACK HUGHES
ALFRED J. HULBERT
GEOFFREY HUNTER
PAUL K. HUNTWORK
EDWARD W. HURLEY

N2L 3G 1 CANADA
22901
92701
95051
75081
97077
E14 UNITED KINGDOM
55417
55113
19711
32901
04103
01907
94305
48824
08903
90278
94550
90278
SF-33101 FINLAND
44115
55303
08540
03458
56301
55420
S-223 62 SWEDEN
55057
10003
48823
77027
02167
94621
37232
90274
113 JAPAN
95819
22901
70125
53211
92653
1-34100 ITALY
55455
55057
18018
D-6100 GERMANY
55455
78751
19174
92713
53706
95376
70122
23602
06413
73070
55427
35807
55455
77843
92717
K7L 3N6 CANADA
87115
M3J lP3 CANADA
5511

en
n

,

):>

:z

rn
~

en
'It:
<.D
I?O

'It:

......
0

SHMUEL PELEG
M. A. PELL
HAL PERKINS
WALT PERKO
DAVID PERLMAN
RUSS PETERSON
SUE PETERSON
W. W. PETERSON
TRUMAN C. PEWITT
CHARLES PFLEEGER
BOB PHILLIPS
CHRIS K. PHILLIPS
ATE PHUNG
PAUL PICKELMANN
DOUG PIHL
ALAIN PIROTTE
TOM PITTMAN
STEPHEN A. PITTS
P. J. PLAUGER
S. POKROVSKY
KEN POLAKOWSKI
RUDOLPH C. POLENZ
BARY W. POLLACK
J. E. POLLACK
GEORGE POONEN
L. C. PORTIL
J. L. POSDAMER
LEE POTTS
FRED W. POWELL
KARL PRAGERSTORFER
TERRENCE PRATT
WERNER F. PRAUTSCH
C. B. A. PRICE
RON PRICE
WILLIAM C. PRICE
MICHAEL PRIETULA
DAVID KARL PROBST
STEPHEN G. S. PROUT
MARLIN PROWELL
ANDREW S. PUCHRIK
ERIC PUGH
GREG PUGH
BRUCE A. PUMPLIN
HOWARD D. PYRON
DOUGLAS H. QUEBBEMAN
IRVING N. RABINOWITZ
WILLIAM F. RAGSDALE
THOMAS RAMSBERGER
V. LALITA RAO
CHARLES RAPIN
WAYNE RASBAND
PETER RAUSCHMAYER
BRUCE K. RAY
JERRY L. RAY
JEFFERY M. RAZAFSKY
ALAN REED
MIKE J. REES
ROY F. REEVES
L. EDWARD REICH
C. EDWARD REID
PHYLLIS A. REILLY
J. REINFELDS
ROBERT REINHARDT
WERNER REMMELE
JOHN REYNOLDS
JOHN D. REYNOLDS

20742
M13 9PL
14853
55414
55455
55112
55113
96822
60439
37916
97212
94903
D-5100
48109
55440
B-1170
95153
73110
10036
630090
07828
54701
V6T 1W5
94566
02168
N9B 3P4
13210
63188
24401
A-4060
22901
D-1000
HP2 5HG
07724
97068
55455
H3G 1M8

UNITED KINGDOM

GERMANY
BELGIUM

USSR
CANADA
CANADA

AUSTRIA
GERMANY
UNITED KINGDOM

CANADA
THE NETHERLANDS
98225
47130
90024
SW7 2AZ UNITED KINGDOM
54701
65401
47150
ISRAEL
94545
18015
18015
CH-1007 SWITZERLAND
20014
D-8000 GERMANY
80307
68022
64108
B15 2TT UNITED KINGDOM
S09 5NH UN ITED KINGDOM
43220
22201
32303
90746
2500 AUSTRALIA
61 000 YUGOSLAVIA
D-8000 GERMANY
N8 UNITED KINGDOM
35801

DAN C. RICHARD
PETER RICHARDSON
GEORGE H. RICHMOND
CLAES RICKEBY
PETER A. RIGSBEE
JENS PETER RINGGAARD
MARK RIORDAN
KEN RITCHIE
TERRY RITTER
CLARK M. ROBERTS
JOE C. ROBERTS
MARK L. ROBERTS
KEN ROBINSON
N ROBINSON
J. S. ROHL
S. ROHLFS
THOMAS A. ROLANDER
STAFFEN ROMBERGER
MICHAEL ROONEY
CARL S. ROSENBERG
RAYNER K. ROSICH
BERNIE ROSMAN
R. WALDO ROTH
E. L. ROWE
H. J. ROWE
LAWRENCE A. ROWE
DAVID ROWLAND
DON H. ROWLAND
BRIAN G. ROWSWELL
HERBERT RUBENSTEIN
NANCY RUIZ
C. A. RUSBRIDGE
MARK RUSTAD
JOHN L. RUTIS
FRANK RYBICKI
KARL H. RYDEN
DAVID J. RYPKA
JONATHAN SACHS
MORLEY W. SAGE
TOSHIAKI SAISHO
HIKMET SARA
ANTTI SALAV.A
A. H. J. SALE
TIMOTHY J SALO
CHESTER J. SALWACH
A. E. SALWIN
D. SANDEE
TOM SANDERSON
HELMUT SANDMAYR
HORST SANTO
DAVID SARANEN
LYNN SAUNDERS
AARON SAWYER
BOB SCARLETT
ANTHONY J. SCHAEFFER
HELMUT SCHAUER
JERRY SCHIEFFER
ROSS D. SCHMIDT
G. MICHAEL SCHNEIDER
SERGIO DE MELLO SCHNEIDER
ERIC SCHNELLMAN
P. SCHNUPP
MARK A. SCHROEDER
DEAN SCHULZ
ROLF SCHUMACHER
CARL \1. SCHWARCZ

07724
3052
80309
S-161 54
20375
OK-2730
48824
68005
78753
91016
75042
90274
2033
HA6 3DZ
6009
D-8000
95008
S-100 44
02154
94035
80302
01701
46989
19301
LEI 7RH
94720
97229
87109
2006
80401
87115
5000
55112
97123
19122
90024
43210
60604
S09 5NH
143
LA1 4YX
SF-00330
7001
55455
18960
20810

AUSTRALIA
SWEDEN
DENMARK

AUSTRALIA
UNITED KINGDOM
AUSTRALIA
GERMANY
SWEDEN

UNITED KINGDOM

AUSTRALIA
AUSTRALIA

UNITED KINGDOM
JAPAN
UNITED KINGDOM
FINLAND
AUSTRALIA

THE NETHERLANDS
87002
CH-9470
D-5205
55792
97077
02035
55455
47401
A-1040
75229
55343
55455
13560
98117
D-8000
75214
95051
D-1000
OnSL

SWITZERLAND
GERMANY

AUSTRIA

BRAZIL
GERMANY
GERMANY

19898
STEPHEN C. SCHWARM
90230
ARTHUR I. SCHWARZ
33314
FRED L. SCOTT
19085
THOMAS SCOTT
BARRY SEARLE KIA ON8 CANADA
DAVID SEGAL
10003
06901
MARK SEIDEN
D-7500 GERMANY
MANFRED SEIFERT
90024
BRUCE SEILER
78712
WAYNE SEIPEL
GUISEPPE SELVE 1-40122 ITALY
68588
SHARAD C. SETH
MICHAEL SETTLE
76011
32901
GEORGE A. SEYFERT
02173
G. M. SHANNON
84112
ED SHARP
94022
DAVID ELLIOT SHAW
94025
JEFFRY G. SHAW
20014
JOHN M. SHAW
WILLIAM F. SHAW
01754
55413
BELLE SHENOY
10012
DAVID SHIELDS
39210
ROBERT A. SHIVE JR.
87801
KIM L. SHIVELEY
20742
BEN SHNEIDERMAN
22311
ARNOLD SHORE
06320
JAMES P. SHORES
75240
GERALD A. SHOULTS
55440
BILL SIMMONS
91101
E. E. SIMMONS
06488
CHARLES E. SIMON
92634
SEYMOUR SINGER
48823
THOMAS W. SKELTON
sw7
2AZ UNITED KINGDOM
DAVID SLATER
J. B. SLATER NW3 7ST UNITED KINGDOM
THE NETHERLANDS
P. A. SLATS
LEO J. SLECHTA
55165
BARRY SMITH
97221
BROOKS DAVID SMITH
53211
lAIN SMITH RG1 7QN UNITED KINGDOM
JOYCE A. SMITH
20742
LAURA SNYDER
47401
ROBERT J. SNYDER
46202
JOHN S. SOBOLEWSKI
98195
THOMAS C. SOCOLOFSKY
48823
MARY LOU SOFFA
15260
N. SOLNTSEFF L8S 4K1 CANADA
DAVrp SOLOMONT
02155
MARCO SOMMANI 1-56100 ITALY
MANFRED SOMMER D-8000 GERMANY
NORMAN E. SONDAK
01609
ROLF SONNTAG
D-3000 GERMANY
BRUCE M. SORLIE
55406
STEPHEN SOULE T2N 1N4 CANADA
JOHN H. SPANTON
95133
TERRY L. SPEAK
80309
RICHARD SPELLERBERG
55440
MARTHA L. SPENCE
01741
DAVID SPENCER BH22 8HL UNITED KINGDOM
HENRY SPENCER M5W INS CANADA
RICHARD D. SPILLANE
07470
D. H. SPRINGER
95131
TOM SPURRIER
32901
JOHN P. STALLINGS
95014
JOHN STANLEY
55404
L. S. C. STATEMA
THE NETHERLANDS

90007
JORGEN STAUNSTRUP
97077
ROD STEEL
01852
EDWARD STEEN
49401
GORDON A. STEGINK
47401
HAL STEIN
29208
GERALD STEINBACK
60201
ALBERT STEINER
55416
WARREN STENBERG
VIC STENNING GU16 5HJ UNITED KINGDOM
76019
PHILIP STEPHENSON
55422
CALVIN STEVENS
85726
W. RICHARD STEVENS
lAIN STINSON SW7 2AZ UNITED KINGDOM
NIG
2Wl CANADA
ANNE STOCCO
70504
A. I. STOCKS
55440
JERRY STODDARD
55455
JOHN P. STRAIT
50011
GEORGE O. STRAWN
02139
JOHN N. STRAYHORN
78721
EDWARD P. STRITTER
55424
ROBERT A. STRYK
V8P
5J2 CANADA
GORDON STUART
6005 AUSTRALIA
PETER R. SUMNER
MARKKU SUNI SF-20500 FINLAND
14609
EDWARD W. SUOR
WCl UNITED KINGDOM
SILVIA SUSSMAN
LARS SVENSSON S-281 00 SWEDEN
94596
RALPH W. SWEARINGEN
THE NETHERLANDS
S. D. SWIERSTRA
A-I040 AUSTRIA
ADA SZER
ISRAEL
MENACHEM SZUS
PREBEN TAASTI DK-9000 DENMARK
20052
RICHARD TABOR
182 JAPAN
MASATO TAKEICHI
18104
RAMON TAN
THE NETHERLANDS
ANDREW S. TANENBAUM
01701
DAVID TARABAR
H. TAYLOR KIN 6N5 CANADA
75275
JANET TAYLOR
98055
RICHARD N. TAYLOR
94550
WILLIAM P. TAYLOR
90403
MICHAEL TEENER
DOUG TEEPLE V6X 2Z9 CANADA
48106
PAUL R. TEETOR
64108
ROBERT TEISBERG
94088
T. D. TELFORD
R. D. TENNENT K7L 3N6 CANADA
13676
TED TENNY
DANIEL THALMANN CH-1200 SWITZERLAND
01451
R. L. THAYER
DIDIER THIBAULT F-75005 FRANCE
DAVE THOMAS SW7 2AZ UNITED KINGDOM
39762
GAY THOMAS
20052
RAYMOND E. THOMAS
20012
RICK THOMAS
55425
RON THOMAS
LARS-ERIK THORELLI S-100 44 SWEDEN
52101
EDWARD O. THORLAND
40506
LAVINE THRAILKILL
S-341
00 SWEDEN
BENGT THYLEN
DHl
3LE UNITED KINGDOM
H. F. TIBBALS
55441
MIKE TILLER
HERVE TLREFORD CH-1211 SWITZERLAND
ALAIN TISSERANT F-54042 FRANCE
18017
STEPHEN TITCOMB
2232 AUSTRALIA
JEFFREY TOBIAS

NOBUKI TOKURA
500 JAPAN
HOWARD E. TOMPKINS
15701
SEVED TORSTENDAHL S-145 72 SWEDEN
ALFRED I. TOWELL
47401
STEVEN N. TRAPP
55421
MARTIN VERGES TRIAS
14 SPAIN
EDWIN TSE H9R IGl CANADA
CASEY TUBBS
32901
JOHN TUCKER
79601
W. TYLER
95060
ASHOK N. ULLAL
D-7408 GERMANY
BRIAN W. UNGER T2N IN4 CANADA
55455
JOHN URBANSKI
55440
TOM URSIN
INDULIS VALTERS
55406
J. J. VAN AMSTEL
THE NETHERLANDS
THE NETHERLANDS
G. E. VAN BEINUM
94041
WARREN VAN CAMP
ANDRIES VAN DAM
02912
THE NETHERLANDS
R. P. VAN DE RIET
THE NETHERLANDS
TOM VAN DER HOEVEN
THE NETHERLANDS
P. J. VAN DER HOFF
45036
PATRICIA VAN DERZEE
THE NETHERLANDS
H. VAN LOON
23508
FRANCES L. VAN SCOY
9321
T. J. VAN WEERT
THE NETHERLANDS
13100 BRAZIL
FERNANDO ANTONIO VANINI
M. W. VANNIER
40506
WILLIAM J. VASILIOU JR.
03824
JEAN VAUCHER H3C 3J7 CANADA
55113
ROBERT D. VAVRA
JAMES A. VELLENGA
55440
B. VENKATESAN T2N IN4 CANADA
P. VERBAETEN
B-3030 BELGIUM
JIM VERNON
55440
STANLEY C. VESTAL
55413
STEPHEN J VNUK
18651
EllTI WADA
113 JAPAN
KENNETH R. WAD LAND
01420
55455
KAREN WAGGONEK
THOMAS \,Al~NEK
lJ-I000 GERMANY
s. P. J. WAGSTAFF LAl 4YX UNITED KINGDOM
85731
JOHN E. WAdL
11740
M. WAITE
80309
WILLIAM M. WAITE
A. R. M. WAJIH PE17 3QB UNITED KINGDOM
70504
TERRY M. WALKER
BOB WALSH
87106
LARRY WALSH
95050
PATRICK WARD H3C 3J7 CANADA
80215
DAVID M. WARNER
SCDTT K. I,ARREN
77098
55455
WARREN J. WARWICK
MASARU WATANABE
222 JAPAN
22152
MARK S. WATERBURY
80302
JOE WATKINS
DAVID WATT G12 8QQ UN ITED KINGDOM
55104
GEOFF WATTLES
80303
VINCENT B. WAYLAND
JOHN A. WEAVER
18018
ANDERS WEBER DK-2300 DENMARK
D-8000 GERMANY
HELLMUT WEBER
NEIL W. WEBRE
93401
WALLY WEDEL
78712
WALTER WEHINGER
D-7000 GERMANY
REINHOLD WEICKER
D-8551 GERMANY

14850
KEVIN WEILER
ISRAEL
RUTH WEINBERG
79409
LEONARD H. WEINER
55113
STEVEN W. WEINGART
D-6300 GERMANY
DIETER WEISS
78721
DONALD G. WEISS
ANTHONY B. WELLER WCIH OAH UNITED KINGDOM
02138
ROBERT E. WELLS
JIM WELSH BT7 INN UNITED KINGDOM
89154
JOHN WERTH
30332
JOHN P. WEST
RICHARD WEST H9R IGl CANADA
60532
TERRY E. WEYMOUTH
22209
WILLIAM A. WHITAKER
GRAHAM J. WHITE M20 9QL UNITED KINGDOM
BN3
lRA UNITED KINGDOM
B. WILLIAML
95051
E. HAROLD WILLIAMS
12308
GEORGE H. WILLIAMS
59717
JAMES C. WILLIAMS
14850
JOHN H. WILLIAMS
75081
KENNETH L. WILLIAMS
6140 SOUTH AFRICA
M. H. WILLIAMS
NI0 UNITED KINGDOM
W. H. L. WILLIAMS
N6A
5B7 CANADA
S. WILLIAMSON
94086
ARTHUR C. WILLIS
SAM WILMOTT KIS 5G3 CANADA
02154
ROY A. WILSKER
73034
ARDOTH H. WILSON
DENIS M. WILSON AB9 2UB UNITED KINGDOM
13032
J. WILSON
94088
GARY W. WINIGER
48130
GREGORY J. WINTERHALTER
NIELS WINTHER DK-2650 DENMARK
D-6750 GERMANY
HANS-WILM WIPPERMANN
NIKLAUS WIRTH CH-8092 SWITZERLAND
47401
DAVID S. WISE
13210
JOHN M. WOBUS
48109
LOUIS F. WOJNAROSKI
97217
DAVID WOLFE
55112
DARRELL L. WONDRA
92122
GORDON J. WOOD
55421
WILLIAM T. WOOD
94703
JAMES A. WOODS
98006
JOHN D. WOOLLEY
17011
DONALD L."WRIGHT
ROGER P. WRIGHT RG6 2LH UNITED KINGDOM
20910
JACOB C. Y. WU
13323
WAL TER WUENSCH
MARYLENE WUEST CH-1211 SWITZERLAND
"07205
NICHOLAS WYBOLT
URS R WYSS CH-1205 SWITZERLAND
CHI YIP LAl 4YX UNITED KINGDOM
210 JAPAN
SUSUMU YOSHIMURA
90020
KENNETH YOUNG
55165
RAYMOND YOUNG
47401
STEPHEN W. YOUNG
55901
L. W. YOUNGREN
ISRAEL
GIDEON YUVAL
77550
RUSSELL W ZEARS
55455
PETER H. ZECHMEISTER
NW3 UNITED KINGDOM
H. J. ZELL
94086
ANDREW HARRIS ZIMMERMAN
44691
E. C. ZIMMERMAN
63110
JOAN ZIMMERMAN
48109
KARL L. ZINN
44139
TOM ZWITTER

--0

:r>


r
:z
rrl

::e::


m
rrl

I..N
00

-2Pascal at Sydney University
A.J.Gerber

~.

C.C.Morgan

Introduction

The temptation to IIplayll with software is more often than not too great to
resist, and we succumbed. Our experience (over 12 months) with our changes has
given us confidence in them, and only a few of our original mods have been
retracted. We are also pleased to add that users seem more than happy to use
these "extra" features, and that we often have to turn away requests for the
more fanciful changes which do get proposed from time to time. We do realise
that Pascal is deliberately designed to be minimal, efficiently implementable
and so on. We also have some rather strong views on where the absence of certain
features actually hinders many programmers, as opposed to those features which
are genuinely used rarely by a small group of users (which does not include
ourselves) .

1.
1.1

1.5

2.

Glitter
a.

A dayfile message bas been added to provide timing information.

b.

An option (*$w±*) provides warnings if any of the language extensions
detailed below are used by the programmer. The default setting is "on".

Language-oriented extensions

Most of the language lIextensions" detailed below do not, we believe, run
contrary to the Ilspiritll of Pascal. They were all implemented quite cheaply and
with little or no effect on compiler efficiency. Our experience with them has
vindicated them at least as far as we are concerned.

2.1

Reading strings

The standard procedure "read" is extended so that variables of type "string
(i.e. packed arrays of char) may be read. The definition is as follows: if f
is a textfile, and s a string variable, then "read(f,s)II is equivalent to:

Implementation-dependent/oriented features
KRONOS-oriented changes

for i := 1 ~ n do
begin
sCi] := ft ;
if not eoln(f) then get(f)

Necessary as always. In particular, allowing INPUT & OUTPUT to operate interactively under TELEX; and letting the compiler accept line numbers (sequence
numbers) on source files.
1.2

ll

en

Listing format

Note that read(f,s) never does a IIget(f)II when eoln(f) is true. Hence it never
causes a readln(f) II, and in addition it right-fills incompletely-read strings
with blanks.
II

A listing format modelled after the 1972 Stanford Algol W implementation was
adopted. Particularly valuable is the ability for programmers to check BEGIN-END,
etc. nesting with level indicators on the left-hand side of-the listing. $-cards
(lines with a 1$1 in the first column) may be used to control the listing's spacing, titling, paging, etc. A more interesting $-card is the "$INCLUDE 1I
which allows source text from other files to be interspersed within the main source
file.
1.3

For the benefit of student users

Some more checking facilities have been added. There is a compile-time check
against the assignment of a value to a for-loop control variable. The $T+ option
has the added effect of initializing the stack at run-time to
1777~~~~~~~~~~377776B·s.
This allows hardware cbecking for undefined reals and
(most) pointers. An oversight in Pascal-6000-3.4. was corrected: a check is made
that during a IIread" a subrange-typed variable is not assigned an out-of-bounds
value. The post-mortem dump was reformatted to make it a little more informative
and easier to read. In addition, a procedure which invokes PMD, but then continues
execution, has been added to the library (IlSNAPIl).

1.4.

Fieldlength handling
A different FL-handling discipline is implemented.

The user may preset his
run-time FL at compile-time by use of the (*$FLxxxxx*) control comment. This has
the effect of forcing the program (at run-time) to grab an amount of core equal to
its code space, plus "XXXXX". The default setting is:

run-time FL

=

code space + size (global-data-seg) +

2~~B.

These settings may, of course, always be overridden at run-time by not running in
REDUCE mode.

rn
2.2

Reading and writing symbolic scalar types

3:

to
It is possible in our version to read and write symbolic scalar variables
(RED,GREN,BLUE; ••• ;CAT,DOG,MOUSE; ... ;TRUE,FALSE etc.). This allows the language
to be more generous in its treatment of scalar variables - most users complain
of the absence of this feature at one time or another. An additional benefit is
that the post-mortem dump can now really dump such variables.
2.3

case-statement revamp

These extensions are arguably at odds with Pascal's "minimal language"
philosophy, but turn out to be incredibly useful. They are:
(i) the addition
to the case-statement label list of a constant "range
and (ii) the addition of
a "default" label. The first of these is surprisingly absent from standard Pascal
in view of the recent addition of constant ranges in the syntax of sets (e.g. [1 •• 9]).
We have a sneaking suspicion that this was not implemented because the Pascal-6000
lexical analyser maps colon (:) and dot-dot ( •• ) into the same internal symbol, thus
making compilation of things like
ll ,

case i of
~ ,2 •• 1~-;12: begin
rather awkward for a one-symbol-lookahead compiler. Our (ad hoc) solution was to
use the word symbol to in place of " •• n here. The default label is represented by
else and is executed if no constant satisfies the evaluation of the case-expression.
A typical example is:
case ch of

~to
'~'

Articles

rn
-0
-I

'Z'

to '9'
-;lse

rn
:::0

Articles

Introduction
-3-

Consider the following PASCAL code fragment:
2.4

And for systems programmers

~

T

~

record

Two further modifications were made to the language which are not intended
for use by "general-purpose programmers". They enable ODe to undertake systems

x

:;z

: integer;

rn

The extensions in this regard allow

:::e::

one to treat pointers as integers (and vice-versa), and to access the address of
a variable. They are:

(/')

programming from within Pascal exclusively.

var P:J Q : tT;
(1)

The "pointer to" operator. The use of "t" is extended so that if
 has been declared thus:
~



new(P);



Q

then the value of the expression "t" is a pointer to ,
and is of type "t':
(2)

The mechanism provided by the standard functions "ord" and nchr u is
extended in the follov.Jing way: every type declaration allows the use of
a corresponding IItype-function ll throughout the scope of its declaration.
The type-function is of one argument, of ~~; the function-result

is the same argument (bit-for-bit), but with its type changed to that of
the type-function.

3.

:~

P;

dispose(P);
Qt.x

:~

1;

The space occupied by the variable Qt has been de-allocated and yet Q
has a non-nil value.

in [2].

In conclusion

We would like to stress that our changes to Pascal-6000 have not detracted
from the overall efficiency of the compiler or its object programs. Our experience
over the past year or two with these changes has definitely vindicated them, and we
feel they are worth the consideration of the Pascal community at large.

This problem is mentioned in [1] and discussed

I should like to propose a solution which uses a garbage

collection system based on the block structure of PASCAL.

Performing

the garbage collection is simple and inexpensive, and the programmer can
easily arrange matters so that the space occupied by dynamic variables
is not allocated for any significantly longer time than that for which

(* Received (77/01/03)

the variable is actually required.

Tony Gerber and Carroll Morgan are at the
Basser Dept. of Computer Science
University of Sydney *)

The Scope of a Dynamic Variable
Consider

DISPOSING OF DISPOSE

procedure OUTER;

Stephen P. Wagstaff.
University of Lancaster
England.

var PI

tT;

procedure INNER;

Abstract

var P2 : tT;

This paper presents an argument for an automatic garbage collection
system for dynamic variables in PASCAL, obviating the need for, and risks

Variables of type T cannot exist outside the scope of OUTER, and neither

associated with, user-controled de-allocation (e.g. DISPOSE).

can pointers of type

It also

T.

Thus, whenever a dynamic variable is created,

describes how complete protection from tldanglingtl pointers may be

the space it occupies can be maintained on a list associated with the appro-

obtained.

priate "procedure-instancell (or in implementation terms, "stack frame").

Keywords

Protection, pointer, garbage collection, dynamic variables,
PASCAL.

(/')

rn
--0

---I

rn
3:

to

rn
:::0

On exit from any procedure, the whole list can then quite simply be returned

of type pointer.
The third and fourth points concern variant records.

to the allocation system.

When dealing with access to the variant part of a record (static or

The programmer can minimise his storage expenses by giving type
declarations the minimum possible scope (which is good programming anyway).

dynamic), the compiler should generate code to perform a run-time check

However, the question remains:

that the value of the tag-field is consistent with the variant implied

what happens in the case where pointers

reference identical structures but with differing type identifiers (and

(this check could perhaps be optional in general but mandatory for

hence, possibly, differing scopes)?

components of type pointer).

It seems reasonable to regard pointers

Finally, if variants are overlaid, there is a possibility that a

as referencing types rather than structures, and whenever two types have
the same structure, to regard this as a "coincidence ll •

This gives the

dynamic change of variant would result in erroneous access to memory

programmer a fine degree of control over both the lifetime and accessibility

space beyond that occupied by the variable.

of dynamic variables.

with either by forcing all variants to be specified with NEW and dis-

Thus, with

allowing any further assignments to tag-fields or by disallowing the

type T = .•. ;
procedure OUTER;
~Tl =

This can be dealt

"variant" form of NEW so that the maximum required space is always allocated

(The latter would allow dynamic changes of variant).

t;

C/)

rn

The last two points are discussed in detail in [21.

var Pi : tTl;

-0

--i

rn

procedure INNER;
type T2

By incorporating an automatic garbage collection system for dynamic

= T;

var P2 : tT2;

variables in PASCAL, together with appropriate scope rules for

~

identifiers,

the responsibility for de-allocation can be taken away from the user,

new(P2);
Pl := P2;
the distinction in the programmers mind between types T, Tl and T2

would be recognised and the final statement would be flagged as an
error by the compiler, as an incompatible assignment.
Associated Protection Measures

Should it be desired to trap all possible address violations
associated with pointer variables, four accompanying measures are required.

and hence a class of potential address violation errors can be eliminated.
Given a little programmer awareness, the cost of this added protection
need not be significant.

Together with the other protection measures noted

all address violation errors can be wither prevented at compile time or
immediately trapped at run time.
References

1.

Wirth, N.

2.

Fischer, C. N. and LeBlanc, R. J. IIEfficient Implementation and

Pascal New3letter No.5 September '76 p.29

Optimization of Run-time Checking in PASCAL".
Firstly, to ensure that spurious pointer values do not exist, all
pointers should be given an initial value of nil.
Secondly,

(assuming that pointers are implemented as main memory

addresses!), external files should not be allowed to contain components

SIGPlAN Notices Vol. 12

No.3, March '77, p 19-24

(* Received 77/05/17 *)

3
t:I'

rn

=

WRITELN(F)

What is a Textfile?
The PASCAL revised report, section 6.2.4 in particular, is in serious
error as to the nature of textfiles.

PUT(H@),

EOLN(F)

EOF (H@)" and

PAGE (F)

PUT (H) .

This error arises -- or is demonstrated

by -- the definition of type TEXT as FILE OF CHAR.

(As a typographical con-

At this point, we have developed the structure that is necessary and

vention, program fragments are presented in upper case, and the pointer operator,

sufficient to support all the standard textfile operations.

up-arrow, is represented by the character @).

benefit (or is it a side effect?) we have a better appreciation of the

As a result of this lapse,

complex special-case notions are introd,uced as primitive concepts.

Please

embedded file, or file-of-file, concept.

As an added

Before running off to reimplement

notice that I am not advocating a change in the language, or an abolition of

textfiles the new way into your favorite compiler, however, let's give some

existing notation:

thought to extensibility.

I merely propose a new, more useful, understanding and

definition of the textfile notion.

If a text file is considered as merely a nest of files, then those
implementations which would like to give access to such things as page

First, consider the files F and G:

numbers, line nuinbers, and vertical printer spacing ("carriage control") will

F:

TEXT;

G:

FILE OF FILE OF CHAR.

have to kludge those features in as primitives:
we started.

Obviously, a READ or WRITE performed on F will perform the same on G@, the
lIinner " file in G.

Some of the auxiliary I/O constructs, however, change in

a very enlightening fashion:

we notice some nice hooks:

TYPE TEXT:

RECORD

reviewing all available literature on the

(*EXTERNAL FILE NAME, ETC*)

semantics of PASCAL file operations, we conclude that

WRITELN(F)

becomes

PUT (G),

READLN(F)

becomes

BEGIN WHILE NOT EOF(G@) DO GET(G@):

EOLN(F)

becomes

EOF(G)!

P:FILE OF RECORD
~ET(G)

I'Tl

END, and

We conclude that to supply the structure

L:FILE OF RECORD
(*LINENUMBER*)

each line is a file of characters.

(*SPACING*)
C:FILE OF CHAR

we haven't considered the PAGE statement.

END

Let's add another declaration:

END
H:

FILE OF FILE, OF FILE OF CHAR.

END;

Now, anywhere we used G, we can use H@:
of READLN changes.

logically, however, the re-representation

The whole set of equivalent construct-pairs becomes, with

The comments point out places where interesting implementation-dependent
features can reside.

the addition of the PAGE statement:
READ (F)

READ(H@@),

WRITE (F)

WRITE (H@@) ,

READLN(F)

BEGIN WHILE NOT EOF(H@@) D0 GET(H@@):

William C. Price
28282 SW Mountain Rd.
West Linn. OR 97068 USA

(* Received 77/06/10 *)

IF NOT EOF(H) THEN
IF EOF(H@) THEN GET (H)

ELSE GET(H@)
WCP:pt

END,

- 1 -

en
I'Tl
-0

--I

(*PAGENUMBER*)

implied by WRITELN, READLN, and EOLN, a textfile is at least a file of lines, where

There is even more to a textfile:

thus we would be back where

If, however, we consider TEXT to be predeclared as follows,

- 2 -

Generic

~()utines

and

VariaOle Tyoes in

GenerlC

~ASCAL

o 71271712uo

L, I /

t. I' / (

to
~fneric

HOutlnes

~nO

VariaOle

ly~es

in PASCAL

=========~==========~========================

riS

~Jutines

1 i ,:

~~J

varlaole types in

~AS(~l

0

~~SC~L-G~T.

r l' (, e t .~ i l e'J C1; s C'.J S S ; c: ~ (i fl II e r rt: (j") a f t 11 E' 1 jed san d res u l
tnunj in Lil. An experilrentdL version of the oroposej
extens~on5 ,s inulempnted oaSeo Ijn tne ~ASCAL P2-comp~ler~

may

t

s

bp

rn
C/")

8. Austern\uehl, H.-J. t10ftmann
to~puter Sc;ence OePdrtment
TM Darmstadt, Germany

Generic r0~tinps aM~ variaole tyD~S, as intrOJucea in E~1 [1J, dre
d means to pDstPOne tne bindIng tim. at routines and data. In this
oao~r it is exa~inpa to ~hat aearee SUCh feat~res may be carried over
to PASCAL .ithout SEvere violation of the static type checking
requirel11ent. Yle concl;..Jde that gen~ric routines fit to PASCAL, wnile
var;aolp. ttoes nave to ~e subject to strong restrictions. 6es;des,
tney may be ~sea only in connection with a special syntactic form,

=

:E

TI~e ~ASCAL aes19n ~rinciples reliabi Lity ana clarity of the lanqUdtH' arp tnEo' cr;terla tor tnt' extension. Tnese pr;nciples, ;n the
E:xtrerrp., reQI,Jire stat.ic type chE'c!(inq anu prohiOlt run time type
Ct·)Pc~·in:: of C'lp!:"rJnos.
In PA:)Ci\L, the caropi ler is aOle to assert the
co~nat'oilitv ot oper&na ty,)PS for eacn operation, inCluding field
Sflect ion an:J arroy su[;scrir.l1nq. rherefore, in our extension . . . e nave
to qiye stdtic intorm&ti8n auout v~~i~ole types to tne compi ler whenev~r ~~ Jr~ anle to.
It we idil, a~ a ccnsequpnce, there must exist
,ntertdc~s to ti~ varidcle ty~)es at comp~ le ti~e. 4t those intertac~&, ho~~ver, wP have to adw1t oyna~ic ty~e chpCkS to ensure the
~aliai(y of tht tixin~ at
run time, and there type-dependent run
tim~ errors ~ay oCCur if the run tii1e inStdMce of the type is not
in the set of allc~eo types. Tnese interfaces ~ust De tne only points
wn~re 1ynamic cneCks are rpql"red, and the user must De aware of run
tirre errors only at thOse points.

C/")

rn
""'CJ

IntrOductiun

-i

rn
Uniun Typps and ttle Generic Form in EL"\
Thi, Pdo~r Is concerned .Ith the possiutLity ot extenalng PASCAL
oy two mdln features ot ~en wegDrejt"s langudge ~L1 [lJ, namely
~generic rOutines~ ano 'treatment of data types as values-.
In a generic routine in tne sense of I:.L1, formal parameters are
DOUno to a set of oat a types, and tne type of an. ar9ument must De an
element ot tne tyee set at the corresPonoing formal. Insioe a generic
aifferent ~ctions m~y be exeCuted aepending-on argument types.Thus, a GenerIC routine may be regardea as a COllection of different rOutines tor arguments ot different types under a sinqle name,
i.e. as tne abstraction ot an operation that requires aifferent
alg~rithms tor dlfterent Input data types.
From tre seconD feature of ELl, the treatment of types as values,
tollows tne aoility to evaluate ano compute types and theretore
the existence aT type variaOles ana type functions. Types are not
treated stat'ically, but in a oynamic environment. Hence, var~able
types, too, for~ abstractions, since routines are not to be bound
to tneir oata at definition time, Out the structure of objects may
oecome known orlly at campi le or even rUn time.
we are .ell a.are of tne Conceptual difference between ELl, whiCh
Is an interpreter-baseo lanquage (D,sed on the facilities of the
~CL syStem) where type cheCking may De aeferrea untl l run ti~e, and
~A,CAL, where all types have to ~e ~nOwn to the compiler, Our goal
Is to aeter~ine tne restrictions to oe posed on the ELl features
tnat are useD to postpone the binoing of procedures and data from
proqrammrng time to compi le Or even run time Oy the type cneeking
requirements of FASCAL.
In this DdPer, .e deal witn features Df ELl In PASCAL terminology,
too, SO we speak of types Insteao of modes and Ignore that ELl is
an expression language, i.e. we distinguish between statements and
expressions. The extenoea PASCAL tnat we investigate is referred

3:
ttl

rn
In ~Ll, we find url~on types. fhe medn,nq of 'Uni8n', there, ;s
only thp postponement of type cnc1c~, i~e. at run time each object
ana varijule nas ourirlg its litetil1e a oefinite and uncnangeable
type. Ir, Pcifl1Cul&r, the aef1nite type ot ~ union-typeo parameter is
detpr~linpO Oy
th~ argument
type ~nO c~nnot ~e Changed s~bsequent to
creation.

A qen~ric routine has carameters ot u~ion tyees. I"sioe its
Doay, tne alternatives 01 tne ~n~on t/PES ~~y be sinqlea out by
"leanS of the 'qeneric form~ tt13t resemoles a case statement in
PMSC'L. A generic form consists of se.er_l alternative orancnes
ancl ~ neaaer na~inq toe pardn1eters the typ~s of ~nich are to be
tixpd. The rigtlt hand sides of trle ~ranches are statements, the
lett nand sials are formed of type-lists (one entry for each
generic 06ra~et~r) and joditional (ovtional) predicates. In the
typ~-list5, alt~rrlativ€s (or unio~s of alternatives) of the
param~ters' uniorl types are speCified, to wh~ch the types of the
correspondln~ p~rameters are fixeo in~ioe tne branChes.
nranch for a qiven combination of argument types
ate 0 on 0 i l e t i me, ; t a l L t y pes i non e 0 f the t y p elists 'cover" (for aefinition ot cover see [lJ, P.<~o) the correspon0~nt drqu~pnt
types. Since argument types ~ay be unions (if arguments are ~ardmeters at Otfler ro~tines), a" argum~nt type may be
onlY p~rtidlly covpr~a (l1J,P.2j~) oy d typp-ljst element, i.e. some
alternatives ot the argume~t tYpe are not alternatives of the typeL;st tltlement, j,oIh1le others are. rr.en tt'l€' comf.)i ler is nOt aDle to
decicp w~etner tne net~nits run timp t)pe fits or not, ana must
The

In Q y

be

aoproprl~te

S e lee t E'd

;::0

Generic Routines ano Variable Types in

PA~CAL

07/~7/7720b

gene rete a run time test. Tnis, holds, too, if the additional predicate is not evaluable at compi le time.

The

PASCAL-b~r

&eneric Extension

In weqbreit"s ECl system there exists a compi ler as well as an
interpreter, bOth fully compatible. Each may call the other as a
suoroutine. Theretore tne compi ler is able to evaluate parts of a
compi lation unit (routine) and to use the v~lue instead of the form.
&0 predicates of a generic fOrm may be evaluated by the compi ler and
a compile time selection may be done, In the generiC form carried
over to PASCAl-bvr, preoicates are not allowed. There are two reasons
for this aecision:
1.

~e have no interpreter in our system, Therefore, predicates are
not ev~luable at compile-time, and a run time selection is necessarY for eaCh call of a generiC routine with predicates, even if
the covering of all argument types is asserte~. ~o the numDer of
possiole run time errDrs increases.

2. ijy o@sign, a oecision in a generic form is a decision deoendlng
on tne types, nOt on the velues of the arguments. Accoroingly,
oreOicates in a generic form sno~ld De predicates on types only.
The type "lasses that are ceflned implicitly by predicates,
however, dO not have ~uCh a specific structure that the compiler
is aole to hanale them (e.g. all one-aimensional arrays). The
cawpi ler ~i II not be able to determine any comaonent statically.
Therefore a static type cheCking will no ae possiDle inside the
branCh ana sO the adva~tages of tne generiC form wi II De lost.

union tyoes in the sense of ELI, no~ever, fit to the reQuirements
at PASCAL. First, tne structure of eaCh alternative is known to the
Compiler, so there is no difference to a normal PASCAL type after
the selection of one single alternative in a generiC form. second,
tne type constanc, during tne lifetime of a union-typed parameter
allows a staCk Imple~ent.tion of such parameters. when the procecure is entereo, the definite type _itn its length Decomes known
(Since this happpns at run time, run time type descriptors have to be
generat~d by the compiler). Since tn~ length is uncnangeaole, an
aaoress on the staCK may be Computed for eaCh union-typea parameter
and the argument values may De copied. Access to tne parameter
values is inairect via the compi le-time-computable local address,
~here a pointer to tne run-time-computable real adoress is to be
stored. Since .e are able to ~Ut union-typed parameters on the
staCk as opposed to tne PASCAL heap (where flexiDle-length parameters woulD have to oe putl, there are no oroblems with RELEASEcommanOS of the user. So union-typed parameters do not mess UP
PASCAl"S storage management SCheme.
The demand for static type cnecKing implies tnat eaCh qeneric
parametpr is fi.eo to a oefined, compiler-known type (including a
union typel at the entry into a generic Drancn. If that type is a
union, operations on tne pdrameter are restricted to assignments and
eQuality tests inside the Drancn, Since static type cnecking reQuires
tully fixed operana types for any otner operation, This restriction
torces a progra~mer to write aOwn reoeatedly similar branches for

3

Generic koutines ann variaoLe tyoes in PASCAL
071271(72Uo
similar, but different types (e.y. array of intpger vs, array of
real'. Tne PASCal conventiun of identifylny a type by its na~e,
not Oy its structure, aisenacles us to oefine arrays of unions and
SO to hanale si~ilar structures In a single or~ncn, since we then
hao to nave variaOles of type array of unians. unjon-typed variaoles, nowever, .ill not be aLloweo, sinCe (a) each variable must
nave an unchangeaole type (tnere is no cha"ce of a postponement of
type cnolee as with p.rameters) ana (ol unjon-typed variables wculd
impose further neea for run time type CheCKS. So the disadvantage
of multiple writing de.n can not oe remedied Oy using unions, we
will see later that there is a slight improvement oy use of variable
types.

with the given restrictions, the generic form is easily transferaDle to PASCAL. Tnus, a PASCAL-ijWT procedure body may oe either
a normal PASCAL proceaure or a generiC form. The only violation of
static ty~e checkinq ~y tne use of a generic fOrm may occur if only
oartial coverinq is 91Ven at compile time ~nd thUS a run time cheCk
is needed Tor craneh selectiOn. If at rvn time the comolnation of
arqument types does not fit to any of the branChes, a type-dependp.nt run time error will reSUlt, viOlating the principle of static
tyoe thec

en
n

In PASCAL, we dO not nave the faci lity to freele variables, since
there is no interpreted environment avai lable, A variable type at
programming time remains variaole at compi Ie time ($lthoU9h being
invariaole at run time). Static type Checking, however, requires a
wiae range of constancy for type variables, since tnese have to act
as repr@sentatives of the run time types: Two variable. declared by
the same type variable must nave tne same run time type, since the
compiler can cheCk their types only by means of the name of the
tyoe variable. As a conseqUence, a type variaDle in PASCAL-GVT must
not be assignee a value in any other than in its declaring proceaure; otherwise assi,nments to a tyoe variable between oeclarations
of two variables in hierarChically ordereo procedures might result
in different run time types of thOSe variables in spite of the com~
pile time assumption that they haVe the same type.
In contrast to tL1, where type checking of variable-typed variables ana, it neee be, insertion of operations for conversion of
their values, may De done at run time, the static type checking
mechanism of PASCAL requires full compi Ie time cheCking of operand
types for every operation other than assignment or equality cheCk
(wh~re no specific types, but only equality of types is required).
Tnerefore

~e

have to introouce a facility to nai l aown types of

variablp.-typeo variables, similar to tnat we have· for nailing down
types of generic parameters. we define in PASCAL-GVT a new syntactic
form, calleo 'gpneric expreSSion', whiCh looks like the original
generiC for~ used as the DOdy of a generic routine, out has expressions insteao of statements as its oranChes. The 'oarameters' of a
generiC expression na~e the variaole-typed variables, the types of
whicn are fixeo to allow operations on them in the branches, By this,
static type cheCking remains possible in spite of allowing variables
to be Oeclared with (at compile ti",e) variaDle types. Here, too, we
have an interface, where type-depenaent run ti~e errors may be e.pec~
ted, if the definite combination of types at run time is not covered
Dy on~ of tne type-lIsts in the qeneric form. Only variables or parameters Can nave a varlatle type, since there are no operations on variaole types ava; lable. ThUS, a generic e.pression must have a unique
invariahle typP, i.e. all oranches must nave the same resulting type,
whiCh must be invariaole. There is only one excePtion to this uniQue~
ness requirement: Assi~nment Of an invariable-typed value to a variaol~-tyoed iariable is done Oy use of the generic expression, too.
Then the left hana variable is entered into the 'parameter'-list of
tne generic expression forming the right hana sioe of the assignment
statement, and eacn cranCh of tne generiC expression mUSt have that
result type, to whiCh the lett hand variaDle is fixed in tnat Dranch.
.itn tnese restrictions ano svntactical aids type variables may
De handlee in a static type chec~inq environment. Besides variables,
ho.ever, we hdVe to consid·er type functions ana other type-valued
exoressions.

",ust be forbjOden. In addition, even without recursion, type functions are not com~i l~ time evalu&Dle oecause of the existence of
parameters and 'looals, Since the compiler is unable to determine
tne ~tructure of any fu~ction-defined type, those types are obviously
meanl"91~sS ane tnus are forbidden in PASCAL-GVT.
As to other ty~e-valued expreqsions, we must consider the above
remark on recursion. rlere tne same hoLds for iteration. If we allow
Complex type-valued expressions, it will always De possiole to
assig"~ TVA~ := array ( •• ,J of "AR, whiCh structure will ~ot be
reCOgnl~aDle statically. So we must toroid, too, complex tyee-valued
expressIons and allow only type variables and type constants to
apoear on the right hana side of an assignment statement.

r
::z
IT!
~

en
'II::

c.o
I/O

'II::

......
0

Structures Over

~~riable

Types

.titructures !arr~ys, recoras) over unions cannot be oefinea,
sInce type unIon Is only allowea lor oarameter specification·

parameters in PASCAL, ~o~ev~r, ~ust be specified not oy a ty~e
structure, out Oy a type name, ano compatibi lity of aCtual ana
formal p~r~~et:rs ;s aetermined only by equality of tne type name,
no~

by SImI larltv ot str~cture (or a certain kina ot covering, if
un,ons werp- ,nvolveo). SInce we 00 not allo~ variaoles of union
type, tnere cannot exist any cOmp8tiole araument for a formal of
'strIJct~re

type

of

union~.

StruCtures over tyPP var,aeles, ho~ever, are meaningful, since
variaDles may De usee in any context where otner types may be
usee. Although its o.erall ~tructure is known to the compi ler the
entire variable of suCh a type is considerpO a variaole-tvped'varl_
aOle insefar as its real aooress is aetermineo only at run time and
access is indirect. Recoras are pnysically restructured to Shift
ty~e

variacle-typeo +ielos to tne end ana so to give information about
th@ relative aOJress of tne tixeo-typed fields to the Compiler. Bath
arrAys and recor~s may be stOred continuously without any use of.

internal pointers ana thus copying may De cone without examining
suostructures. Sincp the co~piler has infor~atinn aoout the overall
structure of suCh an array or record, only COmDonent typeSi if varianie,

have to oe tixed 1n a generiC expression.

Example:
vilr Tv"R : MOllE;
prOce

TPAR;
T~AH;

VA'"F~LO:

F lxFE:LO:

ena;

VARRAY;
I~TEGEk

Generic Routines and Variable

Ty~es

in PASCAL

v1i27!f7Zvo

VHr VV: IVAR;
(;eq;

is ~
tion,

',J: INTEGER;

r"\

~aria~!le

and

TYPes in PASCAL

11'1H:(itR]

VV;

I R tAll

r R L' NC

to

~e~ni~qful eX1.ension in
SlnC€ ~e ~OW are 8blp

im~)lement

8

-0

:to(/)

the direction of functional abstracto dpnote on~ operatjon by one name with

no reaara to oitterent aota typ@s

I := generi c (VV)' Of
enG

Generic Routir'ES
:)1/<1I70u>,

~itn

possiOLy different algorithms

tnp operation.

n
:to-

r
z
rn
~

U V)

... J;

(/)

'S'nCl;

~

ACKnOwleapf'noent

~e thankfully
our f::n'Jlisn.

Cone lus ions

I.D

aCknowledg~

the DDvice of Hans Kron in

impro~ing

1<0

""

I-'

a

Tyoe variauility is a mearlS of separating. data and programs. In
EL1, tt is a meaninytul instru~pnt, since compile and run time are

tlomngenuous in that compile time of rautinesand run time of type
evaluAtion may he the same. Tnus, liorary routines may be written

References

usta ~ndepende"t ano tne~r types evalu&tea ir"l an interpreted
environment or their cOMPilation, 50 aChieving an efficient and

type-secure object code in spite of data injepenoence, since type
chpcKing may be

~one

at

Comp~

le time.

In PASCAL, were compile ana run time Are strictly separated, the
static type checking mechanism imposes strong restrictions onto the
use of type .aria~les, ~aking them constant in hierarchically suboraered Droeecures. ~e are not BDle to extena PASCAL"s type scheme
ay iterateD typps ana type functions, which may De regarDed as
classes of tYDes, since these two features require dynamic treatment. Tnus the type definition part remains the only place where
types may De constructed.
The use of type variaules in PASCAL-bVT is along two axes:
is an extension of the generic

(1) aireetly for oeclaration; this
parameter mechanism to variaole~;

(2) as aase tyee ot a structure; ~e may look at similar structures
it we represent the differe~t base types by
a type variabLe. However, if we want to abstraCt from tne base type
Qf • structure and use a type variaole, we have to COpy each instance
at the structure with invariaole oase type to an instance of the
structure kith .ariable Dase type, Since, even if we were able
to fix that •• riaDle nase type in a generic expression to the right
invariable pase type, the PASCAL convention of considering two equal
structures as oifterent types enforces copying. Such a usage may be
meaningful, however, ;n the context of generic routlnes to avoid
multiple writing oown of similar brancoes, Then, we may enclose
the generiC in a kina ~f pseuDo-procedure (generiC, too), where the
cop.ing is done, ana the yeneric itself may Oeal only with one
structure over a variaale base type, Especially for library routines
one must consider the traoe off Detween tne COPy overhead On the one
hana ana the possibi lity to use one name for one operation independently at types on tne athpr nand.
~naer one Single type,

Providing more type variaoility in PASCAL-GVT would have violated
the aoove-mentlonea principles of our extension.
The feature of tne gener1c routine fits mUCh better to PA~CAL than
tnat of type v~riaDllit., since we only nave to exClude the grouping
of tyres by predicates to r~taln static type CheCking. This feature

[ 1]

~euorpit,~:

Tne

(,()~m.

(2)

Treatment of Data Types

"(,i",

1/(1Y"),

5,

in EL1,

o.2S1~'/)4

~.:
Zur verwenaunq typaDhaenoiger Prozeduren und
variELI.r Typen in ~A~CAL, Diploma Ihesis, Computer

AUster~uehl,

~cience
~'artt\

TH DarmStijdt,

~~uartnlent,

llt(,

H4

File

Paoes

(* Received 77/08/05 *)

Nr~

PU

~055,

The University of Tasmania
Postal Address: Box 252 C, G.p.a., Hobart, Tasn--ania 7001, Austr'J!ia
Te!ephor.e: 230561.

Cables 'Tilsuni'

Telex: 58150

U WtLj -<-1J:Lelle..<,t you to Imow too tlw.t d -0., qude pOM-<-ble to leave a;t;tJUbltte
-<-lLbC,".J:'a.uoH ou;!: 06 a BUf'Jlclllghi> B6700 PASCAL pltogltam, and;to .t.ttpp£.Lj d aLt -<-n ;tIle
LiQJ'!2- Hew Language ic.ontltal pltogltam? JCL?) to be bowid -<-n a;t apen;.ng t-<-me. TlU-i.
rv[p ;oac.lu.ne- cuta /[ul1-depel1dell;t -<-n6o/[mauoll JUght dtU: oS the PASCAL p/[og/[am, but
«'Ducd b2. uHbecuwbll} .tecUo1U> -<-6 done bO/[ evcu11} PASCAL ~ile o/[ /[Wt. TIU/.> wou£.d be
~e.L6-ev.Ldertt;to aJ!tj B6700 P/[og,1ammell lteacUltg DUIt doc.wnevJ:Lauol1, btU: m-<-glU:It';t be

:to
10th Nay, 1977
Dear Andy,
All is forgiven.

Let's forget the past and get on with work.

Distribution Centre for Australasia:
I await your suggestions.
I think we can
act for Austral ia, New Zealand and Papua/New Guinea, but Japan is probably nearer the U.S. than us.
Standards: great news!

desparately needed!

I am on tenterhooks!

O.tfU2/i.,,6.

Your point (4): Remember B6700s and 85500s have been around a fair while:
they are also today's machines. Ny point here is that the CDC 6000s are just
about an extreme in simplicity of (i) architecture, and (ii) operating system.
It is quite natural that troubles will arise at the other ends of the spectrum.
It is also quite natural that systems with reasonable affinity will prove to be
easy to implement PASCAL on, for the assumptions are the same. Actually the
CDC conventions and operating systems are more troublesome than its architecture
wtlich is a triumph of monolithic simplicity. Examples of the (again subtle)
effects are PASCAL's nJnexistent attitude to interactivity, the lack of read/write
scalars, and so on. Quite a long list of regrettable influences could be compiled.
t1any of them do not directly lead to implementation difficulty, but show up as
a less-than-perfect construct.
I grieve, but can do nothing about it.

CDC-bias, etc: May I take some time to talk around the points you make on files,
program, and CDC-bias?

I donlt expect a reply since you are busy, but lid 1 ike

to try to convince you that I have some points here.
Your point (1):
fi les as sequential access structures: I t ..-;·taZl?j aOY'ee.
Sequential files are useful; they are data objects; they are needed fort'i'1e
purpose you cite. What I try to say is that files are not full PASCAL-variables
in that their usage in array of file or record of fi Ie, or fl Ie of file or in
expressions, is undefined. They partake of few properties of full variables; about
many~procedure or function-names for example.
I express a sadness that the
opportunity has been lost of expressing this well in the PASCAL language.

as

Your point (2): arrays as random-access.
only partly agree. Sure a
slow array could be implemented as a random-access fi Ie, but not all randLFiIaccess files can be implemented as slolJ aY'Y'ays. Unless you are wi 11 1n9 to thrm"r
away PASCAL's strong typing and admit truly dynamic sized arrays. The point being
that even a random-access file is a sequence of variable length. PASCAL arrays
are always of fixed pre-determined length.
I e~phasize that random-access is
a property of the access, not of the file (though CDC's standard implementation
of files disguises this). Think abstractly. So lIve no objection to slow
arrays; they're just not equivalent to random-access files.
Your point (3): program heading.
I can't see FORTRAN's ident"~cal program
heading as a 'coincidence', I'm afraid. Your subsequent argument is a pragmatic
one for collecting all machine-dependent information at a central place. A good
practical point. The counter-argument is that based on a feel ing for structuring.
One of the precepts of structured programming is that information relevant to a
structure should appear in one place (the point of decision) and that only. So
this urges me to collect all file data at one point: the type or var declaration
for it.
--Besides this, several nasties creep in if the information is collected in the
heading. CDC PASCAL crudely restricts 'permanent' files to ones declared
in the outermost block; if this restriction is 1 if ted (an obvious step leading
to better structuring of subprograms and their scopes), then name confusion may
arise (two files called INPUT?).
In addition, the program heading could become
very large for camp.lex programs, and a useful faci 1 ity has been pre-empted (I mean
the facility to activate a PASCAL program with genuine parameters). Now much
of this is non-standard, but I hope it better illuminates what 1 mean when I say
there is subtle CDC influence (and I mean subtle, not blatant: ~/irth is a good
designer).

-Pa/Le'lthe.uc.afJ'.y, ovell the lMt 10 Ljea/L6 I have had qrUte -<-J1,uma;te c.on;tac;t
W-Gtll c7,(.L ;the tl0Uow-i.vrg hy,stem;: 1B,\I1130, 18:1360 & 370, 18.1.17040, IBM1401,
CDC6600 (Scope) & CLjbell 72, (K/[ovrOh) CDC1700, El1gWh-Elewuc. KDF9, Etuo;U 503,
PDP-S, PDP-ll (20,40,45 &70), Bu.-'1ltougl1,; B1700, B6700, Un-<-vac. 110&, ICL 1900, .
t~I" 10 (KIlO), Va/L·can and 1'U:Vtda;ta.
I c.ouid add -<-11 molte p/[e-1967 mac.fUHe6.
I
I have. managed ;to develop Ct c.olHw-0.,~eUlt' h vwhe nO/[ mac.YUIle6 altd ;thruiA
-in fJ2-~uci:ce,6 . •.

o:J

=-'8.Y'suGsive 8egmen·t.

-i

! a:t1 interested to know that the non-academic world in the U.S. is interested
in PASCf\L.
I'd love to know how many of those PUGN subscribers are (i) miniCDrlr::uter firms, (ii) mainframe operators, (iii) software houses) or (iv) just
interested individuals? It'd be interesting, yes? Thank you too for the Minnesota breakdoHn of lIsage. 5 - 10% usage rate in number of runs is indeed good
pro~ress.

Our first-year course will switch over entirely to PASCAL next academic
year (a first for reactionary Austral ia) now our campi ler is operational, and
wi 11 put on a "\.Jhat's in PASCAL for yoU!1 course later this year for the general
academic population.
It will be interesting, as our FORTRAN usage at Tasmania
has never been dominant due to some complex historical constraints. Switching
Algo~into Pascallers is easier in one way, but convincing them of the merit
of the switch is more difficult!
We are also organizing through Burroughs to run our compiler on a B7700
system, and probably a dual-processor B6700.
If I can get to any others of the
range (eg the new 6800) I'll try them too. \1e aim to thrash it on re-entrancy
and any possible model-dependent features. Hardware documentation is very poor
i~ Burroughs.
And needed.

progra~

Open Forum for Members

fly bes t wi shes.

(/)

rn

I hope the work load doesn't get you down.

Yours sincerely,

rn
3:
b:I

rn
;:0

Open Forum for Members
TELEPHONE: 692 1122

BASSER DEPARTMENT OF COMPUTER SCIENCE
School of Physi cs (Bui Iding A2B),
University of Sydney, N.S.W. 2006

24 May 1977

Andrew B. Mickel,
lliitor, Pascal Newsletter,
Canputer Centre, 227 Exp Engr,
University of Minnesota,
MINNEAPOLIS

MN

55455

UNITED srATES OF AMERICA
Dear Andy,

Thanks for mailing my newsletter #8 air mail - as Arthur Sale
points out, three rronths' lag is unacceptable. (It's continually
annoying to receive conference notices and Calls for Papers fram ACM
_eks after the event.)

I am mainly writing to air a grudge. At the beginning of this
year we sent you a short article dealing with changes to the Pascal-6000
ca:rpiler we had made. Although you no doubt have good reasons for not
publishing any word of these changes, _ are at a loss to understand why
you subsequently publish proposals for changes, when _ have actually
irrgJlemented these changes and can attest to their worth or otherwise.
W= have not attempted, nor do we wish to attempt to irrgJlement features
such as dynamic arrays and initializations as it is obvious that a lot
of people are debating several alternative proposals. With one exception,
what _ have irrgJlemented entails sirrgJly weakening restrictions already
present in the language. 'l.'hey are:
(1)

Our other under-the-table extensions (type-functions which
relax type-checking (cf. Richm:md's transfer functions in PUGN #8) and the
address-of operator) illustrate nore closely our ideas on why we feel no
regret at "extending" Pascal. These systerns-oriented changes were made
for purely selfish reasons: scxre of us wanted to carry out systans
progranming entirely in Pascal, despite the fact that Pascal was not
designed as such. '!he point is that progranrning in "extended Pascal" is
nruch more satisfying than prograrmning in an assembly language. Our
concern is therefore that we should make Pascal nore useful than it
really is, sirrgJly because the alternatives available (on the ax: Cyber)
are so abho=ent. In our minds, we always maintain the distinction between
"Sydney" and "Standard" Pascal, and so dces the corrpiler - it will, unless
directed otherwise, flag every use of a Sydney-irrgJlemented extension.

Finally, we would be grateful if you would give our nodifications
sane publicity. They are actually irrplemented, they work, our experience
with them (over a year) is positive, and the l.ltlJlementation overhead
incurred is definitely acceptable.

(/)

rT1
-0

-l

~.grinting,,~

~~

reading "packed arrays of char";
(* Editor's Note: In a reply dated 77/06/07, I stated:
"I just received you letter, Tony, yesterday.
John and lowe you several big
I found out shortly after reading your 24 May letter that there was

reading and writing symbolic scalar ty~s;

(3)

allowing a "range" of labels for case-statement labels;

apologies,

(4)

providing an "else" - clause for case-statements (this is the
exception) ;

(5)

allowing functions to be of any type (except file).
a new one, only just irrgJlerrented.)

material on John's deck which I had never seen: a listing and some correspondence.
I hope you don't get the idea that we go out of our way to hassle Australian PUG
members! •...
liThe trouble with an else on case is that it catches things you don't plan for
Separate
as well as the things you ~and you can't distinguish among them.
compilation is a good thing. Your include feature or something like it will wind

The debate on the suitability of the else-clause in the casestatement seems to be a rather ove=rked one, reminiscent of the dangling~ debate for if-statements. wirth talks of convenience as opposed to
necessity in this context in PUGN #8, but I cannot help feeling that a lot
of the language would disappear i f this criterion was applied to the whole
language (e.g. the with-statement, if-then-else is really only "case
- of true: ..• ; false: ... end", record variants). Most people
here seem to be perfectly haPPY about using the else-clause - they
include people who one could genuinely call "good" prograrnrers.

(/)

Surely then, our efforts should not be concentrated on standardizing
Pascal at a time when Pascal is beginning to show signs of age. There are
non-trivial deficiencies in Pascal which are being attacked in nore recent
languages (Eu-olid, CUl, Alfhard et al). Pascal might better serve therefore
as a testbed in which irrgJroved ideas may be evaluated. I have this recurring
nightmare: I'm reading the UTOPIA 84 Newsletter and they're carplaining
about all these old-fashioned people in industry and academia who won't rrnve
fran Pascal to UTOPIA 84 because of the large financial investment tied up in
Pascal software •.•
Pascal's role is not, I belJ.eve, to serve as the next
irrgJortant widely-used general-purpose language. It is a credit to its design
that although it wasn't designed as such, it has nearly becane such. let's
keep Pascal in its proper perspective, please!

(2)

(This is

:z
rT1
. ::E:

up in Release 3 [of Pascal-6000].

-------

"Regarding Utopia 84, ilve had the same thoughts, but we haven't even gotten
rid of Fortran yet, and once that precedent is set, getting rid of Pascal when its
time comes will be easier.
No, I don't think you comprehend the politics of getting
a language like Pascal widespread.
So yes, Pascal's role is to be the next
widely used general purpose language, and any attempts by you or I are going to fail;
it simpley has too much merit on its own to stop it.
Languages like Euclid, Alphard,

and CLU are not general purpose and therein is the

rub!

adopted different syntax for similar semantic constructs.
"Thank you again for all you have done .... "

"P.s.

What does "grinting" mean?"

*)

Besides they needlessly

rT1

ANPA RESEARCH INSTITUTE

1111111111111

1350 Sullivan Trail, P. O. Box 598
Easton, Pennsylvania 18042
(215) 253·6155

June 1, 1977
Mr. Andy Mickel
Pascal User's Group
Dear Andy,
Each Newsletter seems to be getting better.
high quality both in presentation and content.

Number 8 is truly

I have given lots of thought to the question of PASCAL software
tools, There is no question that there exists a great need for the
collection, review, and distribution of shareable software. We need
to do this within PUG so that we can preserve our independence while
increasing our scope.
Up until now I have collected and installed at Lehigh University
a number of useful programs. I've used those to trade to get others.
The problems of wider distribution have me truly worried. At Lehigh
our antiquated 7 track drives and strange 63 character set make machine
compatibility problems (via ma~netic tape) almost insurmountable. I've
even had five crates of cards (50,000) punched to import some software.
Postage and other distribution costs have been paid out of my own pocket.
There has got to be a better way - here's my suggestion:
I recommend that PUG Newsletter allocate a number of pages in each
issue to the publication in source form of generally useful PASCAL
programs. Both software tools and pedagogic examples could be published
~program listings, documentation, designer commentary, and reviews) in
'The Programmer's Corner" of the Newsletter. I could use my facilities
at ANPA to produce camera ready copy of this material. Local nonstandard usage could be clarified in text descriptions. Constructive
criticism from members would be invited.
"The Programmer's Corner" has other benefits besides facilitating
the sharing of programs. Good technique and compliance to standards
would be encouraged. A new outlet for programmer/user ideas would be
opened. Software tool distribution would be furthered by encouraging
implementers/distributers to include the published programs on PASCAL
distribution tapes. The tools would also form a good test base for
implementors.
My personal interest in this stems from my great disappOintment in
the dropping of the Algorithms Section from Communications of the ACM.
"The Programmer's Corner" offers a way to restore program and algorithm
design to its rightful preeminent place in our profession.

I can see two disadvantages to this approach. First, it will take
time before a thorough set of tools is published and, secondly, valuable

AMERICAN NEWSPAPER PUBLISHERS ASSOCIATION I RESEARCH INSTITUTE

space in the already crowded Newsletter will be used. To the first
objection I respond that a continually grOWing, universally available
software set offers significant advantages. To the second I offer the
following method for increaSing the available space in the Newsletter.
First, we set up an abbreviation scheme. E.g., SA: slow arrays,
DA il dynamic arrays, DF!! direct access files, FlO.!!. formatted input/output,
etc. Letters from dissidents could then be ti~htly compressed for
publication. "w/o FlO & DF, PU & WNRF: MH/ABT could be the concise
representation of "Dear Andy, Without formatted I/O and direct access
files, PASCAL is useless and will never replace FORTRAN.
"

:z
rn

:e::
U)

Incidentally my own experience over the last five years with
students who have learned to program using PASCAL is that if they go
into a non-PASCAL environment, they quickly become an importer or
implementer of PASCAL. In their minds, neither FORTRAN, COBOL, nor
PL/I will ever replace PASCAL.
One final word about "The Programmer's Corner" idea. It seems to
me that as our organization matures member interest will shift from
implementation discussions to applications. I, therefore, look for the
Newsletter to soon begin reflecting this change and membership to grow
even faster because of it.

nZJ:lY'

~R1chard
J. Cichelli
Research Manager
Computer Applications Department
Co-director, Computer Science Group
Department of Mathematics
Lehigh UniverSity

(* Editor's Note: I reacted negatively to this proposal at first, especially
beca~se of space :onsiderations and who would judge what programs would be
publlshed. But R1Ch phoned me and talked me into it - provided he edit the
section; he's really right that we should involve the interest of users much
more than we have. It's been mostly implementors so far. Beginning with
next issue (~ascal News #11), we should have some programs (mostly software
tools) to prlnt. See also the second page of Mike Ball's letter for his views
on portable program exchange. *)

U)

rn
"1:l

-l

rn

16 June 1977
Mr Andy Mickel
University Computer Center
University of Minnesota
Minneapolis, MN 55455
Dear Andy
Enclosed is a check for my membership renewal for the next year.
Please change my address to:
Michael S. Ba11
Code 632
Naval Ocean Systems Center
San Diego, CA 92152
This is a change of address due to a local reorganization.
I am currently hard at work an the concurrent and sequential
Pascal compilers for the Interdata 8/32.
The past few months
were spent on the design of the Kernel and compiler changes,
so I had very little time to worry about anything. else. We
.
have an innitial operation date 6f 15 July, so thlngs are comlng
to a head.
It will not be available for distribution for at
least several months.
The Univac 1100 compiler is seeing increasing local use, and
there are 24 known copies in the field.
There are 11 at
universities, 4 at government installations, and the rest in
industry.
I have no data on the amount of use except at a few
of the installations.
I was interested in the "standard extensions" to Pascal.
I would
like to suggest that these be limited to those which can.be
translated easily into equivalent standard Pascal. For lnstance,
Dynamic arrays can be used in ways which are much more difficult
to translate than can parameter arrays. Other extensions should
be limited to additional standard procedures, and prehaps minor
changes to highly system dependent actions such as file
. .
declarations. This limitation should increase program portablilty,
while at the same time providing the convenience and added
efficiency which seems to be the motivation behind most of
the suggested improvements.
Along that line, I would like to suggest that a standard syntax
be specified for external and other language subroutine
declarations. The implementation is of course highly machine
dependent, but a uniform syntax would ease transfer pains.

While on the subject of extensions, I heard from Jim Shores that
you have a proposed extension for initialization which Wirth liked.
If this is in shape for use, I wduld like a copy of this, since
the initialization of tables is an area of considerable inefficiency
in many programs.
I would also like to urge the creation of a standard editing
procedure and distribution format for Pascal programs, since
in my experience much of the trouble in transporting programs
comes in incorporating corrections, and then later in merging
corrections with the inevitable local modifications.
Something
similar to Bell Lab's source code control system might provide
a reasonable approach. The first job, of course, is to decide
what features are needed, and what can be implemented in a
portable manner.
I would like to suggest the following list of
features as a starting point.
1. The standard should include the full ASCII character set,
but all programs should be case independent, so that they can
be translated to an upper-case subset without harm.
2.
Card length restrictions should be followed, since many
operating systems work in card images.
Serial numbers should
be optional.
3.
Corrections should include enough redundancy (prehaps an
alphabetic checksum of some sort) so that corrections which are
transmitted on paper have a reasonable chance of surviving the
keypunching experience.
4.
The system should provide the ability to add local changes
with the local editor, then merge these corrections with new
corrections from the distributer (a down-date procedure).
5.
The programs which implement this should be implementable
with the subset Pascals which are frequently the first step in
a bootstrap.
In particular, as few files as possible should be
used.
More specific suggestions are easy tQ generate.
We are intending to implement some form of source code control
system for our own use, and if there is interest in this, we
will take the extra trouble to make it portable and generally
useful.
Lets here from athers on the subject.
I am sure that
I am not the only one tired of simulating other systems'
editors by hand.
<:J

yours,

J>
G>

fT1

Mike Ba11

U1
C>

incorporating Sir George Williams University and Loyola of Montreal

I:j!j 1455 de Maisonneuve Blvd. West
Montreal, Quebec H3G 1 M8

o

then the first READ would find 123 and the next would fail, which
might be confusing. !qe could insist that the item be followed by
a blank, but this has obvious problems too.
For example, a program
reading expressions would accept 123 +456 but not 123+ 456.
The method extends naturally to user defined scalars and (note!)
subranges. This is important, because I think that it would be
pointless to extend PASCAL in such a way that scalars could be read
but entering FLASE instead of FALSE causes a fatal run-time error.

7141 Sherbrooke Street West
Montreal, Quebec H4B 1 R6

Tel. 514-879-4251
June 16, 1977
PASCAL User's Group
c/o Andy Mickel
UCC:227 Exp. Engr.
University of Minnesota
Minneapolis, MN 55455

The programmer still has to provide an error recovery routine.
For an interactive program, there is no problem: issue a diagnostic
and cue for corrected data. For a batch program the easy way out
is to READLN, leaving the user to spot further errors on the same
line.
In a specific application, however, it is often possible to
design a more sophisticated error recovery procedure which takes
reasonably intelligent action.
The PASCAL Newsletter is doing a fine job.

Keep it up!

Dear Andy,
The merit of PASCAL is its simplicity.
It is reasonable to
expect a competent PASCAL programmer to correctly predict the effect
of any well-constructed PASCAL statement, which is more than can be
said of certain other programming languages.
In attempting to
standardize PASCAL we should attempt to tidy up loose ends, not to
incorporate fancy features. When we have to extend the language, we
should preserve the spirit of the initial design.
Everyone has their own ideas about what the most important
defects of PASCAL are. My own pet grievance is the P~AD statement
used to perform automatic conversion from character string to
INTEGER or REAL. No user will accept a program which collapses when
it encounters an unexpected character in the input stream, and no
programmer wants to incorporate conversion procedures into every
program he writes. Therefore, READ must have an error exit, and the
problem is how to provide it in a clean way. The solution should
be compatible with the existing READ, so that simple-minded
conversion is available for toy programs and novice programmers.
I tentatively propose the fOllowing: the READ statement should
accept an actual parameter whose type is RECORD. The record must
contain two fields, one scalar or REAL, and the other BOOLEAN.
For example:
VAR

ITEM: RECORD
DATUM: SCALARTYPE;
FOUND: BOOLEAN
END;

After executing READ (FILENAME, ITEM) either ITEM. FOUND = TRUE and
ITEM. DATUM has the appropriate value or ITEM. FOUND = FALSE and
ITEM. DATUM is undefined.
In the first case, the file pointer will
have been advanced past the item read, and in the second the file
pointer will be unchanged, except that leading blanks and blank
lines will have be~ skipped. If we have formatted input, then
the pointer woul~~be advanced over the indicated field width in either
case, and the program would not get a second chance to read the item.
If SCLARTYPE is INTEGER and the input stream contains

AA

the string

(/)

rn
""0

-I

rn

:::s:
t::O

rn

THE UNIVERSITY OF TEXAS AT AUSTIN
AUSTIN, TEXAS

Complltalion Center
512/471-7242

June 24, 1977
Dear Andy:
Since it's renewal time, I thought it would be appropriate to bring you

up to date on PASCAL related happenings here at UT.
The best news is that we finally got confirmation that the new version

of DEC-lO PASCAL has in fact made i t to the U. S. and DECUS. This confirmation came in the form of a copy of the files for a test installation
from Carl Perkins of DEC to whom we had supplied the old version of
PASCAL. He informed us that he would be the official DEC US submittor.
We have the new version up and in reasonable shape.

The biggest problem

with it is that all programs that ran with the old version have to be
changed.
On the
job in
PASCAL
PASCAL

Control Data side of things, Wilhelm Burger has left UT to take a
Washington, D.C. Tom Keel of our staff is now looking after the
system. We are looking at installing your efficiency mods from the
Newsletter #5. Another programmer made a good start on a PASCAL

interactive debugger this past semester.

123J5

;;0

78712

V1

f->

Let me turn now to the question of standardization which has been debated
so thoroughly in the PN issues of the past year. It appears from the information in PH DB that the U. S. standardization process is not well understood. I enclose a copy of a presentation made at VIM.23 by Meredith
Speers which describes the process quite well. A careful r~view of the
process will reveal that it is an extremely expensive and t1mS consuming
process. The effort in shepherding the proposal for a standard through
SPARC is considerable. I would estimate that it would take a year and
about $35,000. counting personnel support to get a technical committee set
up. A conscientious effort could shorten this time frame, but I doubt it.
Once the technical committee is established I suspect at least 12 to 18 months
will be required to formulate an acceptable standard. Assuming quarterly
meetings, th:Ls translates to 4 to 6 meetings. This estimate assumes a 20
to 25 person technical committee. As you point out in PN 1ffl, the technical
committee is critical to the formulation of a standard and I doubt that the
canvas approach will work with PASCAL given the acknowledged weak spots in
both the Report and Manual.
The technical committee under Xl rules is a volunteer organization with
strong continuing attendance requirements to assure a body of expertise
behind the proposed standard. GivEllthe strong interest in a standard expressed within PUG, I would expect a technical committee of 20 to 25 sufficiently committed volunteers could produce a standard in 12 to 18 months.
The most difficult part, as you point out, would be to control extensions
to the language.
If the effort through BSI does in fact result in a proposed ISO standard,
then SPARC will almost certainly set up an Xl PASCAL technical committee.
Consequently, I think that a u.S. XlJ committee for PASCAL is probably
inevitable and PUG should probably take the leadership in establishing
such a committee.
Enclosed is my renewal check.

Keep up the good work!
Sincerely,

4J AUL/

wald~~edel,

Manager
Programming Services

WMW:mp
Enclosures

(* Editor's Note:

Wally is a member of the ANSI X3J2 Basic Standards
Committee. I replied to Wally in a quick note dated 77/06/27 th~t:
"I guess the point is that we don't want an ANSI standard that dlffers
from an ISO standard. We are not going to go for an ANSI standard
because it takes too much timeand energy." I mi ght now add that
after there is an ISO standard, ANSI should adopt it as a matter of
course. *)

UNIVERSITY COMPUTING CENTER
,!JNIVERSITY OF COLORADO
eOUL..DER. COLORADO 60309

22 July 1977

Mr. Andy Mickel
University Computer Center
227 Exp. Engineering Building
University of Minnesota
Minneapolis, MN 55455
Dear Andy:
Please
academic year
to you, John,
exceptionally

find enclosed my membership for the next
for the Pascal User's Group. And congratulations
and the others for producing four newsletters of
high quality. Keep up the good work.

After reading Newsletter i8 and listening to CDC present
their future plans, I agree with your position that now is the
time to formalize the definition of Standard Pascal by cleaning
up the semantic definition and making relatively few extensions
to the syntax. The important syntactical changes should include
dynamic arrays, value initialization (including arrays and
records), strict procedure parameter ·type checking and case
statement alternative.
I don '.t expect to see the bulk of my proposals in Newsletter i8 implemented in Standard Pascal. I believe the best
route for implementing extensions to PASCAL is to build a preprocessor (written in Standard Pascal) to translate extended
Pascal to Standard Pascal. Such a processor is truly portable
and essentially changes the compiler into a two-pass system.

en
rn
-c
-I

rn
:;;:
o:J

rn
:;c

....w

......
......

Our distribution mechanism is operating efficiently with
less than one week turnaround (except for vacations).
Karin Bruce and Michele Dowd are doing a good job. I've enclosed
some of our recently developed material. Karin feels it would be
more expedient to drop the option of letting the buyer supply the
tape and incorporate the cost of a tape into the minimum cost.
I concur with this idea. Do you have an opinion on this change?

*****
-0

:l:>
~

Richmond

rn
I.TI
N

The University of Calgary
292024 AVE. N.W.

I; I-I:OJ

DEPARTMENT OF COMPUTER SCIENCE
TElEPHONE: (403) 284-6316

CALGARY, CANADA
®

Network Services, Inc.
175 Jackson Plaza
Ann Arbor, Michigan 48106
(313) 769·6800

T2N 1N4

77-07-29
Dear Andy,
Enclosed is my renewal; if I've missed P.N. #9, would you send

July 28, 1977

me a copy?

Mr. Andy r·1ickel
Editor, Pascal User's Group
University Computer Center227 Experimental Engineering Bldg.
Minneapolis, Minnesota 55455

I really stand in awe of the job you've done in publishing the
P.N.; nevertheless, I hereby add to your burden with the following.
If Pascal is to compete with Fortran, I believe four things are

needed which I have not seen discussed as a unit in the Pascal Newsletter
so far; hence, this letter.

Dear Andy:
Before I go on, I should point out that all the possibilities

I thought your readers might like to know that we have an
interesting PASCAL project in progress and that there are
PASCAL related positions available here in Ann Arbor.

discussed here can be inserted into the Pascal language without much
syntactic change.

Better still, efficient one-pass compilation of these

features is still possible, Fortran being a weak demonstration of the
fact, another being found in an M.Sc. thesis which discusses these and

ADP Network Services currently operates more than fifteen
DECSystem-10's on an international communications network
and we have the need to develop a systems implementation
language to support language, monitor and other software
development for DEC-IO's and other hardware that may be
attached to our network as our company grows. PASCAL has
been chosen as the base for this language. We have embarked
on a jOint project with Al Kortesoja of Manufacturing Data
Systems Inc., also of Ann Arbor, to develop language and
code generation features that will provide us \vith a general
implementation language that will generate good code for a
variety of machines.
We began ~ith ~he DECSystem-lO compiler developed by H. Nagel
of the UnLversLty of Hamburg and are modifying it to include:
random 10 facilities; flexible length arrays; constant arrays
and records, an exception handling facility, functions which
re~urn arrays, records and sets; and STRING handling.
Through
t~LS we have endeavored to maintain the coherence and compile
tLme checking capabilities originally designed into PASCAL
by Professor Wirth.
We, ADP Network Services and MDSI, have a variety of positions
open in the areas of PASCAL compiler development, systems
programming, and applications development using our PASCAL.
I would be pleased to receive any resumes your readers would
like to send and would see that they are properly considered
by 111:. Kortesoja and myself.

many other interesting possibilities, "Pyxis: A language Evolved from
Pascal" by E. N. Kittlitzt Department Computer Science, University of

Calgary, 1977. (The author may be contacted via that department, Calgary,
Alberta, Canada T2N lN4.)
First, concerning storage mapping: I join the cry for a variable
initialization facility, which in turn implies a certain amount of

statically allocated storage.
Second, storage could be explicitly allocated as static either
in common blocks or as "private" areas for given procedures or fUBctions.
Then one has the possibility of Pascal subroutines that do not use the
run-time stack and so could be loaded with and called by a Fortran main

program.

A second benefit that I find personally more important is that

one could then program more modularly, no longer having to use unprotected

globals to implement the Algol own.
Third t there is the need for flexible array parameters; I don't

suppose that is debatable any more. Of course, one must distinguish between
flexible array parameters and "rubber" dynamically-allocated arrays. It
strikes me as not in the spirit of Pascal to admit rubber arraYSt nor would
rubber arrays be at all necessary from the view of Pascal as a Fortran-

replacement.
The flex array facility of Pyxis has merit; for example, it
costs nothing if you don't use it. The following is a Pyxis program
fragment which prints the sums of the two 6-element vectors.
Flexvec = array [1 to *] of real;
var A: array [5 to 10] of real;
B: array [-3 to 2] of real;
function Sumvec(X: Flexvec): real;

~

Sincerely,

~~~

Manager, Programming Languages

var I:
- - S:

integer;
real;
begin S := 0;

for I := 1 to UPB(X)
do S :=S+X[I];
return S

NJB/kjs

end·--begin (;initialize values*);
write(Sumvec(A), Sumvec(B»
end

en
rn
-0

-l

rn
3:
t>:l

rn
:::0

Pyxis also allows one to allocate flex-typed objects of run-timespecified size to the heap, and to have a pointer which may reference any
object of a given flex type, i.e. an object of a type which falls within the
class of types specified by a flex type declaration.
The fourth point involves the great format debate, and variant
records too., I think people are not thinking straight about these issue,s.
A text file is not a string, nor a sequence - not even one of indeterminate
length!

It has funny states, e.g. the "not-opened" state; even an abstract

model of a file does odd things. In Pyxis, a program interacts with a file
(which is "outside" the program) via its image (which is a record of status
information with a string acting as a buffer); a string is a fixed-length
packed array of characters, in the Pascal sense. Thus, format operations
become type coercions changing various simple data types into short strings
and vice-versa; the analogy with integer-to-real coercion is quite good, and

SPECIAL TOPIC: MICRO/PERSONAL COMPUTERS AND PASCAL
the following four letters deal with some developments described on page two of the
EDITOR'S CONTRIBUTION. See also the IMPLEMENTATION NOTES section under INTEL 8080, LSI-II
Motorola 6800, etc. And also see HERE AND THERE News section under Kenneth Bowles Kurt
Cockrum, John Colli~s, Creative Computing, Jack, Crone, Dan Fylstra, Roger Gulbrans~n,
C~rl Helmers, Sam Hllls, Aro~ K. Insinga, Bafbara I. Karkutt, Ed Keith, Donald Lindsay,
Tlm L. L?wery, ~ruce Mackenzle, Jim McCord, Carlton Mills, Carol Anne Ogdin, David Segal,
Bruce Seller, Mlchael Settle, Jeffrey G. Shaw, David H. Welch, and Richard West!

format operations are no longer the perquisite of the file handling package.

Of course, not all the foregoing viewpoint fits well with Pascal,
but some fair amount does, and is worth considering. Assuming a good type
coercion syntax can be designed, format operations could simply be functions
which accept or return flexible arrays of characters, and their use in I/O
becomes natural without being their only use. Further, if you do not use these
functions, they need not consume space in your load module.
The tie-in with variant records should be clear. Variant records
are used for two totally distinct and completely valid reasons. The first
is that which they were designed for; the second is to pun: One must write
one's own "dispose"; one needs to dump large list structures; and for a myriad

of other purposes a programmer sometimes needs to get at the bits, do arithmetic
on pointers and the like.

Although these activities are machine dependent

they are not dirty; because they must be done with great care, they must be
done in a good language; and because they are so universally necessary, they
ought to be accommodated in the language in a clear machine-independent way.
Rather than continuing the abuse of the variant record, let the
job be done by a syntax designed for the purpose. To this end, I favor the
common idea of allowing a  to be used as a 

such that if its (one) argument is of a suitable type, a pun is allowed
or, in certain specified cases, a coercion occurs. A suitable type for
punning would normally be a type requiring the same storage as that which
one is "punning it into"; and if the user doesn't know his implementation
well enough to do what is required, he's still better off with the resulting
error message than with the current "guess and hope" method required by
variant records.
In summary, I hope most for variable initialization, private (own)
variables, flexible array parameters (but not rubber arrays), and a view of
type coercion to solve both formatting and variant-record problems.
Killing Fortran was presented as a motivation; more precisely
I want a strong, viable language so I won't have to reprogram soon. I've
done a lot of work in Pascal, in part because I hope that with just a
little more strength of expression Pascal will survive; but I also believe
that without that strength, it won't.
Very truly yours,

Stephen Soule,
Assistant Professor
SS:tah

104B Oakhurst Circle
Charlottesville VA 22903
8 July 1977
Andy Mickel, Editor
Pascal Newsletter
University Computer Center
227 Exp Engr
University of Minnesota
Minneapolis, MN 55455
Dear Mr. Mickel:
(1) I have received a reply from Dean Brown at Zilog about the hypothetical
Pascal machine. Zilog is not describing the machine to the public at this time--see
enclosed copy. Perhaps his spontaneous use of the term "Pascal machine" is a hopeful
indication however.
(2) Enclosed please find copies of letters I have sent to Byte, Creative
Computing, Kilobaud and Personal Computing as my one-man campaigo to stamp out BASIC
and increase Pascal's visibility.
(3) Since (judging from PN 8) Pascal will soon be available for personal
computers, it seems to me that a timely collection of Pascal games and hobby programs
might help wean the hobbyists away from BASIC. I personally have been writing Pascal
versions of Star Trek, Mastermind, Lunar Lander and so on. I would like to hear from
anyone in PUG interested in sharing such programs, and also from anyone who could
explain to me the copyright laws concerning Pascal translations of copyrighted BASIC
programs.
(4) I personally was aghast at the proposal to change variant record usage
(PN 8-15). I think the language designer's responsibility to protect the programmer
from himself stops short of that. Perhaps I have strange tastes, but I like having
access to individual bits of a word by treating the word as a packed array of boolean.
I like being able to declare
var r: record case boolean of false: (x,y,z:integer);
true:(p:arraY) •• 3Jof integer) end;

so that for statements can be used for assignment (for i := 1 to 3 do pli1:~something)
yet clumpsy array notation is avoided in other situations for example:
write(a[x,y,z) instead of write(a[p[l], p[2J, p[3]]).
'
(5) Could someone in PUG e~lain why Pascal's semicolons make Prof. Sales
weep? (PN 8-33)
(6) Congratulations on the Newsletter.

v;::ta-·M
David A. Mundie

en
rr1
-C

--f
rr1

::;;::
0:1
rr1

::::c

SCCSINTERFACE

The International Publication of the
Southern California Computer Society

Box 5429
Santa Monica, California
90405 U.S.A.

(2f3) 396-0048

'J'

r' ~

Aug.

Dear Andy,

Sincerely.

/~~
Larry Press
Editor
P.S. We have an informal system of coordinators for various topics.
Would you mind if I were to list you or PUG as coordinator for Pascal?

I' I'll

Maria Lindsay
Coordinator
5150 Anton Dr
Room 212
Madison, WI 53719

June 27, 1977

Thank you for the copy of your newsletter. I wi 11 put a "short
contribution" extolling it in the next issue, of Interface.
As Steve Legenhausen points out on page two of the newsletter,
BASIC is becoming a microcomputer standard. I am very much interested
in urging our members to consider other languages than BASIC, and would
like to publish anything which would work to that end. An article such
as a Pascal tutorial, a critique of BASIC (control stru~tures, data
types, etc.), a Pascal bibliography, a survey of micro-based Pascal
activity, or a Pascal subset proposal, would be most valuable for our
readers.
If you or any'PUG members would be up for writing or compiling
material along these lines, I would love to publish it. Like yours, our
format is quite flexible, with room for short contributions as well as
longer articles.

t,

1. 1977

t::: Pascal User's Group
........ c/o Andy Mickel
University Computer Center
227 Exp Eng.

o "'I,.\I~''S t.~>,

~5- (Y\l\i\.V\e~2+-e....,

h-''''V\"'-''f'~(I.ter al you have
managed to compile and publisn.
In reference to my earlier offer to help promote PASCAL, you mentioned
"pr~ssing
our advantage in the microprocessor area", through articles and
letters to such magazines and journals as Dr.. DQbb'~,~, tgrsonal ~
~ CrE!tiye ~~~puti~ etc.
While I'a-be-gIad .0 swamp
ese and ~
erpijl)hca ons,w
pr07 ASCAL material, I really can't "press" any "ad_
vantage" because, frankly, we have none" -- yet. As of today. I know of no
reasonably-priced, memory-efficient generally available implementation of
PASCAL {or a deaent subset}, in compiler OR interpreter form, suitable for
use on any of the popular micros, with the dubious exception of the LSI-11,
which has itself only become inexpensively available through the still
brand-new Heath computer line.
Having an "advantage" entails for me. two considerations.
First. one's
product or service must be in~erently superior to its competition. Secondly, it must be ayailaRle and ~lQ use. PASCAL certainly is a superior
language, perhaps t e worthiest ITVi yet encountered (despite its many
flaws wnich I hope will be truly CORRECTED, and not merely "written
around"}.
However, the availability of a powerful, easy-to-use microPASCAL remains nil, and so our "advantage" remains merely a tantalizin~
phentom.
For the average micro-user. PASCAL iS l and will remain, ·unreal
until someone comes up with an implementation wh ch iS from both aesthetic
and practical standpoints, more attractive than the al t ernatives BASIC and
FORTRAN. {Mioro-l>ASC~L w111 have to be "more -attractive", of course, in
order to lure away the vast majority of satisfied BASIC and FORTRAN haok~
@nd give them proper cause to learn and embrace a strange new ·language.}
I've been reading about the UCSD PASCAL project, and I'm filled with hope
that, finally, I will be able to show my d0M:~~~ friends and customers
some.hing more than the {often confusing} .IlScr
.lIIl!1~.
Perhaps
I will be able to demonstrate a working compIrer or nterp~ as well as
the superiority of PASCAL as a programming tool. The moral victory would
be even sweeter if I could point to simultaneously_available IDENTICAL ver_
sions of the language optimIzed for the LSI 11, Z80, 8080 and 65021
Any.
way, until I liear more from La Jolla, the emergence of PASCAL into the
micro-age is still my pipe dream.
Regarding media exposure for PASCAL, though, I am all for it, and suggest
th~
formation of a steering or co-ordina.ion committee to manage a media
blitz to awaken the personal computing oommunity to the advantages and joys
of PASCAL prOgrammi~. What do you tnink? I have noticed too many APL ar-

110

(* Editor's Note: I replied to Jim in a quick letter dated 77/08/31:
" ••• My basic problem is time, and the hasty note I scribbled last time
to you did contain some hazy thoughts. What I meant by 'pressing our
advantage' was literally that in the 5 years I've been involved with
Pascal, there were no areas where we had a chance to shine and the doomsayers
were pretty explfcit about us keeping in our place. But ·because microprocs/
personal computers are relatively new, there's a much less powerful
establishment to overthrow. So relatively speaking Pascal pproc developments
seemed to me further along than other fronts &that we should concentrate
energy there (press). Oh well, I should have originally said 'enlarge
the opening.'
'I agree about .the APl problem. It upsets me a great deal.
"Regarding other fronts, I consider that we haven't and shouldn't yet take
one080l, and that Pascal .vs. FORTRAN is the front I've been involved with.
"Other fronts are of course getting manufacturers just to support Pascal
processors 1n their software line, and getting stuck up computer science
departments to teach the stuff.
"I appreciate your offer of help and am glad you liked the newsletters.
liThe spirit of PUG so far has been its far-sighted inability to form working
cOlllllittees - just loose unions .... " *)

~~~~it.~og~i~~ XBLlglit~'~i~~:~ef~o~~r ~;t~~~o~;tyc~:ng:eni~or:~~k~~~

is calling the shots. In either case, we'd better get something together
if we intend to make any dent in tne personal comguting. sector. APL. as
~~f~~l~ t~ !~ ~~~. s w:g~lo~t ~OOd language, and coul very well bury us by

t

Finally,'in ~ #8 {I think}. you expressed interest in getting

JiM MERRiTT

POBox46~~

BERkElEY CA 94704
PhoNE 41~-84~-4866

informa-

""CI

l>

en
I'TI

V1

en

FROM

Andy Mickel
Editor, Pascal Newsletter
University of Minnesota
227 Experimental Eng. Bldg.
Minneapolis, Minnesota 55455

TO:

THE
EOITOR'S
DESK

September 6, 1977

Dear Andy,
Finally getting around to a detailed reading of PUG.' Newsletter #8 pro-

vides me with a theme for an editorial I will put into the December 1977,
pushing PASCAL as a possible language. I picked up several Springer-Verlag
books at IFIPS last month and have since spent some time discussing PASCAL
with my good friend and associate Dan Fylstra.
I think that PASCAL would make an excellent choice as a successor to
BASIC in the personal computing world, a thought which is echoed by several
contributors to PUGN #8. Here are two points about PASCAL Personal Computing
Use which will no doubt appear in the editorial I am composing this week:
Like BASIC, PASCAL is an academicly originated language with a
fairly well defined set of machine independent standards. As such
it has one major point in its favor: it is not a proprietary product confined to anyone organization, and is thus open to the
general computing public as a standard to be implemented and
delivered with machines. Thinking of the general public as users
requires a machine independent (or nearly so) language, and in the
interests of better software techniques a structured language like
PASCAL comes to mind. The large amount of activity evidenced by
PUGN suggests that both the academic training and wide usage which
were present in BASIC's evolution will also be available with PASCAL.
When implemented for the personal computing millieu, PASCAL
should at a minimum level of function offer an interpretive or
semi-compiled interactive system which is friendly to the user in
the same way that BASIC is friendly. Fully compiled and optimized
code generation is not needed in a context where one high speed
processor is dedicated to each user and his or her files.

As a final point in closing, we (BYTE Publications) are in the process
of preparing a series of publications initially oriented to systems software books characterized by tutorial documentation of the design, complete
publication of source code and any necessary intermediates, machine readable
representations of the source of object text, and other information
relevant to the process of getting the particular software item running
in the user's personal system.
(Where machine dependence is involved,
we are looking for target machines which are in the following set:
LSI-II, 6800, 6502, 8080, Z-80.)

I would be most interested in talking with readers of PUGN who have
implementations of PASCAL available for sale which run interpretively,
semi-interpretively or as compilers. Our standard form of publication
agreement is an exclusive book and audio record publishing license
to the software and its machine readable representations.
I'll send a copy of the editorial after it is written.

tlr;~

Carl T. Helmers
Editor in Chief
Byte Publications, Inc.

C/)

rn
-0
-i

rn

SPECIAL TOPIC: PASCAL STANDARDS

6.2.1

In Pascal Newsletter #8, we devoted many pages to a series of letters about standards.
Among the actions described as being taken were: 1) we try to clarify instances of vague
semantics in the Pascal Revised Report, and 2) Tony Addyman of the University of Manchester
coordinate an effort to get an ISO standard certified which would amount to a tightened up'
Revised Report,with no additions.
This summer, Tony phoned that:
1) he had received another list of points requlrlng clarification from Jim Welsh in Belfast.
2) he wondered if there would be copyright problems with the current Revised Report already
published and the proposed standards document.
3) he was very pleased that the June meeting of a British Standards Institute (BSI)
committee on programming languages (of which he is a member) authorized a working group
(headed by himself) for a Pascal standard. This is for the purpose of certifying a
document as a standard, not to propose additions and changes to the language.
4) he envisions an appendix to the Report which would both suggest various strategies
for things left to be defined by an implementation and list conventionalized extensions.
I sent him a small list of items which included:
1) Optional; on last limb of a case.
2) Role of the word-symbols: extern, forward, and fortran (all non-standard) but in
various implementations they are neither predefined, reserved,nor user-declared.
3) Many good definitions in the Axiomatic Definition don't appear in the Report. For
example (brought to my attention by Charles Hedrick): the Report specifies the mod
operator as the operation: "modulus." But the mathematical meaning of modulus gives
things like: -3 mod 2 ; 1. The Axiomatic Definition clearly states -3 mod 2 ; -1.

(a)

Is array [integ~r] of real legal??
Note that
 ::=  , and
 ::= •.
.

I .. I

(b)

~ 1'1 ;

array [0 .. 9] of array [Boolean] of integer;
T2 = array [0 .. 9, Boolean] of integer;

~

Al:Tl;

A2:T2i

Are Tl and T2 identical types?
(Assuming that "identical
types" means more than having the same type identifier.)
Specifically, is it legitimate to write Al [S,trueJ or
A2[S][true]?
(cf. Ul1-6, p39)
6.2.2

n.1

On 77/08/17 I received a note from PUG member D. G. Burnett-Hall dated 77/08/10
which read: "Dear Andy,
I enclose ~nother Attention List' following Tony Addyman's
Attention ,List in Newsletter 8: I've tried to avoid duplicating
his points (and I've sent him a copy)." ...
8.1.2

(a)

Field identifiers within a record must be distinct,
taking all varia~ts of the record into account (UM-7,p46).
But one identifier can be used simultaneously as a field
identifier and the identifier of a variable (say) (UM-7,p49).

(b)

Helpful if last example included an empty field list (UH-7,
p46).
(*E.g.
include POINT; in type SHAPE: also in
exa~ple at end of R6.3.*)

(c)

Why is the conjUllction of ;end
(i)
illegal in the declaration record ... case ••• ;end , but
(ii) legal in the statement case~end ?--{R9.2.2.2)
(*DEC-l¢ compiler rejects i t in both instances.*)

This should include something along the lines of UM-4A (p21)
(and UM-IO, p63/64) about whether compo~~d Boolean expressions
are completely evaluated.
(*It would change the language
to say now tha-t they are evaluated only as far as necessary,
but I wish this had been done.
So did the author of
SKIPBLANKS (UH-12A,p85) which is only dubiously legal. *)

(a)

14 div{-3) is not defined anywhere!

(b)

mod operator is defined (in terms of div) only in
UM-2B (pI3).

Is i t -4 or -5?

::z
rn
:::E:
C/)

C/)

rn
-0

-i

rn
3:
Cd

rn
:::c

Another Attention List
D. G. Burnett-Hall

U N I V E R SIT Y

o

8.1.4
F

Y 0 R K

1977 August 9

(In-) Equality operators for sets?
(UH-8,pSO).
More
obvious than the set-inclusion operators the Report does
describe.

DEPARTMENT or' COMPUTER SCIENCE
9.1.1

Consider also:
R4 = record
case B : Boolean of
false: (I :integer);
true : (R:real)

~

4

6.1.1

(a)

Add IIprograms" to first sentence.

(b)

Is

II

an illegal constant?

(n

=0

characters not

defined~)

var X,Y,Z:R4;
(*Integer and real quantities need not be the same size*)
X.B :; false; Y.B := false;
Z.B:= true;
X.I :; 1;
Y.l := 2;
Z.R :; 3.4;
X := Y;
(*Presumably their types are,identical~)
X : ; Z;
(*Legal?? Are their types identical?*)
(*Does this imply a run-time check?*)

1'1; (ZERO,ONE); T2; (ONE,TWO);
should be illegal because the type of ONE is ambiguous
(UM-5A,p34)

~

6.), 2

For Boolean type, better to make clear here that it is ordered
(false; true) than just a note in 8.1.4.

6.1.3

Allows lower; upper band for subrange type:
not.
(Why?)

en
rn
9.1.2

UM-5B(p3S) does

-0

:P

UM-1LA (p71) says that if
procedure P (var X,Y:integer);
is declared, the procedure statement
P(A,A)
is illegal (flxl
•. xn should be distinct variables").

\Jl
00

Why?

9.1. 3

9.2.2

(a)

Doesn't forbid duplicate use of one label in the same block!

(b)

procedure P,
label 99;
procedure Q; begin .......... ; 99: ......... end (*Q*);
begin (*P*) ••.•. ; go to 99, •.. end (*P*): - R.9.1.3.1 does not require label 99 to be in Q, thus
contradicting its second sentence.
In R9.1.3.2, should
"procedure ll be replaced by II innermost procedure, function
or program"?

(a)

(i.e. the file ends with the end-of-line marker or is empty?)
If not, the program schemata in UM-9A2. 9A3 (p58/59) will fail.
This assumption would considerably simplify input of data (try
rewriting UN-9A2 if eaf can occur at any moment!) and would be
easily implemented in the run-time system.
Perhaps this should
be answered in R14?

12.1. 4

(a)

All the case labels within one case statement must be

(cf r:=+2)?

distinct (UM-402, p31).
(b)

One of the examples should include a list of case labels.

(e)

A case label cannot be used as the destination of a gato
statement.
(This is implicit, but it would be helpful to
make it explicit.)
In the final example, i t is very
tempting to write:
1:

9.2.3.3

(a)

begin. x := x- pi/2;

(b)

10

(a)

(b)

-- is it illegal to give real datum for integer variable
(cf i:=-13.4)?
{*DEC-l¢ system rejects both:
the first is unhelpful and
unnecessary. *}
(b)

\..;'hen read

(c)

What terminates (i) an integer, (ii) a real n~~er?
Does end-of-file terminate an otherwise valid nQ~er?
(*My suggestion under 12 \-10uld remove this possibility*)

goto 2 end;

Never says that tht, statement S \vill not bE' obeyed

if el>e2 (to) or el , for that matter?)
If one can reset (F)
for a textfile F to re-read its data, why not for INPUT?
(*DEe-l~ system allows them:
chiefly because DEe-l~ operating
system expects matching of internal and external filenames to
be done at run-time and not by JCL commands, worse luck!*)

(a)

type of argument must exclude real.

Can one assume, when reading ~ textfile F, that eof(F) becomes
true only (i) after readln (f) or (ii) immediately, on reset (F)?

(b)

This section should include a list of those implementationdependent constants whose values are needed when a program
is being transported.
e.g. MAXINT (m~-2B, p13"but not in
Report), maximum size of a set, default values of M in write
(E:M) for integral and real E, etc.
(*Should these be
standard constant identifiers?
I favour a limited number
of environment enquiries, c.f~ Algol 68*)
A compiler-option takes the form of a comment whose first
character is $.
(*That much, pace N. Wirth, but no more.
Itensures that one can put comments in portable programs
which won't accidentally be taken as compiler options.*)

""Cl

::r:>
G"l

rn
IJl
LD

Implementation Notes
GENERAL IN FOR MAT I ON
As this is the first issue of Pascal News in this academic year July I, 1977
30, 197B, let us explain how this section is organized:

CHECKLIS T

C H E C K LIS T

CHECKLIS T

C H E C K LIS T

-- First a CHECKLIST to
maintainers for reporting

be
the

June

used as a guide to distributors, implementors and
status

of

Pascal

implementations

on

various

computer systems.

1.

DISTRIBUTOR/IMPLEMENTOR/MAINTAINER
(* Names, addres-ses, phone numbers. *)

2.

-- A SOFTWARE
applications.

MACHINE
(* !lanufacturer, model/series and equivalents. *)

TOOLS

section

describing

aids

to

Pascal

users in developing

-- A PORTABLE PASCALs section reporting distribution information about kits

used

to produce Pascal compilers for real computer systems.

3.

SYSTEM CONFIGURATION
(* operating system, minimum hardware, etc. *)

4.

DISTRIBUTION
(* cost, magnetic tape formats, etc. *)

5.

DOCUMENTATION
(* In form of supplement
Machine retrievable? *)

to Pascal

~

Manual and Report?

6.

MAINTENANCE POLICY
(* How long? Accept bug reports? Future development plans. *)

7.

STANDARD
(* Implements full standard? Why not? What is different? *)

B.

MEASUREMENTS
(* -compilation speed (in characters/sec. please; this is a
meaningful measurement for compilation speed);
-compilation space (memory required at compilation time);
-execution speed;
-execution space

(the

memory required at execution time;

compactness of object code produced by the compiler);

** Try to compare these measurements

to

the

other

language

processors on the machine, e.g., FORTRAN. *)
9.

RELIABILITY
(* stability of system (poor, moderate, good, excellent);
how many sites are using it?
when was the system first released to these sites? *)

10. DEVELOPMENT METHOD
(* Compiler or interpreter? Developed from Pascal-P / handcoded from scratch/bootstrapped/cross-Compiled/etc.? What
language? Length in source lines? Effort to implement in
person-months? Previous experience of implementors? *)
11. LIBRARY SUPPORT
(* Libraries
of
subprograms
available?
Facilities for
external and FORTRAN (or other
language)
procedures
available? Easily linked? Separate compilation available?
Automatic

available?

copy

of

text

from library into source program

Symbolic dumps available? *)

..
•.
•..
••.
•..
..
•.

-- Information on PASCAL VARIANTS •
-- A FEATURE IMPLEMENTATION NOTES section describing implementation strategies
and detsils of various Pascal features as suggestions to all the compiler
implementation efforts underway.
--A list of MACHINE DEPENDENT IMPLEMENTATIONS sorted by name of computer system,
giving news of Pascal compilers for real machines •

-- And in subsequent issues
information for this year.

this

year,

an

INDEX

to all the implementation

We are essentially beginning anew this year and so in this issue we are combining
summaries hand-compiled from PUGN's 5-8 (last year) with the news received since #8.

IMPLEMENTORS - 11AINTAINERS - DISTRIBUTORS
Please use the checklist if you are reporting information and please keep us all up
to date. You might also send us a copy of your documentation and distribution forms as so
many implementors have done so that we can keep up to date on the overall development of
Pascal. Please send camera-ready copy, single spaced, and use wide text (we prefer IB.5 cm
lines). We also will accept reports on ASCII paper tape accompanied by a listing. And
please include PUG All-Purpose Coupons with each copy of your system that you send out!

USERS
Please help make us all informed consumers of Standard Pascal systems by reporting
your quantitative and qualitative experiences with particular implementations •

EVERYONE
We would like to thank all the effort put forth by people who have sent in
information. We regret to say that our ability to answer individual requests is limited
not only by time, but by the commitment we have first to this section of the newsletter.
Therefore we prefer to answer inquires through Pascal News. We print all the news that

en

comes to our attention barring oversights and mistakes on our part!

o

The person implementing Pascal has several choices.

SOFTWARE TOOLS
There has been much discussion concerning the distribution of Software Tools written
in Pascal in PUGN 5-8. Please see the letter by Richard J. Cichelli 1n the OPEN FORUM
section this issue. It was our idea that tools should be incorporated with the
distribution of Pascal implementations but even this poses real problems. Starting next
issue we should see news on tools greatly expand.

Examples of software tools are listed below:
1. A program to

~

1£

there

is

no

access

to

a

working Pascal compiler on another machine, the implementor orders a Pascal-P kit already
configured to the target machine. Configured compilers have constants inserted in them to
specify, for example, the size of each simple data type. These configuration parameters
are given by the implementor on the Pascal-P order form. (See below.)
After receiving the kit, the implementor can write an interpreter for P-code in
another language (usually takes about one person-month), and thus immediately has access
to a Pascal compiler running interpretively by using the P-code version of the compiler
included in the kit.
To produce a real Pascal compiler for the target machine then requires editing of the
Pascal-P compiler written in Pascal to produce code for the target machine (instead of the
P-machine). After recompiling, a Pascal compiler exists in the code of the target machine.

reference identifiers in Pascal programs.

If the implementor initially has access to a working Pascal compiler on another
machine, the step of writing a P-co~e interpreter can be omitted.

2. A decompiler to examine the object code produced by a Pascal compiler.
3. A prettyprinter to format and indent Pascal programs.
4. Performance

measurement

programs

to

monitor

execution

times

in

Pascal

programs.
5. A program to change character
6. A program

to

compare

~

- The current version is called Pascal-P4 and is distributed with a copy of Pascal-P3
(which is of interest to previous recipients of Pascal-P2).
- Pascal-P4 represents a major improvement over earlier Pascal-P versions because it

from one to another.

two text files and generate a set of modifications to

convert one to the other.

7. A text editor to slter and record modifications made to a source program.
8. A ~ formatter used to produce

written

documentation

Facts about the Pascal-P compiler:

about

software

for

users.

Believe it or not, right now several different programs exist in categories 1, 4, and
8, and at least one program exists in every category except 7! All are written in PascalI

PORTABLE PASCALS

removes data type alignment restrictions, is more efficient, includes runtime tests, and
1s a more complete implementation of Pascal.

- Pascal-P2 was developed from a phase in the stepwise refinement of Urs Ammann's
Pascal-6000 compiler in 1974 by K. V. Nori, Urs Ammann, K. Jensen, and H. H. Nageli.
Subsequent improvements were done by Christian Jacobi.
- Reliability of Pascal-P4 has been fairly good. As of Spring, 1977, it was distributed to
106 sites by George Richmond and to 37 sites by Chris Jacobi. (No distribution data has
been received from Carroll Morgan.)
- Several good reports on the viability of Pascal-P were reported in PUGN #8 as well as
two more in this issue: Ted Park for a Data General Nova and John C. Knight for a CDC
Star-lOO.
- The is no promise of maintenance for Pascal-Po P4 is the final version produced at
Zuerich. We at Pascal News will attempt to print bug corrections in future issues in
this section.

- Documentation for Pascal-P4 consists of a 65 page report entitled The Pascal 

Compiler: Implementation Notes (Revised Edition) July, 1976. (A 24 page c~ection li;t
to the original December, 1974, edition is also available.)
- Pascal-P4 is a significant subset of Standard Pascal. Restrictions to the standard
include:

Pascal-Po
The most widely used portable compiler for creating new Pascal Implementations is
Pascal-Po Basically Pascal-P is distributed from three pOints in the form of a kit
consisting of a magnetic tape and printed documentation.

procedure and function formal parameters are not allowed.

files are not implemented.
goto's may not exit procedures or functions.

Pascal-P is a compiler written in Pascal (almost 4000 lines) which generates symbolic
code

for

a

hypothetical stack machine called a uP-machine" because it is somewhat of an

ideal architecture for Pascal-Po The symbolic code is thus called P-code.
On the magnetic tape are text files containing:
- a sample character set collating sequence. This file is also distributed as a listing to
simplify character set conversion.
- the Pascal-P compiler in Pascal.
- a P-code assembler/interpreter written in Pascal which is intended to document how to
write an interpreter in an existing language on the target computer system.
- a Pascal-P compiler in P-code. In other words, the result of compiling the Pascal-P
compiler on itself.

Implementation Notes

a (rather small) maximum string constant length is imposed.
the sub range form of set constants is not implemented.

nil is not a reserved~rd, but rather is predeclared.
many standard procedures and functions are not fully implemented.
text and maxint are not predeclared by the compiler.
Pascal-P can be ordered from three places (write for prices and order forms).
In Europe, Asia, and Africa, order from:

Christian Jacobi
Institut fuer Informatik
E.T.H. Zentrum
CH-8092 Zuerich
Switzerland
Phone: 41/1-32 62 11 x2217

George H. Richmond
Computing Center: 3645 Marine Street
University of Colorado
Boulder, CO 80309
USA
Phone: 303/492-8131

In North and South America, order from:

Carroll Morgan
Basser Dept. of Computer Science
University of Sydney
Sydney, NSW 2006
Australia
Phone: 629 1122

In Australasia order from:

Departement Informatique de l'INPL, Ecole des Mines, Parc de Saurupt, F-54042 Nancy Cedex,
France. In this case t the compiler operates in two passes; the first pass can be
parameterized and the second pass can be rewritten to generate code for different

machines. This effort is explicitly oriented toward 16-bit machines. So far as we know, no
other implementations have been developed from the initial compiler. See SEMS T1600 in the
Machine Dependent Implementations section.

Pascal J

(* We at PUGN would appreciate new ordering information be sent to us by these
three distributors for inclusion in Pascal News #11. We would also appreciate
some
sort
of
distributors. *)

coordination

on

a

common

order

form

for

these

three

1.

IMPLEMENTOR/DISTRIBUTOR/MAINTAINER. B. W. Pavenel, C. B. Mason,

Group,

Dept.

of

Software

Electrical Engineering, University of Colorado, Boulder, CO

Engineering
80309, USA

(303/492-7204) •
Pascal Trunk Compiler

2.

1. IMPLEMENTOR/DISTRIBUTOR/MAINTAINER. H.
H.
Nageli,
ETH-Zentrum, CH-8092 Zuerich, Switzerland (Tel. 32 62 11).

Institut

fuer

Informatik,

2. MACHINE. The trunk compiler is the machine independent part (e.g., syntax analysis and
error recovery) of a Pascal compiler in which the code generation has to be inserted in a
certain number of empty procedures.
3.

SYSTEM CONFIGURATION. Requires a working Pascal compiler.

4.

DISTRIBUTION. Magnetic tape. Cost: SFr. 50.--.

MACHINE. Pascal-J is a compiler which translates Pascal to the

intermediate

language

Janus, a totally portable "mobile programming system" -- even to the pOint of defining its
own character set! Janus in turn is macro-processed via Stage2 which is implemented in
standard Fortran.

3. SYSTEM CONFIGURATION. ANSI Standard 1966 Fortran IV compiler. Specify character set:
(a) ASCII (full 96, or 64 character subset), (b) EBCDIC, (c) CDC display code, or (d)
other character sets if detailed collating sequence is sent.
4. IJISTRIBUTIllN. 7-track magnetic tape (1200 ft. reel) $28.00 (0.8 kg); 9-track magnetic
tape (1200 ft. reel) $39.00 (0.8 kg). Subtract $7.00 if you supply a 1200 ft. reel. Longer
reels are accepted, but more postage is charged. Overseas orders must add cost of postage
and specify type of shipping.

5. DOCUMENTATION. In German, available in May, 1977 (77/3/3). Detailed comments in the
source describe how an implementor can write algorithms for the machine dependent parts.

5. DOCUMENTATION. (a) SEG-76-1 "A Preliminary Definition of Janus" $4.00 (180 grams); (b)
SEG-76-2 "PASCALJ Implementation Notes" $2.00 (60 grams); (c) SEG-76-1 (*-3?*) "Janus
Memory Mapping: The J1 Abstraction" $2.25 (60 grams).

6.

6.

MAINTENANCE. Not defined yet.

en
rr1

MAINTENANCE.

Every

-0

-I
rr1

3:
0:1
rr1
:;0

six months (February and September) a new release is planned, but

this is subject to manpower constraints. Attempt to fix all reported bugs.

7.

STANDARD. Full Pascal is treated.

8.

MEASUREMENTS. Not applicable.

9. RELIABILITY. Moderate (77/3/3). The Trunk was used with good results in 1975-76 by
Teruo Hikita in producing a high quality Pascal compiler for the Hitachi 8000 series.
10. DEVELOPMENT METHOD. Started in 1975 from a phase in the stepwise refinement of Urs
Ammann's Pascal-6000 compiler. The Trunk is a 5800 (indented) line Pascal source program
in which the machine dependent parts are clearly marked and separated from the machine
independent parts.

Some other machine-dependent compilers are written in such a way that they might be
useful as Trunk compilers. Take for example, the current ICL 1900 compiler written by Jim
Welsh, Colum Quinn, and Kathleen lkShane at the Computer Science Department, Queen's
University, Belfast, Northern Ireland, BT7 INN, United Kingdom. The syntax analysis is
separated

from the code generation in this compiler, which is written in Pascal.

possible

Trunk-like

8.

MEASUREMENTS. As an interpreter, very slow, but the intent is to do a

full

bootstrap

to a real compiler.

9. RELIABILITY. Moderate, improving with each release (Sept. 1975, Feb. 1976, Sept. 1976,
Sept. 1977). As of February, 1977, the portability of the September 1976 release is deemed
inadequate with implementation times ranging upwards from six person months.

10. DEVELOPMENT

METHOD. Compiler originally written in Pascal to generate Janus, and used

compiler

is

that

11. LIBRARY SUPPORT. Not applicable.

en
N

See ICL 1900 under Machine Dependent Implementations.
Another

STANDARD. (* no information - presumably full Pascal *)

to translate itself to Janus. Janus processor written in Stage2 macros as an LL(l) system.
The set of macros consists of stack operations and indeXing in terms of a single
accumulator and simple index register. A set of macros for multi-register machines is
being implemented. The Stage2 macro-processor is implemented in Fortran.

11. LIBRARY SUPPORT. Not applicable.

clearly

7.

implemented

by

Alain

Tisserant,

PASCAL VARIANTS
Pascal-S
A description of Pascal-S comes from the abstract in the report "Pascal-S: A Subset
and its Implementation", by Niklaus Wirth, Institut fuer Informatik, ETIi Zuerich, June,
1975. (Available for $6.50 from George Richmond; see address under Pascal-P.)

(2)

A guest editorial and four articles by Brinch Hansen in the April-June, 1976,
issue of Software - Practice and Exp~rience 6, pp 139-205. The articles are
entitled:

"Pascal-S is s subset of the programming language Pascal selected
for
introductory programming courses. This report describes an implementation that

"The Solo Operating System:

A Concurrent Program"

"The Solo Operating System:

Job Interface"

is especially designed to provide comprehensive
and
transparent
error
diagnostics and economical service for large numbers of small jobs. The system
consists of a compiler and an interpreter and is defined as a single,

"The Solo Operating System:

Procedures, Monitors, and Classes"

(3)

self-contained

(4)

"Disk Scheduling at Compile Time"
The book Operating Systems Principles by Per Brinch Hansen, Prentice Hall, 1973.
An article "Experience with Modular Concurrent Programming" in the )larch, 1977,

(5)

~ncurrent Pascal Compiler for Minicomputers by Al Hartmann,

Pascal

program.

This

machine-independent

formulation

in

high-level language facilitates its construction and is a prerequisite for
portability. "

a

easy

IEEE Transactions on Software Engineering 3:2, by Brinch Hansen.
Springer-Verlag:

Lecture Notes in Computer Science, Volume 50, 1977.
Standard

Pascal

constructs

omitted

from Pascal-S are:

pointers, set and file types, with and goto statements,
functions

as

parameters,

and

the

scalar and subrange types,

passing

of

procedures

(6)

The

new

book

Prentice-Hall,

and

the

1977.

Architecture

of

-

Concurrent

Programs

by

Brinch

Hansen,

several standard procedures. The only file operations are

read on input and write on output. The report contains a complete listing of the
and interpreter on 34 pages!

compiler
Modula

Pascal-S

is

currently

distributed

on tape with the second release of the CDC-6000

Pascal compiler from Zuerich, Colorado, and Sydney. Pascal-S was implemented in PL/I under
Honeywell Multics by the Computer Science Department, University of
Southwestern
Louisiana, P.O. Box 4-4330, Lafayette, LA 70504 (318/234-7640).
O. Lecarme reported on 77/03/04 that Helmut Sandmayr, Neu-Technikum, CIi-9470 Buchs,
Switzerland (085/6 45 24), has implemented a Pascal-S compiler (not interpreter) for the
IBM 1130.
Rich Cichelli reports (77/08/31) that an incremental interactive (conversational)
Pascal-S compiler was implemented at Lehigh University which is smart enough only to
recompile the subprograms in which changes are made.

Modula

written in assembler. The project at Cal Tech centered around writing a one-user operating
system called SOLO in Concurrent Pascal. Both compilers are written in Sequential Pascal.
In 1975-1976 the system was distributed widely (252 sites) and led to the development
of a machine independent version with a different kernel.
As reported in PUGN #6, distribution of Concurrent Pascal was terminated in August,
1976, when Per left Cal Tech to join the University of Southern California. On 77/07/12,
Per phoned to say that distribution may resume and arrangements are being made. Details
may be available for Pascal News #11.
Plans are to write a simpler kernel and I/O drivers. This may take 6 months.
Publications about Concurrent Pascal include:
(1)

"The programming language Concurrent Pascal", in the June,
Transactions ~ Software Engineering 1:2, by Brinch Hansen.

1975,

language

for

dedicated

computer

systems and process control

1975-76.

Published material on !10dula includes:
(1)
(3)

Pascal" compiler, a "Concurrent Pascal" compiler (used for writing operating systems and
other concurrent programs), and a "kernel II or machine dependent set of run time routines

small

though. *)

(4)
A portable pair of Pascal compilers was implemented by Per Brinch Hansen and Al
Hartmann at Cal Tech in 1974-1975 for the PDP 11/45. The system consists of a "Sequential

a

It

is conceptually cleaner than Concurrent Pascal in many respects. Modula is still
experimental and the implementors in Zurich have insisted there are no distribution
arrangements. (* We are hearing rumors of implementation efforts outside of Zurich

(2)
Concurrent Pascal

is

applications on small machines, developed by Niklaus Wirth and co-workers in

"Modula: A Language for Modular Multiprogramming", Softw'!.~
Practice and
Experience 7 (1977), pages 3-35, by Niklaus Wirth.
"The Use of Modula", same as (1), pages 37-65, by Niklaus Wirth.
"lJesign and Implementation of Modula", same as (1), pages 6 7-84, by Niklaus
Wirth.
"Toward a Discipline of Real-Time Programming", Communications of the ACM 20:8
(August, 1977), pages 577-583, by Niklaus 14irth.

The following is the Abstract from reference (4), above:
"Programming
complexity

of

is

divided

reasoning

in

into

three

program

major

categories

validation:

with

sequential

increasing
programming,

multiprogramming, and real-time programming. By
adhering
to
a
strict
programaming discipline and by using a suitable high-level language molded after
this

discipline,

the

complexity

of reasoning about concurrency and execution

time constraints may be drastically reduced. This may be the only practical way
to make real-time systems analytically verifiable and ultimately reliable. A
possible discipline is outlined and expressed in terms of the language Modula."
Copyright (c) 1977, Association for Computing Machinery, Inc.
Reprinting privileges granted by permission of the ACM.

FEATURE IMPLEMENTATION NOTES

Rcc.omrnc"da.uon 2 : to PASCAL
1977 February 17

PORTAB I Ll TY NOTE

obje~

~equenc.e

06

on

type c.haJt ;.,houtd
(.{.) a;ttempt to c.oUec.:t i l l ,;Udl MM .{.mo o.

ClI:~R

SET OF

p"ugftamn"v,,~

PftogtammeM wJt.{.ung c.ode -that depenM on the c.oLtatin9
,jelV

/Wu:t.{.nu,

and
Introduction
I have recently been examining a number of PASCAL programs that are
thought by their authors to be highly portable.

It rapidly became

obvious that it is not realized by the PASCAL community just how

(u) o.dc.quateJ.y c.ommCIt-t ~uc.ft IUle-, ~o that the .{.mellt 06

the c.ode M deaJt.
Tlw adv.{.c.e CLppUM pOJVuc.ulaJt£y to

PASCAL ted by leuc.illy

aIlCl1.Y~,{,Ylg

PJt09~

wh'{'d! pitOC.M-6

U.

many problems are caused by the different character sets used on
the computers

\1e

have avai lable, nor ho\tJ this problem is compounded

by the ~ type in PASCAL.

This note sets out to make the problems

more widely known, and to make recommendations to implementors and

Available characters
Except that PASCAL originated in CDC machines this would not be a severe
problem, since ASCII and EBCDIC have a high degree of commonality in

programmers.

the graphics.

Programmers should however be aware that the characters

Character set collating order
There are two very common character sets in the computing industry:

"hich can be assumed to be avai lable on all computers are 1 imited to

EBCDIC (adopted by IBM, Burroughs and ICL 2900 range), and ASCII (adopted

of probability (for example '>' and' [' are quite highly probable, but

the 48 FORTRAN characters.

Others are available with varying degrees

by a number of other mainframe suppliers, and most minis)~ together with

't', '=', '{' are extremely unlikely).

a fev.J manufacturers \"ho use their own idiosyncratic character sets

felt when designing a language or sub-language or a reply system.

(the key example being CDC).

inappropriate choice of character may mean that there is no suitable

In this lot, we can assume nothing

The point of this is mainly
An

about the collating order except that the alphabets collate in ascending

alternative in another system, and doublet symbols will have to be used

order; that the digits collate in ascending order and have successive

(as for example happened with the { } and (* *) in PASCAL itself).

ORO values; and that the 101-ler-case alphabet collates either lower or
higher than the entire upper-case alphabet (if it exists).

Practically

every other variant of ordering occurs.

The second major deficiency in awareness occurs in respect of the
lower-case alphabet.

Programmers, through long conditioning, are

very proficient at reading solid upper-cased text.

The general

This has always been a severe problem to programmers attempting to write

populace are not, and even programmers read normal text faster and

portable software, and the advice that can be given only alleviates the

more accurately than the upper-case we normally print.

problem: it cannot solve it.

regrettable that many programs are written so as to totally ignore the
existence of loItJer-case.

Rec.ommendarun 1 : :to PASCAL hnplemel1x:oiL6
All PASCAL c.ompJ-teM ~houtd be able to handle obje~ 06
type c.itaJt M .{.meJtvtaUy ftepitu en:ted .{.yt UtiteJt tlte Ascn Oft the
EBCVIC C.OdM, and pite6eJW.bly botfl. It may be nec.uMfty :to
deteJUri.{.l1e the dtaJt Jtept'cM enmt.{.on by a c.omp.{.,teJt opt.{.on.

It is thus

Programmers should make provision for

systems that can read and print lower-case alphabets to use them, even
if their system cannot, by simply providing the hooks and commentary.
Rec.ommendation 3 : to PASCAL

~ogJtamm~

Be cuvaJte 06 the UHvttiat d.{.6ileJtel1c.M be;tween the pit.{.ntable
gJtaph.{.~ (and.{.11 ~ome c.MM the c.omol c.ilaJtac.teM), and
make illowanCM 60ft thMe d.{.66eJtenc.M.

They aJte .{.mpoJttavtt.

The set of char

-0

The PASCAL set construct looks at first sight as to be heaven-sent to
enable programmers to write code which is independent of character
set collating order.

The

~

operator allows testing a character for

membership in a set, rather than having to do relational comparisons.

Rec.ommeHdation 5 : :to PASCAL .i.mpleme.l1:toM
16 pOM.i.b.te, .unplenlevI:tation6 ~hou..td pV-,nd a mo.wnum J.. e:t J..,~ze
wlUcll will. ac.c.ommoda:te ill c.haJWc.-teJt; .i.n .the c.ilCVto.c;teJt ~ e:t.
The mcUn pfwbleJn6 c.en:tlLe CVtound J.. e:t a p0ta-tOM, and the Cfle.atiOll
~ e:t

Alas, this is an illusion.

Though conceptually the set construct is ideal,

:tempolLcvUu, .i.6 .the. wOl1dJ...i.ze
lCVtg e ~ e:ts mal{ ltutM.c;ted :to :the

V,

:to 0 Mill.

~.i.l1gle

::t>(I')

"::t>oil

r 6 nec.uuUtl{,

C.M e 06 'J.. e:t

06

eilCVt'.

and it is excellent for writing such constructs for sets of more

(I')



=

rn

~

It follows that the definition of PASCAL ought to explicitly give
this sequence, rather than leave it to be implied.

is made to the PASCALERROR routine to kill the program.
Undefinition

The definition (and the preceding paragraph) state that after the

The detection facility is not available if the loop is a DOWNTO loop,

execution of a for statement (provided the statement is not left by a

or if it cannot be simply optimized.

goto) the value of the control variable is undefined.
implement the loop efficiently.

=

The primary

purpose of this undefinition is to allow implementors freedom to

PASCAL programmers should not therefore

rn

::E

Summary

CI)

In this case, and others, the 86700/87700 PASCAL compiler enforces strict

presume any particular value in the control variable after it has been

adherence to standard PASCAL.

used in a for statement.

negligible time penalty.

Of particularly nasty characteristics are the

compi 1ers which may leave it set at succ(e2), since this may be
out-of-range of its type.

Hardware checks make this possible with

Programs written in 86700 PASCAL therefore

have a higher probability of being portable in this respect than would
be the case for many other PASCAL compilers.
effect, however:

In the 8urroughs 86700/87700 computers, it is easy to prevent programmers

There is one unfortunate

non-standard PASCAL programs are less likely to execute

in 86700 PASCAL since it is such a searching test.

from doing any computation with this variable until it has been re-defined
by setting it to a tag-six word (uninitia1 ized operand).

This value can

be overwritten by a legal value, but causes a machine interrupt if the
va r i ab 1e is used in an operator context.

Th i sis done for all for

statements in 86700/87700 PASCAL, and the illegal use of the variable

Imp1ementors of PASCAL are invited to send me answers to the following
questions about their compilers.
1.

cannot therefore be permitted.

In what order are e1, e2, and the assignment of v carried out?

Does this differ with the form of the loop?

It should also be pointed out that the definition of a for statement
a110vls the control variable to be undefined whether or not the body
of the loop is ever entered.

The invitation is also extended to

users as implementors are notoriously unreliable correspondents.

2.

What value is left in v if the loop is never entered?

3.
4.

What value is left in v if the loop is entered?

86700 PASCAL treats both cases the same,

1 imit-variable)

unlike some other compilers which take advantage of the implementation

freedom to leave the control variable unchanged, or at el, if the
loop body is never entered.

Vlhat happens if the control variable is altered (or a
(a)

from a piece of code compiled in the body, and

(b)

from a procedure called in the body?

5.

Are there different (optimized) forms of for-statement?

6.

Are there any limits on the number of repetitions or size

How do they differ?
Internal change to the control variable
The User Manual, on p24, explicitly forbids the alteration of the
control variable by any statement in the body of the loop.

constructs are hard to detect as they may occur in the body of a
procedure or function.
this occurrence

at

On the 86700 computer it is possible to detect

run-time with a small

ti"me

of the limit-expressions?

Such illegal

penalty, under some

If code-templates could be attached (with explanations) this might be
usefu 1 too.

If sufficient information is received, it may be possible

to prepare a summary for PUGN.

circumstances.

If the loop is capable of being optimized to use the STEP-INDEX facility

Arthur Sale

(which implies that e1 and e2 are in the range 0 .. 65535, and the loop is

Professor Information Science
University of Tasmania

a TO-loop), then a STEP-IIWEX-VlORD (SIVI) is stored in the control

(Burroughs B6700 implementor)

variable v.

All read-accesses of v return the (integer) value of v,

without the final or increment fields, but write-accesses destroy the
tag field.

Thus when the loop incrementation point is reached, the

STBR instruction causes abnormal termination of the loop, and a call

APPENDIX (continued)
APPElml x
::z

66700 'FOR' STATEMENT CODE TEI'IPLATES

CASE 3 (constant bounds)
CASE 2 (unoptimized, but was

CASE I (unoptimized)

CASE 4 (first bound constant,

second capable of optimization)

rn
C/)

a potential case for optimization)

LIT (1/,,2/el)

e2

el

e2

I

OUPL

e2

NAt,1C(TEMP)

I

lIT(el)

NAMC(TEr~p)

STOO

STOD

LIT(el)

t~r----------------~I

~:~:(EL)

Ii""

,

LIT(el)

NAMC(V)

rI

TL:

l

STON

EXCH

1

(* store into V, but leave on TOS *)

VALC(TE~IP)
LSEQ

(*GREQ if DOliNTO loop")

BRFL(EL)

(*test whether to exit the ioop*)

INSR(35:16)
ONE
INSR(47: 12)

- - - - - - . J1

v,r.----.

LT8(4 )
STAG

,

body

i

VAlC(V)

NAHC(V)
STOO

I

ONE

f

:C(V)

L

STON
BRUN(Tl)

(* increment i')

U'

body

5UBT if OO\vNTO loop *)

(* store, but leave on TOS *)

NAI'1C(V)

(* go do the test again *)

STBR(El) _ _ ___.

(* increment, store, and test *)

BRTR(TL)

(1, branches unless SIH overwritten i,)

El: ' E - - - - - '

MKST

ZERO

NN1C(PASCAlERROR)

lT8(6)
STAG

LT8(4)

(* now got a tag-s ix word on TOS I,)

ENTR

NAMC(V)
STOO

(* store the 51W into V *)

Tl:

(* into the control variable *)

(* causes pascalerr(4) *l

EL:
ZERO
lT8(6)
STAG
NAHC(V)
STOO

(1, undefine the control variable ,0,)

0">
00

NOTE TO PUGN

tempI :=el;
tempZ:=Z;
INTERIM REPORT - IMPLEMENTATION OF FOR-STATEMENT - I

v:=templ;

while v

~ ~empZ

The note gives some comparative details on the implementation of for-

s;

statements in two PASCAL compilers.

As more information becomes avail-

v:=v+l ;

able, it will be added to the list.

See my earlier comments in a

do begin

z
rn

:::e:

end;

(/)

Note to PUGN on the Burroughs B6700 implementation.

v:=invalidtagsixvalue;

BAS I C TEMPLATE

The answers are again:

(i) as for PASCAL-6000.
for v:=el to eZ do s;

(ii) + (iii) In all cases the exit value of v is a special word
which cannot be utilized as a value, but can be overwritten

PASCAL-6000 .-cCDC Cyber range)

with a proper value.

The implementation produces code which is equivalent to the following:
~

templ = a register;
temp2

=

a temporary stack location;

tempI :=el ;
tempZ:=eZ;
while tempI

~

tempZ do begin

v:=templ;
I,~PLHIENTAT I ON NOTE

s;

1977 February 17

templ:= v+l;

B6700/B7700 Pt1SCAL

end;

ELSE

JtI

USE

The consequences of this code on the precise action of the loop with

the three questions I posed are:

In t roduct ion

(i) the two expressions are computed before an assignment, so that

Many PASCAL implementations are inserting an ELSE clause in the CASE statement

v:=l; for v:=v+l to v+l0 do 5;

of PASCAL.

will count from 2 to II.

pseudo-standard for any such implementations so that maximum compatibility

(i i) The exit value of v if the loop is never entered is its value
before the loop is reached.
(iii) The exit value of v is eZ if the loop is ever traversed.

This note puts the cases for and against, and proposes a

between PASCAL

compi~ers

can be achieved.

Aga i ns t

In addition, alterations of v from within the body of the loop do in

The case against having an ELSE clause in a

fact alter the progress of counting, if they can be achieved.

encourages a programmer to use the clause through laziness simply to save

"riting a long I ist of alternatives.

PASCAL for Burroughs B6700/B7700 (Tasmania)
More details are given in the Note mentioned before.
generally equivalent to:

The code is

~

statement is that it

Thus \-Ihen an unexpected value of

the case expression occurs, it is processed erroneously by the ELSE clause,

rather than being one of the 'undefined' areas of PASCAL.

The arguments

here rest on implementors choosing to detect values of the case expression
~

tempI

a temporary stack location;

temp2 = a temporary stack location;

which do not match any label, and choosing to make such occurrences definite
run-time errors.

Such an interpretation is not mandatory.

For

Syntax of else-clause

The arguments for an ELSE clause are regularity, and robustness.

The regula

In the 86700 implementation, an ELSE can appear wherever a case-label can,

argument comes from (i) examination of languages of similar age and utility,

except that there can be at most one in any case statement.

in most of which the feature appears, (i i) the analogy with .i.i.-~-else

may appear in a case-label list, though it is difficult to see why this

which may be viewed as a special version of ~, and (i i i) actual thought
habits of good programmers.

would be done.

The robustness argument derives from the need to be able to write programs

Thus an ELSE

This syntax is very easy to accommodate, and requires

minimal changes to the CASESTATEfiENT routine in PASCAL-p4. There are no
other syntactic changes.

z
rn

:::e::
C/)

which are robust against all input, and all circumstances, and from the
difficulty of handling all case statements without error.
of labels are error-prone, and sometimes inappropriate.

Long lists

Reeommel1da.t.i.on 3

If the intention

loan ~p.temetJ.tatioll adopu an fLSE-e.tw,vJ e, .then .the above

is that all values other than a specified few are to be similarly treated,

~yn.tax 6houU be JtegalLde.d

then it ought to be possible to specify this.

alLe a.t..;tac.hed.

(V;

~.tal1dafLd.

Mo~Med ;,yntax ~ag!'"am6

The B6700 implementation

Styl istics

The implementation of PASCAL for the Burroughs B6700/B7700 computers

The preferred style for a case statement containing an else clause has the

at the University of Tasmania contains such an ELSE facil ity.

develo~

The semantic

else clause last, follmving all labelled clauses.

features of this implementation are suggested as a pseudo-standard for PASCAL
implementors who also agree that this is a necessary feature.

Example of case with else

A case without else
If no else appears in a ~ statement, the 86700 implementation will
raise a run-time error event, and terminate the program,

if the case

expression evaluates so as to match no case label.
Rec.ommendation 1
1

Tha:t aLe. ~mp.temen;ta;t;{.o 116 a n PASCAL fLegalLd .the above a/.) .the

thing

:=

arithmeticoperator;

thing

:=

variahZeevaZvator;

.-

separator;

,~ , ;

':

thing

pfLeneM.e.d ,!>emaruCh on .th-iJ, 6uua;Uon OJtM.~ng ~11 a c.a/.)e

Arthur Sa I e

else:

6.ta:teme.m.

Professor of Information Science

thing .- otherthing

University of Tasmania

(Burroughs 86700 implementor)
A case with else,
If an else clause appears in a

~

statement, then the B6700 implementation

transfers control to the else clause for all values of the case expression
which do not match an explicit case label.

In all other respects an else

clause behaves as a labelled clause.

Re.c.omme.l1dation
Tha:t .the above. be. fLegalLded a/.) .the m~~mum 6e.marue r,equ..Uceme.na
on an we-e.tD.lL6e ~11 a ea/.)e-6.ta:teme.m.

10

06

.the ea/.)e-expfLu6~0I1 w~dt alLe olLU~de

-0

an ~)J.tememation

Mil eaU6e .the 6ame. eooee.t a/.) ~11 Reeommendatiol1 1 OOfL

m

>

va.tuu

G)

rn

dee.talLe,d fLange.

(a/.) ~n .the .type.}, .they alLe el1eoUfLaged .to do 1.>0. Tw -iJ,
fLe.tevan.t oH.ty .to ~p.temetJ.ta.tJ.aM .that A..Vle.tude an we-e.taMe..

MODIFIED

SYNTAX

CHART

FOR

CASE-STATEMENT

IN

WIRTH-FORM

Variable-parameters in Pascal
Bill Findlay,
Glas?ow University, Glasgow G12 8QQ, Scotland, U.K.

I!:ter[~ct:12.~~":~: -th _.:~§S;~-Il n!:'S:L~23 - D. A. Joslin, University

of'

Sussex~ Computer

Centre, Brighton, U.K.
:i::l18 rccPJ.iro,,:::rd; of the HcviZ'f'd. nopcrt

t'!:~_~-.:G

T~:rU~;.:·t-

fron the vej"~r- :::·t~:":'t of c~ }):~:og:t'n::J (;:ore ~_'r~'·!;C':::·8._11:.!!
iLulJ8cliatc:;'y [,foGer ]{,,:-- ,~i\:E)y and

liJi;AD(i'~:'.:)~~

X~=

1-( C.cfi:r..:-:11.

f"1'"

£"i';

18/5/77

l'i:-::'1t

iD cl.ci-ir..ca
~~E'I'(f)

) ~est:.lto

The impression that variable-parameters in Pascal must be
passed by reference is wid~spread (e.g. it appears in the books
by Conway,
Gries and
Zimmerman and by Webster).
However, I
believe it to be a misconcept Lon stemming from the fact that all
existing implementations have used reference passing.
Many other controversies in the Pascal Newsletter arise from this failure
to distinguish between language and implementation.
My understanding of the matter is that (as in Fortran and
for
the
same
reason)
both reference and value-result are valid mechanisms for
variable-parameters.
If we look at Section 9.1.2 of the Report we find only that
the formal "represents" the actual during the execution of the
procedure.
~ame
binding is disallowed (thank Heavens!) by the
rule that the index of a
subscripted variable-parameter is
evaluated just once, but reference is not specified.

Ca.:Cd·<:~0r_ ;.d X'E:01.le;~t by a.ny dt~~'LiI(f :c'ccol~cl (tfh.ich

&C·~UDJ.::"y process)

'i

-the

pY0E:;2'"f!.!.'l

'I.-rill ~.:.ot

and 8econd a!1o. 8u.bseqnent r8quests cy {:er:QinB-l

inpl.rL:;

en
rn

(ii)

"""CJ

In the Axiomatic Definition, at axiom 11.2, it is stated that
the variable-parameters and non-local variables accessible by a
procedure-call must be distinct
(no "aliaSing").
Given this
condition, it is not possible to determine the parameter-passing
mechanism by running a legal
program.
I conclude that any
method which satisfies axiom 11.2 is allowable.
This issue is not just of theological interest.
The implementor has been given an important degree of freedom: he can copy
the technique used by the Fortran system on his machine and
thereby gain access to the enormous investment in Fortran library
routines.

-i

rn
pny;C}~J)lJRE G}~I~Fr:{1JAL(VAR X:IU~AL);

Cd

rn

BEGIN lillADL!I; READ(:::) mill;

=

;JJ1J1?3L!':( tS:'YP:i_~ A REAL N1Jl·132ERt);

r;];T '.'(EflL (x) ;

(.x- 'luE'stion .lj,)
(.;,. cet 2_ns\.,'8r .,:.)

unIIJ:BL:n(tx =', x);

(.;~ :('8Bllonne t::> EL:!!3\-.'cr .;'. \

to rule (U) above;

he h3.8

loac.8~

a P:::0C'''.co.;n b.a is to interac"!; wit},

a sar:1ple teletYIJe 383st0J1 r::hOi./ine ini:era0'GioD
wi th

CC21Il~'T

viE'"

III~[lEru~Ct.L ..

_LISTING OF ,T CelIINT(1/)

PROOUCfD ON

'MAY7' AT

_OUTpUT RY LlSTFllF IN ',T.rC21' ON 13MA-V77 AT

11.49.48

".~O.44 usING

1~.19.51~

LlSl'FILF INT~RACT,NUM~fR
o .t,'llJACRI'J INTF.RACT
D.A.JrJSLIN.

U14

coni"

Ic'>J !,T????

5 ')? .... ?
6 AS *CRO, !
7 F.R !
~ RP CfO:., DP,LS,I]L,P!W'j

PASCAL rn~p, OpJFCTCC21INTPROG
TypE STRING = pACK~D ARRAY [1 •• ,6] OF r.HAP,
VAR ~! STRI~G: J,K, INTEGF': r. CHAR:
PROCrnURF GFTSTRI~G(VAR S: STRING),
VAR I, I"THER' AI A'RAY n •• 16] OF CkAR.
nFGIN

9

FOR 1.= ,

TO 16

E,'

0

10 IF F"AILCFILE *CRO),
II RP F>i.CM
12 R,~

JlEAiHN:

pAC'UA,1

n~"'1~Y77

IlL *LPO
CE

DO RFADCA[Il):

dL *CRO

,S~

OJD.

PROCFOURF GF.TINTEGFR(VAP I,INTEGERI:
RFGIN
HADI N:
OFADel)

I!.?· 20. S~- LdAD CC~l I NTPRiJG .. CdRESK

FNO.

PROCEPUO. GETeNAReVAR r.,

12.21.05- INTERACT
~l THERf~ - PLEASE TYPE IN YdUR

C"~R):

RfG '"

OEADtO
FtJD.

BEGIN
WRITFlNC'N! TNfRE • • lFA~E 'YPE IN YOUO NAME'II
GETSTRINGCS) ,
WRITFLN('GlAn TO HfET ~I'IJ, ',S):
REPEAT W.!TFlNt'TVPE IN A UkOlF NUMBEr'):
GFTJNTrr.ER(J):
WRITElNI'Ann ANOTHEO'):
r,FTtNTrr.FR(IO:
tJrHTFLNl 'YOUR I-.ttlt-'RERS ARF-f

NA:~E

IlAVI D
GL4f) Til MEET YiJU, D~VI D
TYPE IN A WHOLE NU<'1RF.R
~

HADIN:

,.J,

I

ANO. ,110:

WRITFlNt'TIIFIR SU~ T~·,J+K,., ANn THEIW DIFFERENCE 1~',J~K):
WWITFlNl'S~AlL WE TRV AGAIN?I):
GFTCHARlC)

UNT!L ell'Y·:
WRITELNC'GOODS,E, '.5)

END.

:::~AL COMPILE • • pASQ/2A r~USSFX VFRSlnN 001) ON 04/05/77 AT ,,'49/44
OPTloN(SI ~FLErTEoI NoNr

..

1~3

AND ANUTrlER
- 67
YiJUR j'lW1B!':HS ARE
123 AND
(:, 7
THE.lR SUr'l IS
190, AND TH.EIR DIFFERENCE IS
S~ALL

W~

TRY AGAIN?

... Y i-~S
TYPr". IN A i~HUI...E NUM8ER
- -I
.4Nf) ANUTHER

•

77

¥tlUR Nl),"18Er.::, ARE
T>iF:l:", $lJ,"j IS
70'
SHALL W~ TRY AGAIN?
.. Vi-:S,. :ji'lCE ':"10~E

-,

TYP~

iN A

W~JLE

Y!J'L~

~lJ"I~I<:.~.c;

5 A,'ll)

90R,

W~ TRY AGAIN?
Nu TdANx

(Uljil4Yr~,

D.A.V D

1?26.n1 FRf *LPO ,18 lRANSFERS
12.?6.0A FRE .CRO ,10 TRANSFE~S
n•n3 : HAL HO , iJK
/£Nt) IJF ;'oiACRCt

901

AND TrlF.l;~ DIFr~F~ENCIi.· IS

S~ALL

-

IS

NUM8ER

~'~F

I.,FJ~ 00'1 IS

-I AND
77
ANJJ T,",EIR DIFFF.:-RF.i'iCE

8.

MEASUREMENTS.
Pass 1: 4000 lines of Pascal, compiled @ 1000 lines/min.
Pass 2: 2500 lines of BPL, taking 45 sec. to generate code for Pass 1 of the compiler.
A minimum of 110K bytes is needed for a logical (reasonable) segmentation
of the compiler. (* Size and execution speed of code produced not reported. How this
compares to FORTRAN and other languages not reported. *)

MAC HI NED EPEN DEN TIM P LEMEN TAT ION S
---Pascal Implementations Summary---

9. RELIABILITY. Good, but not excellent. (* Number of sites using compiler not
Date first released not reported. *)

(* This section summarizes all the information that we have on all
Pascal implementations, in the checklist format. *)

reported.

10. DEVELOPMENT METHOD. Compiler was bootstrapped from an early PI compiler obtained from
CalTech. The compiler consists of two passes. The first is written in Pascal and emits
augmented P-code. The second pass (written in BPL, a PL/360-like assembler) generates 4700
code from the P-code. The first version of the compiler was written by Mike Mahon in 2
person-months. An additional 8 person-months have been expended in teaching the compiler

Amdahl 470

about such things as optimal variable size and alignment, segmentation, etc.
(* See implementation notes for IBM 360/370. *)

II. LIBRARY SUPPORT. (* No information prOVided. *)

Tektronix, Inc.

Burroughs B1700

June 8, 1977
In a letter dated November 3, 1976, Tony Gerber (Basser Dept. of Computer Science,
School of Physics, University of Sydney, Sydney, N. S. W. 2006, Australia; Tel. 629 1122)
reported several persons who have worked on B1700 implem~ntations. They are:
Elliott

Organick's

group

at

the

University

of Utah, using Brinch Hansen's Sequential

Pascal.

Mr. Andy Mickel
PASCAL User's Group
University Computer Center
227 Experimental Engineering Building
University of Minnesota

en

Minneapolis, Minnesota 55455

rn

projects.

Dear Andy:

-i

P. Albrich, Univers'ity of Karlsruhe, Germany, was working with Concurrent Pascal.

Thank you for the incredible amount of effort you have put intu
making PUG work. Please, however, don't use anymore of that ugly
c.hartreuse paper.

to

P. Schul tess and K. Hauserman at the University of Zuerich, who each worked on

"0

(separate)

M. Ellison at the University of Newcastle-upon-Tyne was using Pascal-P "version 1.On.

rn
::s:
rn
:;:0

As to the Burroughs 83700/84700 PASCAL implementation reported by
Dr. Lansford in PUGN#8: Due to the efforts of Burroughs' management,
the (spare-time) project has been cancelled. We understand that

Burroughs B3700, B4700

1. IMPLEMENTOR/DISTRIBUTOR/MAINTAINER. R. M. Lansford; 3620 Greenhill Rd.; Pasadena, CA
91107; 213/ 351-0206. P. L. McCullogh; Tektronix 60/666; P.O. Box 500;
Beaverton,
OR 97017 (503/638-3411 x2397). W. C. Price; 28282 S\~ Mountain Road; West Linn, OR 97068
(503/644-0161).

inquiries through Burroughs Medium Systems Plant have been answered
with "Ask your local Burroughs representative. 11 The reports we
promised on certain interesting aspects of our implementation
(segmentation, optimization, augmentation of P-code, etc.) have
been delayed (perhaps indefinitely), as we are no longer associated
with Burroughs Corporation.

2.

MACHINE. Burroughs B3700, B4700 (with Accumulator operator.)

Herewith, however, is a short comment arls1ng from our attempt at
understanding the full implications of PASCAL's file structure.

3.

SYSTEM CONFIGURATION. MCVP 5.7 and Time Sharing System

Truly,

4.

DISTRIBUTION. No plans at present--the need has not arisen.

5. DOCUMENTATION. Foreward to program listing; in form of supplement
Manual ~ Report. (* This is apparently not machine retrievable. *)
6.

7.

to

MAINTENANCE. None. Development has terminated. tllf you find' em, f ix' em. II

STANDARD.
Unimplemented:
real arithmetic
formal procedures and functions
files, .(except text files INPUT
and OUTPUT)

Extensions:
segmentation
symbolic procedure call tracing
stack checking and statistics
packing is optional

Pascal

User

lJL~>
;.~i~~~

William
Instrument Research Group
Tektronix Laboratories

WCP:pt
Attachment
cc:

Dr. R.M. Lansford

P. L. McCullough

Burroughs B5700
teaching intervenes. Project has thus far been limited to two people:
and R.A. Freak (Support programmer).
Bruce A. Pump lin, Department of Computer SCience, University of Wisconsin - Eau Claire,
Eau Claire, WI 54701, has promised us a report on the progress of his Pascal-P based
implementation for the B5700. Last we knew (76/08/25), the compiler-interpreter was

11. LIBRARY

~UPPORT.

There

is

as

yet

no

Prof.

A.H.J.

Sale

BI~UI~FO in the code-file so that it is not

possible to l1Rk Pascal to modules compiled by other language processors, but
contains an extended set of predefined mathematical functions.

the

system

working.

=
rn
Burroughs B6700 (San Oiego)

Burroughs B6700/7700 (Tasmania)

C/)

1. HIPLEMENTOR/DISTUBUTOR/MAINTAINER. A.K.J. Sale; Dept. of
Information
Science;
University of Tasmania; Box 252C G.P.O.; Kobart, Tasmania 7001 Australia; STU 002 23-0561
x435.
2.

MACHINE. Burroughs Model III B6700, B7700

3. SYSTEM CONFIGURATION. Burroughs MCP version 11.8 (with few (minor) local mods).
Minimal system to operate not known, but unlikely to be any B6700 that small--storage
demands are low, and little else is critical.
4.

::E:

1. IMPLEMENTOR/UISTRIBUTOR/MAINTAINER. Distributor: Henry Fischer; UCSD Computer Center;
University of California - San Diego; La Jolla, CA 92093; 714/452-4050. Implementors: Mark

Overgaard; Jim Hadden: same site.

2.

MACHINE. Burroughs B6700

3.

SYSTEM CONFIGURATION. (* No information provided. *)

4.

DISTRIBUTION. Scheduled to start in mid-summer, 1977. (* Information on cost, magnetic

tape formats, etc. was not prOVided. *)

DISTRIBUTION. Both 7 and 9 track magnetic tapes available. (* Cost not reported. *)

5.

DOCUMENTATION. (* No information provided. *)

DOCUMENTATION. Supplement to Pascal User Manual and Report available; a dictionarystyle "Reference Manual" is in preparation but is not yet complete (77/4/20). (* Not known
if this documentation is machine retrievable. *)

6.

MAINTENANCE. Unknown at this time.

7.

STANDARD. (* No information prOVided. *)

s.

6.

MAINTENANCE. To be maintained for teaching use within the University as well as larger

aims.

Reported

bugs

will

be

fixed

as

soon as possible. with patch notices to users.

Duration of support not yet determined; several other developments are also pending.
7.

STANDARD. Restrictions: Program heading: reserved

procedure;

no

parameters

(files)

are

word

program

is

synonymous

permitted after the program heading. Reason:

with

cue

anachronism of no utility in our installation, and likely to be confusing. Set constructor
of form A•• B not implemented. Reason: future plan. FORTRAN control character on print line
not implemented. Reason: a ridiculous feature to standardize. Full Pascal I/O not
implemented. Reason: future plans. Present I/O scheme is like Pascal-l. Extensions:
Various reserved words, character set transliterations. Burroughs comment facility_ ELSE
in
CASE.
File
attributes
in
declaration.
Format
declarations.
Extensive
Burroughs-compatible

compiler

options.

(Pascal

control

comment

option

mode

C/)

rn
8. MEASUREMENTS. Current compile speed is 5000 line/min; but expected improvements could
make that 10,000 lines/min--as fast as the Burroughs Fast Algol compiler. (* Size and

-0

execution speed of code produced not reported. *)

rn

9. RELIABILITY. Unknown at this time. (* Number
provided. Date of first release not reported. *)

of

sites

using

this

compiler

not

10. DEVELOPMENT MET~OD. Real compiler, written in Pascal which produces native code for
the B6700. (* Person-hours to create compiler not reported. *)
11. LIBRARY SUPPORT. (* No information provided. *)

not

implemented).
Burroughs B6700 (New Zealand)

8.

MEASUREMENTS.
compiles about 20% slower than FORTRAN or ALGOL, but in about 2/3 of
their space (for test programs about 4-5 K words on average
instead of 8-10K). Elapsed compilation times similar, though
Pascal slower. Speed should be improved by eventual tuning.
executes at same speed as FORTRAN and ALGOL (code is very similar and
optimal) and takes generally longer elapsed residence time
primarily due to MCP intervention to create new segments for
record structures (not present in FORTRAN/ALGOL).
Elapsed
residence times about 20% greater than equivalent ALGOL.

9. RELIABILITY. Excellent. Only one system crash during testing attributed to Pascal.
Compiler now in use at 3 sites. Compiler has been in use since 7&/10. First released to
outside sites in 77/4.
10. DEVELOPMENT METKOD. Compiler which generates B6700 code-files which are directly
executed by the B6700 with MCP. Written entirely in B6700 ALGOL. Kand-coded using Pascal-P
as a guide/model. All other paths offered much more difficulty due to special nature of
machine/system. Person-month details not kept, and project proceeds in fits and starts as

----------------------------1. IMPLEMENTOR/UISTRIBUTOR/MAINTAINER. Chris Bishop; Computing Centre;
Otago; P. O. Box 56; Dunedin; NEW ZEALAND; (Tel. Dunedin 40109 x890).
2.

MACKINE. Burroughs B6700

3.

SYSTEM CONFIGURATION. (* No information provided. *)

University

of

4.

DISTRIBUTION. Tapes can be written in any of the following formats:
a) 1600 bpi, PE, 9 track, B6700 library tape
b) 800 bpi, NRZ, 9 track, B6700 library tape
c) 1600 bpi, PE, 9 track, USASI Multi-file tape
d) 800 bpi, NRZ, 9 track, USASI Multi-file tape.
(* Costs for tapes not reported. *)
5. DOCUMENTATION.
retrievable. *)

Brief

notes

on

usage

available.

(*

Not

known if this is machine

--i

6.

MAINTENANCE. (* No information provided. *)

7.

STANDARD. (* No information provided. *)

3. SYSTEM CONFIGURATION. (* the Cyber 18 is a self contained interactive system. *)
Dennis Nicolai (CDC, Minneapolis) reports that the Cyber 18 and the 2550 have similar
instruction sets, and that the compiler is a cross-compiler which runs on Cyber 70's and
170's. Code is linked and 'down loaded' to the Cyber 18 and 2550.

MEASUREMENTS.
compilation space-- (* No information provided. *)
compilation speed--Compiles the Karlsruhe B6700 compiler in 90 sec. of processor time.
execution speed--, (* No information provided. *)
execution space-- (* No information provided. *)
(* How this compares to FORTRAN and other languages not reported. *)

8.

9. RELIABILITY. Unknown at this time. Compiler in use at
compiler has been in use not reported. *)

3

sites.

(*

Length

of

time

10. DEVELOPMENT METKOD. Karlsruhe 86700 compiler-interpreter translated from Pascal source
to Burroughs Extended Algol. Produces symbolic code for a hypothetical stack machine.' This
symbolic

code

must

be

assembled

to

produce

absolute

machine code which may then be

interpreted. Both the assembler and interpreter are written in Extended Algol. It is
planned to convert this Algol version into a true compiler for the 86700; work will start
in earnest about July of 1977. (* Person-hours to create compiler not reported. *)
11. LIBRARY SUPPORT. (* No information provided. *)

4.

DISTRIBUTION. Control Data Corporation.

5.

DOCUMENTATION.

CDC

Manual

88988500 A.

(*

Apparently

no

machine

retrievable

rn

documentation available. *)

:E:

6.

MAINTENANCE. CDC supported Communications Front End software.

7. STANDARD. Unrevised Pascal
def ined.

language

definition

8.

HEASUREMENTS. (* No information available. *)

9.

RELIABILITY.

Excellent.

(*

with

C/)

extensions.

I/O

is

hardware

Number of sites using system not reported. Date of first

release not reported. *)

10. DEVELOPMENT METKUD. The compiler is derived from the compiler for the CDC 2550 front
end processor, which in turn was derived from the old Zurich Pascal-6000 (1972) compiler.
11. LIBRARY SUPPORT. (* No information available. *)

Burroughs B6700 (Helsinki)
CDC 3200
C/)

1. IMPLEMENTOR/DISTRIBUTOR/MAINTAINER. Antti Salava; formerly at Dept. of Computer
Science; University of Helsinki; Toolonkatu 11, SF-00100; Helsinki 10, Finland; Present
address: Munkkiniemen Puistotie 17-A13; SF-00330 Helsinki 33, Finland; phone: 90-486288.
2.

MACHINE. Burroughs 6700

3.

SYSTEM CONFIGURATION. (*Unknown *)

4.

DISTRIBUTION. None; project not yet complete.

8.

MEASUREMENTS. Unknown; project not yet complete.

9.

RELIABILITY. Unknown; project not yet complete.

on

our

Pascal

;;0

We have not heard any news from either of the following two implementors for over two
years, in spite of several attempts by us and others to reach them.

P. J. Voda, Computing Research Centre, Dubravska 3, 885 31 Bratislava, Czechoslovakia, has
(not the
using it.

same

concurrent

constructs

as Brinch Hansen's), and several large software projects were implemented

Lou Beverino, Computer Center, California

State

University,

Northridge,

CA

91324,

is

known to have received Pascal-P2.

10. DEVELOPMENT METHOD. The compiler is written in Burroughs Extended Algol and
B6700 machine code. (* Person-hours to create compiler not reported. *)

generates
CDC 3600

11. LIBRARY SUPPORT. (* No information provided. *)
This 1s another case of the "two-year silence" (see CDC 3300). You are welcome to try
contacting Marcel Dupras, Institut de Programmation, Tour 55-65, l1-Quai Saint Bernard,
F-75 Paris,
France,
who
was listed by George Richmond as having completed an
implementation on the 3600.

CDC Cyber 18 and 2550

1. IMPLEMENTOR/DISTRIBUTOR/MAINTAINER.
Jim
Fontana,
3519 W. Warner Ave., Santa Ana, CA 92704 (714/754-4102).
2.

MACHINE. Control Data Cyber 18 and 2550.

rn
rn

a version of Pascal operational on the 3300. This version includes

STANDARD. (* No information provided. *)

-l

o:l

CDC 3300

MAINTENANCE. None, project not yet complete.

7.

rn
--0

3:

5. DOCUMENTATION.
We
are currently (77/1/17) preparing a report
implementation. (* Not known if this will be machine retrievable. *)
6.

A local rumor is that John Urbanski, West Bank Computer Center, 90 Blegen Hall,
University of Minnesota, 269 19th Ave. South, Hinneapolis, MN 55455 USA (612/373-3608),
is working on an implementation of a subset of Pascal for the CDC 3200.

Control

Data

Corporation,

CDC 6000, Cyber 70, Cyber 170 (Zurich)
CDC 7600, Cyber 76 (Manchester)
1.

IMPLEMENTOR/DISTRIBUTOR/MAINTAINER.
Distributors:
-(Europe, Asia, or Africa)
Urs Ammann
(* same address as implementor *)
-(North or South America)
George H. Richmond
Computing Center: 3645 l-larine St.
University of Colorado
Boulder, CO 80309 USA
303/ 492-8131
-(Australia, New Zealand, or Oceania)

Carroll Morgan
Basser Dept. of Computer Science
University of Sydney
Sydney, N.S.W. 2006
Australia
629 1122
2.

(* See announcement elsewhere in this issue. *)
Implementor:
Urs Ammann

1. IMPLEMENTOR/DISTRIBUTOR/MAINTAINER. This compiler is essentially the Pascal 6000
compiler modified to fit the 7600 and Cyber 76 machines. The run time system is based on
that of Hans Joraanstad at CERN, Geneva, Switzerland (see Pascal News #4). Improvements by
H. D. Ellison; A.P. Hayes; UMRCC; Oxford Road; Manchester M13 9PL; England, U.K.; (061-273
8252).

Institut fur Informatik
Eo T• H. -Zent rum
CH-S092 Zurich
Switzerland
01/ 32 62 11
Maintainer:
John P. Strait / Andy Mickel
227 Experimental Engineering Bldg.
208 SE Union St.
University of Minnesota
Minneapolis, MN 55455
USA
612/ 376-7290

3.

SYSTEM CONFIGURATION. SCOPE 2.1.3, 32K SCM.

4. DISTRIBUTION. Contact R. J. Collins at address above. A distribution aggreement must
be Signed and the cost is 50 pounds sterling.
5.

together on a common release for Release 3.

3.4

and

Tape format is Scope 3.4 internal binary, 7 track, unlabelled, 800 bpi.

Specify: person responsible for mainta-ining the system. your hardware,

operating

system,

and character set (ASCII or Scientific, 63 or 64). From Switzerland cost is S.Fr. 100
(includes cost of tape; do not pay in advance, you will be billed); from Colorado cost is
$60 for new recipients (includes tape and documents), and $35 for old reCipients (includes
tape but not documents); from Australia cost is $A30 (tape and documents). New
installation notes will be machine retrievable in Release 3.
5. DOCUMENTATION. Machine retrievable supplement to Pascal User Manual and Report and
documentation of library support package will be available with Release 3.
6. MAINTENANCE. Will accept bug reports at Minnesota for
issue Release 3 in 1978.

forseeable

future.

DOCUMENTATION. Same as Pascal-6000.

6. MAINTENANCE. The situation is unclear at present. UMRCC will assist with bugs
in
the 7600 dependant code (runtime system) only. Currently UMRCC and Minnesota will work

MACHINE. Control Data 6000 series, Cyber 70 series, and Cyber 170 series.

DISTRIBUTION.

MACHINE. Control Data 7600 & Cyber 76.

University Computer Center

3. SYSTEM CONFIGURATION. Minimum central memory-49K words. Operates under Scope
Kronos 2.1.
4.

2.

Expect

to

7. STANDARD.
Nearly full standard. Restrictions include: standard procedures and
functions cannot be passed as actual parameters; file of file is not allowed. Extensions
include: additional predefined procedures and functions; segmented files.
8. MEASUREMENTS. Compilation speed:
10500 characters per second on a Cyber 74; 54
seconds to compile the compiler. Compilation size: 46K (octal) words for small programs;
57K for self-compilation. Execution speed: see 7600 statistics, below. Execution size:
binaries can be as small as 2.4K, compared with Fortran minimum of over 10K.

7.

STANDARD. Same as Pascal 6000.

S. MEASUREMENTS. Compilation speed is about 57,000 characters/sec. Compiler compiles
itself in less than 10 sec. Pascal execution speed has been measured by using the obvious
encoding in Pascal of Wichmann's Synthetic Benchmark (see Computer Journal Vol.

no runtime

-------------------------------------------------------ALGOL 4 (OPT-5)
1996
Pascal
FIN (OPT-2)

-------------------------------------------------------* Using T+ option--all run time checks included.

** Forces OPT-O.
Compiler will recompile itself on a 'half-size'(32K
prOVided on size of compiler or object code produced. *)

routines

in

SCM) machine. (* No information

9. RELIABILITY. 3 sites; as reliable as Pascal 6000 (Zurich). (* Date
not reported. *)
10. DEVELOPMENT

METHOD.

Cross

cOClplled

from

Cyber

72

not reported. *)

(* See implementation notes for IBM 360/370. *)

of

first

release

compiler. Based on Zurich 6000

compiler with necessary additions for this machine. (* Person-hours

CDC Omega 4So-I, 480-11

many

1230
6240*
3174**

6850
945

10. DEVELOPMENT METHOD. Bootstrapped from the original Pascal-6000 compiler, but developed
in a 6 pha~e stepwise refinement method. Approximately 1.5 person years.
contains

array bound
checking

checking

11. LIBRARY SUPPORT. Same as Pascal 6000.

(FTN) subprograms. The user library supplied with the system
addition to the standard.

#1).

------------------------------------

compiler and
optimisation level

9. RELIABILITY. Excellent. The compiler is in use at 139 known sites. First version of
this compiler was operational in late 1970. The present version was first released in l-lay
1974.

11. LIBRARY SUPPORT. Allows calls to external Pascal and assembler subprograms and Fortran

19,

The Units are in kilo Whetstones.

to

develop

compiler

CII IRIS 50 (Nice)

CDC STAR-100 (NASA)

National Aeronautics and
Space Administration

NI\S/\

Langley Research Center

2.

Hampton Virginia

23665
Replv to A\\'l or

1. IMPLEMENTOR/DISTRIBUTOR/MAI~TAINER. Olivier Lecarme; Unlversite de Nice; Laboratoire
D'informatiquei Parc Valrose, 06034 Nice Cedex; France (51 91 00).

JUN

125A

~A

1977

MACHINE. CII IRIS 50.

:z:

3. SYSTEM CONFIGURATION. Siris 3 operating system. (* Minimum hardware
known. *)

requirements

not

Dear Andy:

4. DISTRIBUTION. (* Unknown, project not yet complete. *) Expected to be available by end
of 1977.

This is to inform you that a PASCAL implementation has been completed
for the CDC STAR-100. The details are:

5.

DOCUMENTATION. (* No information provided. *)

6.

MAINTENANCE. (* Unknown, project still underway. *)

1.

Implementors:

Douglas D. Dunlop
Dept. of Mathematics
College of William & Mary
Williamsburg, VA 23185
John C. Knight
Analysis and Computation Division
NASA Langley Research Center
Hampton, VA 23665

7.

STANDARD. Will implement exactly Standard Pascal.

8.

11EASUREMENTS. (* Unknown, project not yet complete. *)

9.

RELIABILITY. (* Unknown, project not yet complete. *)

10. DEVELOPMENT

METHOD. Various approaches tried. Tool compiler developed using Pascal-P,

Pascal-E subset, intermediate machine oriented languages, and

2.

Language:

The PASCAL p4 subset of PASCAL.

3.

Machine:

Control Data Corporation STAR-lOa.

4.

Operating System:

STAR O/S.

5.

Documentation:

At present, only the compiler listing.

6.

Reliabili ty:

Compiler correctly compiles itself.

7.

Distribution:

No formal mechanism.

the

Nagel

trunk

compiler

used to write a true compiler. (* Person hours to implement system not reported. *)

11. LIBRARY SUPPORT. Will produce modules for the
provided on external and other language subroutines,
source inclusion, or symbolic post-mortem dumps. *)

linkage editor. (* No information
separate compilation, automatic

ell 10070, IRIS 80, XDS Sigma 7 (Pa-ris)

Write if you are

interested.

1.

8.

Implementation:

The compiler was developed from PASCAL p4.
Two forms exist and both compilers generate
STAR machine code. They are a 6000 based
cross compiler which produces object Modules
for input to the STAR loader, and a STAR
resident compile and execute system.

2.

Our experience with PASCAL p4 has been very satisfactory and we congratulate the developers. In less than six man weeks of effort, the
PASCAL p4 compiler was modified to generate STAR-lOa machine code,
and the compiler which was produced successfully compiled itself on the
STAR-lOa.
Sincerely,

Distributor:

Didier Thibault
17 rue GAY-LU55AC
F-75005 Paris FRANCE
527 6 85

Pierre Maurice
UER d'informatique-Universite Paul Sabatier
118 route de Narbonne
F-31077 Toulouse FRANCE
(61) 53 11 20 x300

MACHINE. CII 10070; CII IRIS 80;

~)S

Sigma 7.

3. SYSTEM CONFIGURATION. SIRIS 7 & SIRIS 8 (CII operating systems; also easily available
on other operating systems, see implementation description.)
4. DISTRIBUTION. Compiler source and assembler code are available on magnetic tape
Just send a tape (mini if possible) to distributor.
5. DOCUMENTATION.
retrievable. *)
6.

~hn C. Knight
Aerospace Technologist
Programing Techniques Branch

IMPLEMENTOR/DISTRIBUTOR/MAINTAIN~R.

Implementor:

7.

Users

free.

Manual (in French); Sept. 1975. (* Not known if this is machine

MAINTENANCE. Maintained from July 74 thru Jan 78.
STANDARD.
Full standard with following extensions:
-separate compilation of Pascal program
-symbolic post mortem dump of variables & procedure in case of abort at execution time
-'value' feature for initialization of variables

rn

-'packed' variables implemented
-extensions to 'read' and 'write' for use in an interactive environment
8.

8.

MEASUREMENTS. (* No information provided. *)

9. RELIABILITY. Very good. (* Number of sites
released not reported. *)

MEASUREMENTS.
compilation speed--1800 Pascal lines/min.;
2400 characters/sec; versus
1200 characters/sec. for FORTRAN.
compilation space--to run the Pascal system:
30 K words with overlay;
45 K words without overlay.
execution speed--dependant on program profile; compared to FORTRAN:
FORTRAN
Pascal
matrix multiplication
1
1.6
recursive program
1
0.3
character count on file
1
0.2
execution space--(* No information provided. *)

using

system

not

reported.

10. DEVELOPMENT METHOD. Seven pass compiler. (* Method of developing
reported. Number of person-hours to implement compiler not reported. *)
11. LIBRARY SUPPORT. Automatic formatting option implemented. (* No
on separate compilation or subprogram libraries. *)

Date

first

compiler not

information

provided

rn
:::;::
(/)

CRAY-l (Los Alamos)

9. RELIABILITY. Good to Excellent. This is release 3 of this compiler. The
been tested since 1974 in 30 installations.

compiler

has

UNIVERSITY OF CALIFORNIA
LOS ALAMOS SCIENTIFIC LABORATORY
(CONTRACT W-7405-ENG-36)

10. DEVELOPMENT METHOD. Full compiler generating object code for the linkage editor.
The compiler consists of
a MONITOR: programmed in CII's local assembly language (2K 32-bit words).
It links the Pascal program to the operating system and controls the
execution of the Pascal program.
All operating system dependancies
are located in this moniter.
To get the compiler available on some
other operationg system,the rewriting of this moniter is neccessary.
a COMPILER: written in Pascal itself, it consists of 4800 lines. It is a
one pass compiler with top-down syntax analysis, separate compilation
of Pascal programs, symbolic post mortem dumps, and several specific
options.
The compiler is fully bootstrapped so that any user may
adapt it easily to a specific need (change the table sizes, specific
features, etc.).
a LIBRARY used by the linkage editor.
(* Person-hours -to create compiler not reported. *)
11. LIBRARY
SUPPORT.
Separate compilation
information on subprogram libraries. *)

of

Pascal

programs

implemented.

P.O. BOX 1663
LOS ALAMOS. NEW MEXICO 87545

IN REPLY
REFER TO:

C-11

MAIL STOP:

2':1 b

Jilly '(,

1T11

Dear And y:
(/)

rn
Despite I)ob J~hnson's rather discoura~ing letter, (~AS­
CAL Newsletter '6), PASCAL still lives on the CRAY-1. We n~w
tl8ve a new version based on Sassan Haze~hi's P-corie Post Processor concept (P.~. 07). Current plans are to extend P-code
and the P-code translator to provide cede ~enerati0n f"or the
(*

I';odel compiler.

No

""0

-;

rn
:3:
ttl

rn
:::0

I enclose an 11-point Mewsletter-style descrintion of
our impleolentation, the User's Guide Addendum, ~nd ~V check
for $~ i'or next year's P.U.G. membership.

Computer Automation LSI-2

1. IMPLEMENTOR/DISTRIBUTOR/MAINTAINER. Computer Automation; Naked
Von Karman; IrVine, CA 92713; 714/ 833-8830; TWX:910 595 1767.
2.

Mini

Division;

18651

MACHINE. Computer Automation LSI-2 (16-bit minicomputer).

3. SYSTEM CONFIGURATION. Computer Automation OS. Minimum hardware: moving head or floppy
disk and 32K Memory.
4.

DISTRIBUTION. Distributed on floppy disk for $900.

5. DOCUMENTATION. User's Guide explaining the use of Pascal under CA-OS. (* Apparently no
machine retrievable documentation. *)
6. MAINTENANCE. Fully supported including acceptance and response
reports. In the near future, standard Pascal I/O will be implemented.

to

user

trouble

7. S~~DARD. Implements Sequential Pascal which varies from standard Pascal. Missing:
reserved words file, goto, label, packed; mixed type arithmetic; standard functions: ODD,
EOLN, EOF, SQR, ROUND, SIN, COS, ARCTAN, LN, EXP, SQRT. Restricted to 2 levels of static
nesting. Has extended 1/0 and file access methods.

1.

Implementors:
The compiler was bootstrapped by John Montague and
Michael Powell. Many of the code templates were taken
from Bob Johnson's cross compiler. Nearly all changes
and improvements since the bootstrap was completed are
due to Forest Baskett and Linda Zucconi. We can all be
reached at the following address:
Los Alamos Scientific Laboratory
Group C-11, Mail Stop 296
P. O. Box 1663
Los Alamos, New Mexico 87545
(505) 667-7877

'J
00

2.

2.

Machine:

Most of the programs we have compiled were first debugged with PASCAL-6000, so error recovery hasn't really been tested.
The P-compiler has had quite a bit of
use at Stanford. No errors in the generated code have
been detected for several months, and we have compiled
and executed John Banning's 10,000 line PASCAL Analyzer
program (PASCAL Newsletter '6).

Cray Research, Inc. CRAY-l
}.

Operating System:
Benchmark Operating System (BOS), a LASL modified
sion of the CRI CRAY-OS Version 1.

4.

10.

Distribution is arranged on an ad hoc basis.
(both) current CRAY-l installations have -a copy.

2'

All

PASCAL

Maintenance:
We will maintain CRAY PASCAL at LASL as long as we find
it useful.
The compiler is still undergoing development, and new versions will probably be complete replacements rather than updates. A project is underway
to use the P-code translator as a code generator for
Model, a LASL-developed language which will be used for
much of our new CRAY-l operating system.

I·

July 7, 1977
ALGOL-W, PL/C, and Sassan Hazeghi's PASCAL-P compiler)
and are experienced system programmers. Neither implementor had ever used a CDC 6600 or a CRAY-l, or written
large PASCAL programs before the project started.
Subsequent development has been done using a PDP-11/70
running UNIX, with a link to the CRAY-l for compilation
and testing.

Standards:
CRAY PASCAL implements the. subset of PASCAL defined by
the PASCAL-P compIler wIth a few extensions toward
Standard PASCAL and several of the PASCAL-6000 predefined functions and procedures.

8.

Method of Development:
CRAY PASCAL was bootstrapped using PASCAL-P and PASCAL-6000.
A total of 5 machines (CDC 6600, Cyber 73,
7600, Data General Eclipse, and the CRAY-l) and 3 character sets were involved in the bootstrap process. Approximately 6 man-months were required. Both implementors have previously modified batch OS/360-370 compilers to run interactively under ORVYL/370 (including

Documentation:
Short write-up on the differences between CRAY
and Standard PASCAL, plus instructions for use.

6.

ver-

Distribution:

Reliability:

Compiler Implementation:
CRAY PASCAL is written in PASCAL and consists of two
separate programs, the PASCAL-P compiler (version 2
extended by Sassan Hazeghi of Stanford University t~
the equIvalent of P4, and further modified at LASL) and
the P-CODE translator which converts P-CODE into CRAY
Assembly Language (CAL.)
Despite some character set
problems, both programs currently run on the CRAY-l and
on a CDC 6600 under NOS.
Some statistics on our implementatIon are:
Lines of source code
P instructions generated
CAL instructions generated
Size of code (64-bit words)*
Compile, translate,
assemble time (CPU sec.)

P-compiler
4400
23,500
38,100
18,200
43

Translator
3900
19,100
36,500
18,400
40

* this includes the run-time package
The compiler and translator run-time are currently domInated by the character by character 1/0 (about 50% of
the total time).
One of our current projects is
dIrected toward improving the run-time support.

11.

Libraries, External Compilation, Etc.
No libraries are currently available or
planned.
External procedures (declared as FORTRAN, though actually requiring PASCAL calling conventions) are supported and have been used. Limited separate compilation is
supported by allowing second level procedures (procedures declared in the PROGRAM block) to be entry
points.

Data General Nova/Eclipse -- Introduction.

Since the announcement in PUGN 8 of a Data General implementation by R. E. Berry,
we've witnessed a lot of activity this summer. As an experiment. we are going to try to
get everyone together here!

Thanks to Rodney Thayer, Central Research Group, P.O. Box 451, Harvard, MA 01451
(617/772-2306) "ho "rote 77/07107: "a few people in my area (myself included) are
investigating R. E. Berry's U. of Lancaster PASCAL for the Data General NOVA. If I am
closer than England for somebody, they are welcome to

write

to

me

to

find

out

about

Lancaster Pascal."
On 77/8/12, Gregg Marshall at the National Oceanic and Atmospheric Administration in
Denver, CO 80200 (303/499-1000 x4482) wrote out a checklist for the Lancaster NOVA Pascal
implementation, "in case they haven't sent one, too. 1I (They hadn't.) Its information is
included in the summary below.
Other NOVA implementations have appeared by Ted Park, A. J. Hurst, and Rafael Bonet -

see below. H. S. Magnuski, Gamma Technology, 800 Welch Road, Palo Alto, CA 94304
(415/326-1661), wrote on 77/7/21 that he is trying to obtain several NOVA implementations
for evaluation. Hopefully he will report his findings to PUGN. On 77/8/9, Bruce 11acKenzie,
Computervision Corp., 201 Burlington Road, Route 62, Bedford, MA 01730 (617/275-1800),
announced that "we will be implementing Pascal on Data
compati.ble machines running under our own operating system •. "

General's

NOVA's and NOVA

Also, Larry Iialsh, ROLM Corp., 4900 Old Iron Sides Drive, Santa Clara,
(408/988-2900) is looking at Pascal-P for the ROLM 1664, a ruggedized NOVA.

CA

95050

-0

J:>

received from George Richmond at the University of Colorado
was quite complete and bug free. I was able to have the compiler
compile itself correctly after less than one man-month effort.
All-in-all, I am very satisfied with the results.

Requests for Data General implementation information have come from:

77/07/11: Doug Kaye, Computer Services, Du Art Film Labs, 255 Ilest 55 St., New York,
NY 10019 (212/757-4580).
77/07/14: Mike Tiller, 2501 N. Lancaster Lane #178, Plymouth, MN 55441 (612/546-6687).
77/06/08: C. A. Miller, Dept. of Physics Nuclear Res. Center, University of Alberta,
Edmonton, Alberta T6G 2N5.
77/08/10: Kevin Driscoll, 330 SE 11th Ave., Minneapolis, MN 55414 (612/331-2133).
77/08/16: Bruce K. Ray, Polymorphic Computer Systems, P.O. Box 3581, Boulder, CO 80303
(303/443-5362).
77/03/14: Wayne Seipel, James Peterson, Computer Science Dept., University of Texas,
Austin, TX 78712 (512/472-1773).
-Andy Mickel

Old address:
Ted C. Park
Scientific Computation Facility
Lorna Linda University

Lorna Linda, CA

Ted C. Park
Technical Specialist

LOMA LINDA UNIVERSITY
June 3, 1977

1894 Commercenter West

cc: George Richmond

LOMA LINDA CAMPUS
LOMA LINDA, CALIFORNIA 92354

SClENTIFICCOMPUTATION FACILITY

=

New address:
Ted C. Park
Medical Data Consultants
Suite 302

TCP:map

Data General ECLIPSE (Loma Linda)

92354

San Bernardino, CA
714/ 825-2683

92408

The Scientific Computation Facility is a Biotechnology Research
Resource supported in part by NIH grant RR 00276.

Dear Andy,

Data General NOVA (Canberra)
I thought this might be the first, but I see from the latest
newsletter that at least one other Data General version exists.

THE AUSTRALIAN NATIONAL UNIVERSITY

However, I would like to report another Pascal P4 system solely
designed for the Data General Eclipse Series computers with
floating point hardware (since the Eclipse enhanced instruction
set is heavily used, my Pascal will not run on a Nova).

DEPARTMENT OF
BOX

To ease the implementation, I used a single size data unit
64-bits for everything. A virtual memory (paging) scheme is
employed so that the system will run in almost any memory
confi gura ti on.
The assembler for PCODE and interpreter are both written in DG
assembly language. I am quite pleased with the speed of the
system, it takes something over an hour to compile the compiler
(-4000 lines of code). This is only 4 times slower than th~
vender supplied FORTRAN compiles! (And the Pascal system 1S
interpreted with software paging!!)
The specifications of the system are as follows:
worksize =
64 bits
memory size
64K words
integer size = 32 bits used in all calculations (64 bits stored)
64 bits
real size =
I have implemented the entire interpreter except the transcendental
functions and the I/O of 'real' data. The transcendental functions
are, at present, of little interest so I may be several months
before implementing these. I/O of 'real' data is needed, I am
working on it and will have it ready in a couple of weeks.

2600
C/)

rn
-u

22 June 1977

I would be willing to disperse DG compatible dumps of the system

to interested users who supply their own mag-tape. I am not
in a position to supply documentation, so interested parties
would· still need to get the implementation kit from the University
of Colorado.

Computer Science

4, POST OFFICE, CANBERRA, A.C.T.

Dear Andy,

-I

The department of Computer Science, Australian
National University, is implementing PASCAL-P for a Data

rn
3:

to
rn
;::0

General NOVA from the Zurich P-4 portable compiler.

The

system is intended for cafeteria style student use and
will require processor + 32K memory, disk, card reader and
line printer as a minimum hardware
under RDOS.

configuration, and runs

It is not intended at this stage to distribute

the system, but interested people may write to A.J. Hurst,
Department of Computer Science, ANU, Post Office Box 4,
Canberra, A.C.T. 2600, Australia.

The estimated completion

date is late 1977.
-u
~

Gl

rn

I have read several comments in the PUG newsletter indicating
how many people perceived the bootstrapping process as being
rather difficult -- indeed, the implementation kit seemed to
indicate this also. I would like to offer my encouragement to
those who try by pointing out that the implementation kit we

00
<::)

John Hurst

tG:,~~':'~~(iCi'u 51' Q.
ordenadores eleclronicos

Data General NOVA 840 (Barcelona)

rocofort, 98· 100

'ole!. 1931 3854100
telex 53095
barcelona· 15

5 June 1977

Dear Mr.

Pascal User's Group

Mick~l:

I have received Pascal Newsletters
#5 and
#7 on the same enclosure from the University of Southampton, Great Britain. What
about
*67.
My company, SECoINSA-TEL~SINCRo is a holding owned by the spanish
government for the development of the national computer lndustry.
We bought CALTECH'S SOLO SYSTEM to experiment it as a software
tool running in the DGC'S NOVA B40 at the research & development
department. The NOVA is used as a software factory.
Enclosed is a short report about our ·implementation. Sorry but
distribution is not planned.
I have personnel interest in PASCAL, sO the address in the PUG
mailing list is my home address. My office addre~s is the impl~
mentors' address below e

Minimal Hardware Configuration:

CPU options: Floating Point Unit
Automatic Multiply/Divide Unit
Real Time Clock
Memory Map&Protection Unit (MMPU)
Memory
44Kw, minimum
Disk
DIABLO model 33 (2.5MBytes)
AMPEX model DM44B with western Peripherals Interface
Tape
WANG CD BOD bpi, 9tracks, 45 ips
Printe'r
TALLY 200 Ipm with Data Products Interface
Card Reader: DOCUMATION 600 cpm with Documation Interface
Console
Standard
Also supported by the system:
Second Console
4060 Multiplexer
as much memory as supported by the MMPU
4.- Method of distribution:
The SOLO SYSTEM and its distribution is not a company objective. Thus, we have no plans for distribution. But we shall
study each request of a system copy.
5.- Documentation available:

Our system is an implementation of the CALTECH'S SOLD SYSTEM.
The languages description is given in two CALTECH Manuals:
- Concurrent PASCAL report.
- Sequential PASCAL report.

Sincerely yours:

/!\~
~ \
RMB/tg
cc: P. Brinch Hansen
1.- Implementors:
Rafael M. Bonet
Arsenio Lago
Ram~n Cervell~

TELESINCRO S.A.
Departamento de Investigaci~n y Desarrollo
Rocafort 100
Barcelona 15
SPAIN
Phone: (93) 3254100
2.- Machine:
Data General Corp. NOVA B40
3.- Operating System:
SOLO SYSTEM

\Rafael M. Bonet

\

=

rn

The system works in interpretive mode. The NOVA interpreter,
an assembly program, is documented in spanish.
6.- Maintenance:

The high level coding (CPASCAL or SPA5CAL) was writen at the
CALTECH by Per Brinch Hansen's team. Neither CALTECH nor Per
Brinch Hansen (now at the 50uthern California University) pr£
vide maintenance for this software.
The low level coding (the NOVA interpreter) is responsibility
of our team, but our structure does not allow a formal maintenance. Of course, we accept error reports.
7.- 5tandards:
CALTECH sequential PA5CAL is not a standard PA5CAL implementation as you can found in the CALTECH report.
B.- Compiler /

Interpreter:

The system is interpretive. The only potion in target machine
code is an assembly program, called the kernel, with a size
of 5K words of 16 bits. The PA5CAL interpreter, included in
the kernel is 2 K words long. The 50Lo 0.5. runs interpretively and is coded in Concurrent PASCAL. The SOLD runs seque~
PA5CAL programs. The compilers speed is about 90 char/sec.
9.- Reliability:
The kernel reliability is excelent.
For the compilers, some not important bugs were detected. S£
me of them were fixed. In general the reliability is good.

en
rn

-c
-I

rn
3:
i.:;O

rn
:;:0

4.

10.- Development method:
,he tapes from CALTECH were used to implement a bootstrap soLO SYSTEM running under DGC'S Real Time Disk Operating System.
Then we developed our stand-alone SOLO SYSTEM.
The system can produce a backup tepe. This tape is loaded
into disk by means of the IPL operation and an AUTOLOAD program
writen at the begining of the tape.
Once the tape on disk the system is loaded by IPL.
For the people interested only in sequential PASCAL:
it is posible to write an interpreter (or compiler) of seque~
tial PASCAL, changing the SYSTEM CALL instruction from a
branch to concurrent code to the actual execution of the fun£
tion required. As Per Brinch Hansen says, it is a 1 man month
work, but it doesn't exist a documentation about how to doit.
Data General NOVA (Lancaster)

1. IMPLEMENTOR/DISTRIBUTOR/MAINTAINER. R. E. Berry and A. Foster; Dept. of Computer
Studies; University of Lancaster; Bailrigg, Lancaster LAI 4YX, U.K.; 65201 (STD 0524).
2.

MACHINE. Data General Nova series (2/10, 820).

3.

SYSTEM CONFIGURATION. RDOS 4.02/5.00 operating system; 32K core, disk backing store.

4.

DISTRIBUTION. Cassette tape or 2.5 Mbyte cartridge disk.

5.

DOCUMENTATION. A user manual is provided.

6. MAINTENANCE. No formal commitment to provide support; Release 2 under development and
will subsequently be consolidating bug reports accepted on Release ~.
7.

STANDARD. Pascal P4 subset accepted.

10. DEVELOPMENT METHOD. Originally
was written from scratch in Pascal;
assembly language.

not

reported.

cross-compiled from a CDC 7600. The P-code assembler
the P-code interpreter was implemented in Nova

DEC PDP-8 Minnesota

1. IMPLEMENTOR/DISTRIBUTOR/MAINTAINER. John T. Easton, 612/373-7525; James F. Miner,
612/373-9916; Jonathon R. Gross, 612/835-4884; Address correspondence to: Pascal Group;
SSRFC; 25 Blegen Hall; University of Minnesota; 269 19th Ave. South; Minneapolis, MN
55455; 612/ 373-5599.

3.

6.

(about

MAINTENANCE. A policy has not yet been determined.

7. STANDARD. Emphasis has been placed on close adherance to the Pascal User Manual and
Report. There are two major restrictions: a) Parameters may not be procedures and
functions. This restriction will not be lifted without full type checking (which requires
a change in the Pascal Standard). b) Files may be declared only in the main program, and
files may not be components of arrays, records, or files; nor may files be allocated with
the procedure NEW. Minor restrictions: set size-96 elements; maxint-8,388,607 (2**23-1).
Full ASCII character set is supported.
8.

MEASUREMENTS.
Execution speed--roughly comparable to FORTRAN IV (F4). I/O seems to be
faster than FORTRAN, while computation seems slower.
Execution space--Interpreter takes 12K, space needed for P-code and runtime storage depends on program.
Compilation speed--much slower than F4. We hope to make some improvements
in this area. About 30 characters/sec. presently (77/07/30).
Compilation space--65K 12-bit words to compile itself.

9. RELIABILITY. Fair to good and improving. The system is has been in use at 1 site since
76/11.
10. DEVELOPMENT METHOD. As with most languages on the PDP-S, Pascal makes use of an
interpreter (a modification of P-code) written in PAL8. The compiler (about 5400 lines,
based on Pascal-P4) and assembler are written in Pascal. All standard procedures are
written in PAL8. Because of the design of the system, the implementation is not suitable
for real-time applications. On the other hand, the implementation does provide 131K words
of virtual memory for code and store. Effort involved has been 1 person-year for
applications programmers without previous experience writing compilers.

Digital Equipment Corporation (DEC) PDP-II -- Introduction

Date

11. LIBRARY SUPPORT. (* No information provided. *)

2.

5. DOCUMENTATION. Machine retrievable supplement to Pascal User Manual and Report
25 pages), in preparation.

11. LIBRARY SUPPORT. Currently (77/07/30), none.

8. MEASUREMENTS. Typical runtimes compare favorably with those of other languages
generally available on the Nova. P-code is generated, assembled and then interpreted.
(* Compilation and execution space requirements not reported. *)
9. RELIABILITY. (* Thought to be good. Number of sites using system
first released not reported. *)

DISTRIBUTION. Not yet ready for release.

MACHINE. Digital Equipment Corp. PDP-8/e
SYSTEM CONFIGURATION.
OS/8 version 3. Hardware required:
-KE8-E (EAE with mode B instruction set)
-RK8-E disk, or other direct access mass storage device with at least 131K 12-bit words
(e.g., DF32 or RF08).
-16 K minimum of core/RAM. 32 K is highly recommended.

At one time last year (PUGN 6-7) Steven Schwarm and C. E. Bridge at DuPont wrote to
say they were coordinating a DECUS SIG Pascal. W~ thought they would coordinate PDP-II
implementations. Well, they haven't, and they have not been communicating either. We've
heard that DEGUS SIG Pascal is in other hands.
Interest in PDP-II Pascal has been high. But from our point of view there are far too
many Pascals on the 11 to wade through.
A few comments: Electro Scientific Industries Pascal for the 11 has received another
good report - see the letter from Wayne Rasband. Structured Systems has come up with an
implementation which runs on many operating systems including UNIX. The highest quality
RSX-ll system we've had reports on comes from Stockholm. Finally, we have news of UNIX
Pascal from U.C. Berkeley.
Jim Shores, with the US Navy in Connecticut, phoned on 77/05/24 and reported he had a
Brinch Hansen interpreter running as a task under RSX. Also he phoned Bob Lucas at NBS in
Maryland and found out that Bob doesn't think too much of his own RSX implementation. With
all the others around now, that's okay.
See also HERE AND THERE News section under David Miller,
Nunnally, Alfred J. Hulbert, Martin Tuori, and Aron Insinga.
-Andy Mickel

Matli

Karlnen,

John

7. STANDARD. Full standard plus extensions: additional features for real-time hardware
control; separate compilation of procedures; Macro (assembler) code in line insertion;
actual core addresses of variables can be fixed (giving access to eKternal page 1/0
addresses at the Pascal level.

DEPARTMENT OF HEALTH, EDUCATION, AND WELFARE
PUBLIC HEALTH SERViCE
ALCOHOL, DRUG ABUSE, AND MENTAL HEALTH ADMINISTRATION
NATIONAL INSTITUTE OF MENTAL HEALTH
9000 ROCKVILLE PIKE
BETHESDA. MARYLAND 20014

July 14, 1977

AREA CODE 301

TEL,656....4000

I suspect that readers of the PASCAL Newsletter may get the impression
that there does not exist a reliable standard PASCAL compiler for the
PDP-II that is useful for production work, but from our experience this
is simply not the case.

ESI PASCAL has also proven more practical for use on small PDP-II configurations, such as a 16K llV03 with dual floppy disks, because it requires less memory and disk space. The ESI compiler (written in MACRO)
is half the size of DEC's FORTRAN compiler and the PASCAL run-time support
library is one-third the size of the FORTRAN library.

",~

//

DEC POP-II (ESI)

1. IMPL&MENTOR/DISTRIBUTOR/tiAINTAINER. John Ankcorn; David Rowland; Electro-Scientific
Industries; 13900 NI, Science Park Dr.; Portland, OR 97229'; 503/ 641-4141; TELEX: 360273.
MACHINE. Any model Digital Equipment Corp. POP-II.

3. SYSTEI1
CONFIGURATION.
Minimum of 16K words.
(76/11/02), an RSX-IIM implementation is underway.

Operates

under

RT-ll.

DISTRIBUTION. Compiler, support module, cross referencer, text editor and

Currently
instruction

manual available for $1500. (* Tape formats, etc. not reported. *)

6.

3000 line programs

in

z
rn

machine

retrievable

instruction

i\ worst-case

manual.

MAINTENANCE. One year of unlimited fixes and updates, followed by annual

Currently

subscription

service. (* Reported by users that IIvendor seems to be re'sponsive in terms of support". ,II)

~

"number-cruncher'

U>

example ran at 40% faster than the DEC original FORTRAN.
execution space--very economical-much

of the space improvement

over DEC

FORTRAN is due to the smaller support module for Pascal.
9. RELIABILITY. Excellent--far better than DEC FORTRAN. In use since 75/11.
sites using compiler not reported. *)

(*

Number

of

10. DEVELOPMENT METHOD. Single pass recursive descent compiler written in Macro-il.
Hand-coded based on University of lllnois bootstrap (with extensive changes) in about two
person-years of effort. First compiler written by both implementors. Compiler translates
source into l1acro-ll which is then assembled and linked to the support module for
execution.

11. LIBRARY SUPPORT. Separate
linkage is implemented.

compilation

of

procedures

with load-time insertion and

DEC PDP-ll (Los Altos)

structured
systems

corporation

"/r"": 7 ,""{,

Wayne Rasband
Section on Technical Development
National Institute of Mental Health
Bldg. 36, Rm. ZA-03
Bethesda, Md. 20014
301-496-4957

page

faster than DEC BASIC.

.:: $

Sincerely,

5. DOCUMENTATION.
Over 70
(76/11/02) working on more.

compilation space--very economical-it can compile

We are using the compiler from Electro Scientific

Industries (ESI) under the RT-ll operating system on five different PDP-II
systems (11/03, 11/04, 11/20, 11/34, 11/40) for real-time laboratory
applications and image processing. We have found ESI PASCAL better suited
for process control type applications than the DEC FORTRAN. It generates
in-line as opposed to threaded code. It allows direct aCcess to I/O device
registers as opposed to requiring subroutine calls. It provides a more
efficient interrupt handling capability and allows insertion of assembler
language statements in-line.

4.

MEASUREMENTS.
compilation speed--About 3500 characters /second, on the PUP-II model 05.
28K on PDP-ll/40. No overlays are used in the system.
execution speed--about twice as fast as the DEC FORTRAN IV and many times

Dear Andy:

2.

8.

343 Second Street, Suite K
Los Altos, California
415

94022
321 8111

STRUCTURED SYSTENS CORPORATION is pleased to announce a new Pascal compiler for
the DEC PDP-ll. The STRUCTURED SYSTEMS Pascal compiler (PASCAL-SS) was designed
and implemented by the team of A. Ian Stocks and Jayant Krishnaswamy, who
previously developed the University of Illinois Pascal-ll compiler.

U>

rn
-0

--i

rn
:3:

to

rn
:::0

The PASCAL-5S compiler is itself written in PASCAL and is self-compilable. It
translates Pascal source programs directly into machine code. The language
implemented is closely based on Jensen and vlirth's revised report (1975) with
a number of language extensions and additional features aimed at large-scale
system development in a production environment. Versions of PASCAL-5S are
implemented or under development to run under the most popular PDP-ll operating
systems, including DOS, RT-l1, RSX-l1 and UNIX.
Many features have been incorporated into STRUCTURED SYSTTI~S PASCAL-SS which make
it one of the most powerful and convenient-to-use Pascal systems for a production
environment. Extensive compile- and run-time error checRing and reporting
features are incorporated in the compiler. Compiler '$' options include an
identifier cross-reference, automatic formatting/indentation of source listings,
conditional compilation of sections of the source, a macro-expansion pass (similar
to DEFINE in Burroughs Algol), and textual inclusion of library files in the
source stream. ~tensive object code optimization may be specified.
Programs and routines may be defined in separately compiled modules and linked
together. User-controlled overlays permit very large programs to be compiled and
executed under severe core constraints.
Anyone wishing additional information on PASCAL-5S should contact:
Martin Rattner
STRUCTURED SYSTEMS CORPORATION
343 Second Street, Suite K
Los Altos, California 94022
(415) 321-8111

00
I.N

DEC PDP-ii (Stockholm)

1 ( 01

'tockholer
19l1-('i-li~

)

rh~ COTI0iler ~ill De jistrituted at no CQst it
tapps are supolled for one or .ore 01 I"e follo~in~
choices:
-

- three DfCtaoes In P0P 11
-

The

ne~5lptters

alth0lJ~n

~re really lnterrestiGQ to reaa,
aistribution is somp~nat slow.

Ifonen the r-:'ay
J fou-nr:l that

the ;
J

'l'l

issue

ma,]netlc

tape

D05

tor~at

(ClC10

~"a

lr'l

\"ll 1\,

fOrTidt

(ut.t lv user-s)

- one y-tr~ck ~a'loetic taoe In inau9trv
(d s e r S 0 f
J; l ( 11! an j o t h f' reo 1. C V t ~ r s )
-

one

'I-track

!) 0

C U "1 E ~ T I~ T I Ut'f

~

LJ S ern

f'J1a-.Jnetic

tdpe

in' IJ( S,

PDP11 llsers)

c?wpati~le

forrrat

(tlUt-' 1 j

for~at

USe-fS)"

finallY a~;r;earp.C1 in the €nQ of July

1 had mixea un rr,y o"",n "GOreS5

pte IT! e n tat ion n ~ t e

enclose an

one -'I-track

update~

(j

esc. r i

t: ;

In

nc;o u r P () ~ 11 co fll rJi l e r ..

version.

AS you can also see, I have oeCl~e~ to dlstriLlute t~e
compiler ~yselt~ ~r Schwar~ ot nu Port have proMiseo
to dlstribute tl"l.ro99h DECU5, but I hHven't Iledrea anyt n l""·1
fro'!' hi~ yet.

~o

a r!J a l

co 'i'l~) l e II e n tin 9 the U(.- (. ':J

re~uansiniljt),

be distrihuted to

bJt 1t prrors are
users ..

~'O

0 k ..

toun~

rerorts

~ill

kno~n

lruly yours,

htSl~ICljO~S

Tne

fro-n

AL IX /l dc,

Stockholm,

Sweden

~r

the co~piler ~ener~tes stM~~ar0 o~Ject nodules
tne comoiler 9,veS full access to "aX tlle systpm
The lollowin~ llSt is T~l"ly a co~. lro. 1r 8ron's
cortribut10n in Pascal ~e~sletter ~7.
'"lth r"?lard to the ·-.,efinition of Fascol in t'ascal
lJser ~anuaL 8no ~eport the tollo~in9 restrictions hole:

2

DEC-lu: crosseompiler that Renerates eooe for
all PDP-Tl's.
P~P-ll: ~ouel j~
anj UP.
lhe
~nd

cO~Diler generates code for tlOAt1na ooint nardware
extended aritnmetic it option s~itches are set.

UPERATi~G

SYSTE~

MSX-ll~

or lAS. (DEC-1Q crossco~Diler under TuP~-lU).
PrObaDly it 15 an easy task to rpplace the AS.
interfacino routines .ith new ones intertac1ny DU,
or ~T-11. we ao not plan to dO that .or~ nere.
Maybe routines to interface with NS.-l1S .ill De made.

4

cO~Jiler

LJnljert3l(en:

Seveo Torstendahl
AdOress;
Telefon A~ L~ ~rlcsson
2~

EXTE~SIONS

is a mOjitlcat1on of tne crossco~uiler
Uron of T~ente 0niversity of TeChnology,
The Netnerlands. f~o Talor ~oci1ications hdJe neen

Severl TorstenCohl
101PlU'EHOR

S-'2~

~NU

llIST~It3UTION

Ine eO~Dilers are available at "0 cost if tapes are
sUPDliej. The distrioution set contains source anG oDject
modules of the compilers ana the runtime liorary,
commana files tor co~piler generation 8"j n'dirltenance,
user manual and compiler ger'eration instructions.

- patkej data struct~res Hre orly lTrle~enteo tor
thar3cter arrays , 3l~dYS packea, tAO c~arls/.orJ
and tor bOoLpan arr~YS ( cackin~ O(ltion~l,
one ooolean/bit J. Ihe orocedures raCk and unp~ck
are not implementeJ.
- only local ju~ps ar~ allowe~.
- a oair ot t'roce~ures, l\:ar~ anc release, to allocate
and 1eallocate ayna~ic storage~
the

followinq extensl0ns

have

ceerl

i~'~ le~enteu:

- funct~on results can ce of ~onscalar tyoe,
- arrays ~ith unsoecified ~ourlas ( hut specitie~
iniex-structure ) can be usee as for~al ~dran;etprs
to oroceaures, allowino oitferently ceclareo
varl'~les or constants as act~al plra'aters,
- a strlna parai~eter tyue has heer irtroo~ceo 1n ~"ich
one-jlmpnsional ch3r3cter arrays or sUDstrinJs therpot
~a) oe passed a§ Dara~et@rs. SUCh ~trjn]s an~ their
constltuent c,",~racters are consiaereu as "re~a only",
- ~roce~ures may te co~o1led seo8r?tely,
- seoar1tely cOIIJr'l~j proceoures cen roe accessea
tnroUlh d decldration with tne rroceoure blOCk
reDl~ced DY "extern".

50clRCE LANGUAGE

the source • • hen it then co.p,les itself the

7. STANDARD. Restrictions: Files not implemented (except input and output); jumps out of
procedures
not
allowed;
packed
only
implemented for one-dimensional character
arrays(always packed) and one-dimensional boolean arrays (packing optional); procedure
"dispose" not implemented (procedures 'mark' and "release' will suffice for nested
allocation and deallocation). Extensions: function results can be of non-scalar type;
arrays with unspecified bounds can be passed as parameters to procedures; several added
standard procedures, including a pair to obtain and set the value of device-register

PdP-l1 version is createri.

memory

rne comoilers are ~ritten irl Pas~al, ana Doth flavp
the saTe source code ex cent tor two seoerately
compile1 routines. TMe crosscompilpr is ~enerateo.

.. hen tne {)E:C-1ti Pascal tomp; Ler from ~'a'TIour~ camp, les

Tne size of the compiler is ~L~~ores of coae. in a
PDP-11 runnin~ under NSX-l1~ V2 onl. 52 ~.orus dre
"vaila~le for co~e anj aata. lhrouah a sli~nt modification
of tne overlay loadin; routine of PSx-llM ,t "as
~een Dossi~le to seg~ent the verY recursive COlllpiler.
It now fits in a j2 I.oras partition an~ uses auout
C::2

r(loior:JS

tor

COde

le3vif"lq

1\1 f..\Ioiords

tor

'lata.

locations;

may

be

declared in the outer block to be associated with

(such strings and their constituent characters are considered as tlread-only".

:z

rn
:E:

en

8. MEASUREMENTS. (x No information provided. x) Reported to be "quite fit for
appiications l l •
9. RELIABILITY.
in 75/12.

lhis is enouqh to co~pile fa,rl. larGe programs.
Ho~ever, the overlay ~eLhanis" ~akes the COlnpiler slo~,
aeout <'JO lines I ",in"te witn ~PI'4-eo",pati"le (j,SkS,
less"ith kKIJ5 (lis"s • • ith RSa-ll:" v3 uSinJ ~LAS and ~
64K partition the soeeo ;5 increased ,-I,) times.

procedures

specified interrupt sources; a string parameter type has been introduced in which
one-dimensional character arrays or substrings thereof may be passed as actual parameters
real

time

Good. (x Number of sites using system not reported. x) First distributed

10. DEVELOPMENT METHOD. Cross-compiler running on DEC-10 producing code for
Developed from Pascal-P. (* Person-hours to develop system not reported. *)

any

PDP-11.

11. LIBRARY SUPPORT. (x No information provided. *)
DEC PDP-11 (Vienna)

RtLlAtlILI II

Excellent. Ihe compiler ;s noo in
sites, ana is usee at tour more.

founa durinq tne last t.o

~eav, use
et·,rOrs

f~o

at

thr~e

Osterreichische

nave neen

~~I.!c:li~n~!t~ellschaft fur

~ontns.

Lenaugasse 10 • A-l082
~tT~OD

OF

lhe
~i

i~olementatl0n

II

~~

en

DEVEL~P0E~1

ne~

effort until

v~rsion

wnich
developea later.

no~

Dertor~s

'5 about

so,'e

b

Bankverblndungen
CA-Bankverein:
26-34343/02
E. o. Spar-Casse:
100-94709
Osterr. Uinderbank: 106-100-432

~Ianmont~s.
Ihr Zeichen

Ihre Nachricht yom

-0

Forschungszentrum Selbersdorf
Telefon:
(02254) 201, 781.y.
Telex:
014/353
Telegramm:
austratom wien

USA

o~timization

rn

Institut fur Physik

Pascal User's Group
c/o Andy Michel
University Computer Center
227 Exp Engr
University of Minnesota
Minneapolis, MN 55455

Ine crosseomp,ler tor PDP-ll runrinq on DEC-lu
pr~duced by bron et al ~as usee as input. ~s mentioned
earlier, tn,s compiler .as mOGilild to cenerate o~ject
code linkable unaer ~SA-11' anO to ~ive access to
t net i l e s y 5 t e 'n 0 IPS x -11 t . " t, e n t r' e c r 0 s s con, p, l e r "a 5
tinishej it compiled itself anD the conpiler .a5 t~us
transferrea to PDP-11.
Nayoe a

Atomenergie Ges. m. b. H.

WIEN • Austria

Unser Zeichen

PH/May/HE;

Sachbearbeiler

.

Telefon (Durchwahl)

1. IMPLEMENTOR/DISTRIBUTOR/MAINTAINER. C. Bron; Twente University of Technology; P.O. Box
217; Enschede, Netherlands; 05420-99111; TELEX: 44200.

1.) that we have implemented P.B. Hansen's Sequential Pascal compiler in
the PDP-11 Operating System RSX11-M and RT11.
2.) why we choose just this compiler
3.) something about the new design of the compiler
4.) what we are just working on and what we plan to do.

MACHINE. DEC-10 cross-compiler producing code for any PDP-11.
operating

system

requirements.

(x

Minimum

4.

DISTRIBUTION. Available on DECtape or 9 track magtape free of charge.

5.

DOCUMENTATION. Machine retrievable documentation package.

hardware

6. 11AINTENANCE. We intend to correct reported errors for the next few years. Error
reports and updates will be sent at irregular intervals to all those who have received the
compiler, unless otherwise requested.

ad 2.) We needed a high level programming tool for process control~
scanning and analyzing data and so on. Our principal concern
was system security and fleXibility.
(One of the main applications being in safety control),
The advantages of P.B. Hansen's Pascal compiler are:
It is the only compiler we know, running in the original
version without any bugs. Anyone concerned with compilers
that are not supported by any maintainer will appreciate
this.

td

rn
;;0

Datum

We have just recently joined the PASCAL Users Group and want to tell you
about the work concerning PASCAL and its applications in our data-processing
group, especially

2.

rn
::s:

1977 OR 01

DEC PDP-11 (Twente)

3. SYSTEM CONFIGURATION. No
requirements not reported. *)

-l

-0

>
G>

rn
00
\J1

- The concept is clear and easy to understand. This enables
you to modify or extend the compiler for your special purposes.

3.) routines for reading and writing

CoNST PAGELENGTH = 512,
TYPE PAGE = ARRAY [1 .. PAGELENGTH

- The concept of a "virtual machine" makes you almost independent
from machine and Operating System.
- The complete interface to the Operating System is contained
in a simple program prefix. This seems to be the greatest
advantage.

PROCEDURE
PROCEDURE
PROCEDURE
PROCEDURE
PROCEDURE
PROCEDURE

The few restrictions· to "Standard Pascal" did not matter that
much to us.

ad 3.) One of the most difficult tasks was to design a suitable set
of prefix routines (as an interface to RSX instead of the
Solo Operating System of P.B. Hansen)· These prefix routines
are system functions that manage for example
and overlay loading.

reading~

CHAR,

READPAGE(U: UNIT, N: INTEGER, VAR BLOCK: PAGE),
WRITEPAGE(U: UNIT, N: INTEGER, VAR BLOCK: PAGE),
READCHAR(U: UNIT, VAR C: CHAR),
WRITECHAR(U: UNIT, C: CHAR),
READLINE(U: UNIT, VAR TEXT: UNIV LINE),
WRITELINE(U: UNIT, TEXT: UNIV LINE),

- the programmer can learn to use the new interface as quick
as possible.
- even in extreme cases it is obvious what happens

But how to work with those simple liD routines?

- liD is efficient (time and core/discsr ace ).

A good practice will be the following one:

To put this concept through requires a lot of courage~ for
the users often want an liD system as complex as they are
used to from other programming languages (FORTRAN! J. Moreover~
RSX has a very sophisticated filesystern and it is hard tu

The programmer chooses
needs. These operators
Pascal. The programmer
writes them himself or

implement it in

An example for such a set will be:

and not to use all the

rn
::E:
C/)

be used.
We don't claim to have invented new functions. On the contrary
we have omitted as much as possible from the RSX-file system
options without restricting its feasibility for the PASCAL user.

the~PASCAL-system

=

"readpage" and "writepage" are for random access pagefiles.
The other routines are for sequential textfiles. Instead
of the type "page" any other type with the same length can

writing

Our main prinCiple of design was to be as simple and clear
as possible so that

J OF

CoNST LINELENGTH = 132,
TYPE LINE = ARRAY [1 •. LINELENGTH J OF CHAR,

complex functions it contains.

a set of "liD-operators" for his special
are procedures and functions written in
takes them out of a programlibrary or
modifies existing programs for his purposes.

procedure read integer (var n: integer~ length: integer];
procedure writeinteger (n: integer, length: integer);
procedure skipdelimiter; procedure newline;

As an example~ look at the way files are handled by the
new prefix. Only two types of files are supported:
sequential textfiles and random access files with a fixed
recordlength of 512 bytes.

C/)

rn
"""0

-i

rn

on

:3
tD

There are three groups of prefix routines for the file handling:

The procedure readinteger does what you expect:

rn

1.) routines for file definition:

It reads an integer "n" with at most "length" characters from
the inputstream e~ding with the next delimiter.

PROCEDURE PAGEFILE(U: UNIT, F:FILENAME),
PROCEDURE TEXTFILE(U: UNIT, F:FILENAME),
with the type definition

and

50

The only systemroutine used is "read one character from an
inputstream". In Pascal procedures like readinteger can easily

be written. If the programmer is in doubt what the program

CONST FILENAME LENGTH = 30,
TYPE FILENAME = ARRAY [1 .. FILENAMELENGTHJ OF CHAR,

really does, one glance at the pascal source program (instead
of considering twenty rules in a manual) obviously will explain it.

CoNST MAXUNIT = 4,
TYPE UNIT = 1 .. MAXUNIT,

This method is the best one to meet the need for structured,
modular. ~rtabel and flexibel programs.

These routines associate a page- or textfile with an unit
number.
2.) file management routines:

PROCEDURE CREATE(U: UNIT, INITIALSIZE: INTEGER, C: CoNTIGDUSTYPE),
PROCEDURE CREATETEMPORARY
(U: UNIT, INITIALSIZE: INTEGER, C: CoNTIGoUSTYPE),
PROCEDURE oPEN(U:UNIT, ACCESS: FILEACCESS),
PROCEDURE CLOSE(U: UNIT),
PROCEDURE DELETE(U: UNIT),

ad 4.) A Pascal version for easily programming CAMAC Systems is under
work and will ~e running summer 1977.
The implementation of Concurrent Pascal in the Operating System

RSX11M using the task synchronisation facilities of RSX11M will
be completed at the end of the year.
Afterwards we are planning to use (Concurrent) Pascal and the
conditional critical regions-concept for multiprocessing

applications (with microprocessors Intel 8080).
If you are interested in our

"Create" and "create temporary" create a new file and "open"
opens an existing file.
"contigoustype: and "fileaccess" define the method of allocation
and aCC8SS.

Sincerely

TYPE FILEACCESS

Dipl.-Ing. K. Mayer

J

=

TYPE CoNTIGoUSTYPE

(READoNLY,MoDIFY,EXTEND.APPEND.REAOSHARED),
=

(NONCoNTIGoUS,CoNTIGoUS),

=

'1~·

yours~

",-"tllU,i.

l(
\

work~

please write to us.

"""0
J>
G>

rn
DI{t'-

00

m

DEC PDP-ll (Portland)
DEC PDP-ll (Belgium)

1. IMPLEMENTOR/DISTRIBUTOR/MAINTAINER.
Pierre
Verbaeten;
K.
V. -Leuren; Applied
Mathematics and Programming Division; Celestijnenlaan 200B, B-3030; Reverlee, Belgium;
(* No phone number provided. *)

1. IMPLEMENTOR/DISTRIBUTOR/MAINTADIER. Barry Smith, Oregon l1useum of
Science
and
Technology, Computing Department, 4015 SW Canyon Road, Portland, OR 97221 (503/248-5923).
2.

MACHINE. Digital Equipment Corp. PDP-ll.

rn

2.

MACRINE. Digital Equipment Corp. PDP-ll.

3.

SYSTEM CONFIGURATION. RSTS/E. (* Minimum hardware requirements not reported. *)

3.

SYSTEM CONFIGURATION. UNIX. (* Minimum hardware requirements not reported. *)

4.

DISTRIBUTION. (* No information provided. *)

4.

DISTRIBUTION. (* No information provided. *)

5.

DOCUMENTATION. (* No information provided. *)

5.

DOCUMENTATION. (* No information provided. *)

6.

MAINTENANCE. (* No information provided. *)

6.

MAINTENANCE. (* No information provided. *)

7.

STANDARD. (* No information provided. *)

:::;:
C/)

7.

STANDARD. (* No information provided. *)

8.

MEASUREMENTS. (* No information provided. *)

B.

MEASUREMENTS. (* No information provided. *)

9.

RELIABILITY. (* No information provided. *)

9.

RELIABILITY. (* No information provided. *)

10. DEVELOPMENT METHOD. (* No information provided. *)

10. DEVELOPMENT METROD. (* No information provided. *)

11. LIBRARY SUPPORT. (* No information provided. *)

11. LIBRARY SUPPORT. (* No information provided. *)
C/)

rn

DEC PDP-l1 (PAR)

-0

DEC PDP-ll (Berkeley)

-i

rn
1. IMPLEI1ENTOR/DISTRIBUTOR/MAINTAINER.
Rome, NY 13440; 315/ 336-8400.

1. IMPLEMENTOR/DISTRIBUTOR/MAINTAINER. Charles Raley,
Computer Center, Evans Rall, University of CalHornia
(* No phone number provided. *)
2.

William

Joy,

Berkeley,

CA

4.

DISTRIBUTION. (* No information provided. *)

5.

DOCUMENTATION.

We

at

PUGN

94720.

"User

Manual",

and

"PXP

MAINTENANCE. (* No information provided. *)

7. STANDARD. Restrictions: procedures and functions may not be passed as parameters; only
the first parameter to NEW is treated - subsequent parameters are ignored. A compiler
option directs the compiler to accept only Standard Pascal constructs.
MEASUREMENTS. (* We have been told that the system is quite fast, even

interpreted.

though

it

is

;;0

MACRINE. Digital Equipment Corp. PDP-l1/45.

3.

SYSTEM CONFIGURATION. RSX-lld. Minimum hardware same as for RSX.

4.

DISTRIBUTION. None until at least 77/06.

5.

DOCUMENTATION. None yet. (* Not known i f documentation will be machine retrievable. *)

6.

MAINTENANCE. None yet.

7.

STANDARD. Full Standard, probably with extensions.

No other measurements have been reported. *)

8. !1EASUREl1ENTS. Expected to be about 5000 FORTRru~ source lines and 3000 Pascal source
lines. Expected to run rings around FORTRAN compiler. (* Rich Cichelli reports on 77/0B/31
that it is a 2 pass system in wh~ch the code generated is faster than the 19 (!) pass
optimizer for William Wulf PDP-ll Fortran! *)
9.

RELIABILITY. Will not be distributed until it is.

10. DEVELOPMENT METHOD. One pass Pascal to FORTRAN translator. Initial version of each
procedure written in Pascal and then hand translated into FORTRAN. When compiler is
finished or can co~pile itself it will be restored to its original

RELIABILITY. (* No information provided. *)

10. DEVELOPMENT METROD. Parsing
interpreted via threaded code.

is

done

by

Pascal

in

a

massive

inverse translation, and then run through itself, thus completing the bootstrap_ Currently

a

modified

LALR

parser. Object code is

(76/12/14) project has consumed about 4 person-months. Expected to consume 6 to 9
person-months in all (with 1 person devoting half-time). Implementor previously built a
compiier

for

a

subset

of Pascal for a class project, but has never written any program

this large before.
11. LIBRARY SUPPORT. (* No information provided. *)
11. LIBRARY SUPPORT. (* No information prOVided. *)

3:
ttl

rn

2.

have received "MANual" documentation (machine readable).

Also available are: UNIX Pascal "Report Appendix", UNIX Pascal
User Manual". (* These are apparently machine readable. *)

9.

~1all;

MACRINE. Digital Equipment Corp. PDP-ll.
SYSTEM CONFIGURATION. UNIX. (* 11inimum hardware configuration not reported. *)

B.

N Condict; PAR Corporation; On The

and Ken Thompson,

Berkeley,

3.

6.

Michael

DEC LSI-II (San Diego)
Hardware requirements are:

1. IMPLEMENTOR/DISTRIBUTOR/MAINTAINER. Pascal Group; Institute for Information
UCSD Mailcode C-021; La Jolla, CA 92093; (* No phone number reported. *).
2. MACHINE.
and 8510A.

Digital

Equipment Corp. LSI-ll Microprocessor, PDP-ll any model, TERAK 8510

3. SYSTEM CONFIGURATION. Comes with a one-user 'operating system. Apparently requires some
mass storage (disk or floppy disk).
4. DISTRIBUTION. Distributed on floppy disk in two versions: 1) Complete release:
including all source code and internal documentation ($200); and 2) Code release:
including system code and users manual ($50).
5. DOCUMENTATION. For complete release: compiled listings of a1'l source code, and user
and system maintainence documentation as complete as it exists. For code release: Users
manual but no detailed system documentation. Do~umentation is machine retrievable.
6. MAINTENANCE. For complete release: compiler updates at least 3 times during 77/8/1
thru 78/8/1. For code release: No continued support for later releases. Only minimal
assistance in response to telephone inquiries. Future plans: plan to have a version of
this system for the Zilog Z-80 ready. Plan to have versions for Intel 8080a ready by 77/9,
MOS Technology 6502, and Motorola 6800 ready by summer of 1978.
7.

STANDARD. Pascal-P subset plus strings.

8. MEASUREMENTS. 700 lines per minute compile speed. 20K byte compiler, 10K bytes for
resident monitor, interpreter, and run-time support.
9.

PDP-ll/20 or up.
28K words of addressable core store.
either a DEC RF-l1 or a DEC RK-ll.
(In case you have some other disk, your DOS expert should have little trouble replaCing our disk driver with your own.)
a DECtape unit (we can supply the system only on DECtapes).

Systems;

10. DEVELOPMENT METHOD. Pascal-P2 via B6700, PDP-l1/10 bootstraps.
text

editor,

text

formatter,

pretty

DEC PDP-l1 (Urbana)

:e::

en

distributor:~

1) Three DECtapes (these must be in PDP-ll format).
2) A statement of your intended uses.*
3) One signed copy of Prof. Snyders encLosed letter.*
4) A stamped, self addressed mailer for returning your DECtapes (total
weight is about 900g (2 pounds».
*The Pasca1-11 compiler was developed at the University of Illinois Urbana and is copyrighted by its Board of Trustees. The work was supported in part by a
grant from the National Science Foundation. Accordingly, distribution is made to any
interested persons or parties who intend to use this software for "research, education, or
other legitimate purposes." The NSF requires that we inform them of those receiving this
software and their intended uses of it.

IMPLEMENTOR/DISTRIBUTOR/MAINTAINER.
Implementors:
J. Krishnswamy
A.I. Stocks
Dept. of Computer Science
Dept. of Computer Science
University of SW Louisiana University of Illinois--Urbana
Urbana, IL 61801
P. O. Box 4330
217/ 333-4428
Lafayette, LA 70509
318/ 233-3850 x538
Distributor:
Pascal-ll; c/o M.D. Mickunas; 222 Digital Computer Lab; University of Illinois - Urbana;
Urb8na. IL 61801; 217/ 333-6351.

6. MAINTENANCE. Since the project under which the compiler was developed has expired, we
have no source of funds for maintaining and upgrading the compiler. Consequently, we offer
Pascal-ll 'as-is', with no plans to extend it or to implement it on another system.
7.

1.

2.

=
rn

5. DOCUMENTATION. Unfortunately, very sparse at present (77/01/21) but we shall include
in the distribution package all that is available. (* This is apparently not machine
retrievable. *)

RELIABILITY. Reported good. First released on 77/8/1.

11. LIBRARY SUPPORT. Extensive gtaphics software,
printer, all in Pascal;

4. DISTRIBUTION. While our Pasca1-11 &ystem is not yet complete enough for widespread
distribution, weare happy to make it available on a limited basis to interested persons.
Our distribution package includes:
1) Pascal-ll source of the Pascal-l1 compiler.
, 2) MACRO-ll source of the Pascal-ll run-time routines.
3) Binary for both the compiler and the run-time routines.
4) Binary for our operating system.
If you are interested in obtaining this software, please send the following to the

MACHINE. Digital Equipment Corp. PDP-l1/20 or up.

3. SYSTEM CONFIGURATION. Operates under our own operating system, Which grew out of DEC's
DOS/V4. In case you desire to install Pascal-l1 on your own version of DOS, we also
provide a list of DOS/V4 modifications. We believe that these modifications are sufficient
for adapting DOS/V4 to Pascal-l1, but we can, of course,' make no guarantees. We caution
that these modifications are not sufficient for installing Pascal-lIon other operating
systems, but 'your DOS expert should be able to make the neccessary modifications using our
DOS/V4 modifications as a guide.

STANDARD.
Differences:
"with"unimplemented.
types real and set unimplemented.
variant records not permitted.
procedures-as-parameters not permitted.
writeln, read In not implemented
EOL feature still included.
Extensions:

compile time options.
source level library routines.
overlays.
8.

MEASUREMENTS.
compilation speed--(* No information reported. *)
compilation space--(* No information reported. *)
execution speed--(* No information reported. *)
execution space--(* No information reported. *)

9. RELIABILITY. (* Information on reliability not reported. Number of sites using
not reported. Date first released not reported. *)
10. DEVELOPMENT METHOD. (* No information provided. *)
11. LIBRARY SUPPORT. Source level library routines are implemented.

system

00
00

UNlVERSlTAT

HAMBURG

the idea to proGram our local inhonor;eneous cOElputer netl'!Ori, (tVJQ
different MINCAL-621, a PDP-l1/20 and a PDP-l0) in Concurrent Pascal.
A code generator for the PDP-l0 has just been conpleted and is currently being tested. In the course of writing a code fenerator for
the PDP-l0 (36 bits per word) we realized some of the shortcomings
in the def~nition of the intermediate hypothetical machine whic~
was originally conceived for byte-oriented machines.

INSTITUT FeR
INFORMATIK

Tela-Hr.: 2 t.73:1 ani hhd

Prof. Dr. H.-H. Nagel
Inrt!tut fer laformatik
1 H&lIIbllI"'lIJ, Schlltel'ltn6e 66-71

Na/Ja

Nevertheless, we have already executed a system of Concurrent ?ascal
orocesses on the PDP-10 and another one "hich comrmnicated fron one
~INCAL-621 to another.

May 16, 1977

~

Our Concurrent Pascal Compiler is described in a report (in German):
Dear Mr. Mickel,

CONCURRENT PASCAL Compiler f(jr Kleinrechner
B. Br(jgge, B. Gisch, Th. Kahl, E. Linde, M. Mittelstein. H.
viestphal
IfI-HH-B-30/76 (December 1976)

as I have indicated by a letter mailed on February 14, 1977 our
DECSystem-10 Pascal compiler of December 30, 1976 is now distributed
by DECUS. ~lr. Nigel Derrett from Aarhus/Denmark pointed out one
error in our PASCAL implementation of December 30, 1976: The attempt
to pack a variable of a subrange type that requires exactly 35 bits one less than an entire word - may result in an infinite loop.
Another, although minor, bug is connected with reading from TTY:
in order to avoid unnecess~y prompting of input during opening input from the TTY, the compiler checks whether any reading from TTY
is requested during aprogran. The aste.risk - promptinr; input to
fill the first TTY-buffer - will only appear, if input from the T?Y
will be requested somewhere in the program. Unfortunately, arguments
of standard procedures have not been included in this test. Therefore, if input from TTY appears within a program only as first argument to GETFILENM1E, the input device TTY will not be opened automatically. An easy way around this weak point consists in inclusion
of, e.g., a statement READLN(TTY).
Both errors will be removed in the next compiler version which, however, may take some time. I 110uld like to investigate means to further optimize code generation by e.g, improving the allocation and
use of registers. Since any change at such a sensitive area has to
be made very carefully, it will take some time.
A PASCAL cross compiler running on the DECSystem-10 and generating
code for a German minicomputer Dietz I'lINCAL 621 is currently being
converted to software paging of procedures: the pure code of procedure
bodies is allocated in 128 Byte pages that may be loaded from disk
to a .certain core area and may be overwritten if that core area is
needed. The nesting of 131 simple procedures has been successfully
tested to verify the loading, overwriting and reloading of procedure
bodies into core. Next we want to implement the PASCAL-S system
(which is already available by a non-paging cross compiler for this
;'UNCAL-621) by this new software paging PASCAL system and to compare
its performance with oaging versus the one without paging.
A compiler for Concurrent PASCAL has been developed by a group of
students at our-lab-orat-ory in collaboration with E. Kemen and myself. This is an implement8tion completely independent from that
of Brinch-Hansen for the PDP-11145. Our Concurrent Pascal compiler
is executed as a PASCAL program on the DECSystem-10 and generates
code for a hypothetical intermediate machine which has been designed
to facilitate easy code generation for Byte-oriented minicomputers.
Two code generators have been implemented, one for the MINCAL-621
and one for the HJTERDATA M85. Using this Concurrent Pascal implementation an assembler program to control our TV-periphery connected
to the HINCAL-621 has been reimplemented as a system of Concurrent
Pascal processes. The ease of designing a process system for actual
applications in Concurrent Pascal has encouraged us to proceed with

Sincerely yours,

DEC-10 (Hamburg-DECUS)
C/)

1.

IMPLEMENTOR/DISTRIBUTOR/MAINTAINER.

Implementor/Maintainer: E. Kisicki; H. -H. Nagel;

lnfor~tik;

rn

13,

""0

Germany; 040-4123-4151; TELEX: 214 732 uni hh d. Distributor: DECUS; Maynard, MA 01754;
USA; 617/ 897-5111; TELEX: 94 8457; TWX: 710 347 0212.

--I

Universtat Hamburg; Institut fur

SchluterstraBe

66-72;

D-2000

2.

MACHI~E.

3.

SYSTEM CONFIGURATION. DEC TOPS-10 moniter using Concise Command Language

Hamburg

rn
3:
ttl

Digital Equipment Corp. DEC-10. (Adapted to the DEC-20 by DEC).

rn
KA-IO

(CCL).

Uses

::0

instruction set. Modifications to use KI-IO improved instruction set have been made

by Charles Hedrick.
4. DISTRIBUTION. DECUS (Digital Equipment Corp. User's Society) Maynard MA 01754
(617/897-5111; TWX 710-3470212;
TELEX 948457).
Also
DECUS
Europe,
P.O. Box 340,
CH-1211 Geneva 26, Switzerland «022) 42 79 SO; TELEX 22593).
5.

DOCU!1ENTATION. Machine retrievable manual included on distribution tape.

6.

MAINTENANCE. No regular maintainance can be given.

7.

STANDARD.

Extensions: Functions FIRST and LAST for scalars; UPPERBOUND and LOWERBOUND

for arrays; MIN and t1ax available as standard functions; procedures to determine the value
of eeL options available; "OTHERS" in ~ statement; LOOP ••• EXIT IF ••• END statement;
Initialization procedure.

8.

MEASUREMENTS. (* No information provided. *)

9. RELIABILITY. Very good. First version released in 75/7. Distributed to at least 60
sites. Later version operational in 76/9. Latest version released to DECUS in 77/2.
10. DEVELOPMENT METHOD. Pascal-P2 and subsequent self
76/12/30.

bootstraps.

Latest

version

dated

11. LIBRARY
SUPPORT.
Symbolic
post-mortem
dump
available. Interactive run-time
source-level debugging package available. Separate compilation
and
inclusion
in
relocatable object code library of Pascal, FORTRAN, COBOL, ALGOL, and l1ACRO-lO assembler
routines.

""0

»
G)

rn
00

to

DEC-I0 (Systems-Pascal)
Cnarles Hedrick wrote (received 77/07/28), "Ine version of PASCAL described nerein
answers most of tne criticisms that caused me originally to declare it useless. Ine lack
of strings and variable-size arrays is still a bother, but not serious. 1 chose to do all
tnis to PASCAL because SAIL (the alternative vehicle) is too baroque to contemplate. My
design goals were to give the PASCAL programmer access to all the facilities of the system
- (1) in a manner that is not too badly machine-dependent nor requires him to know
assembly language, but (2) in a manner that does not require a complex system of runtimes,
e.g., one that simulates the OS/360 access methods. I believe the results have been
successful. I'm still not sure whether it would be usable for hard-core data processing
(ala COBOL), but it comes close. Mainly it is missing tape label processing and ISAM data
sets. But one can now get the operating system to handle tape labels (PULSAR), and IS&~ is
not a primitive concept, at least for the 10. If
DECsYstem-l0 System ProSrammers' PASCAL - an alter.ative PASCAL
system for those who need full access to the facilities of TOPS-IO,
or who want to do data processinS.
(1) Charles L. Hedrick, Computer Science Dept., Rutsers Universitw,
New Brunswick, N.J. 0''\03
(21 PDP-10, KI-IO and KL-l0 CPUs onlw.

Probablw PDP-20, with minor

ch.!!Jn!l1EoS.

(3) TOPS-l0 operatins system.
Virtual memory 6.01 or later monitor
reauired.
One minor feature reGuires 6.02.

(4) The latest stable version is distributed throu~h DECUS.
The most
recent experimental version can be obtained from me directlw (at the
above address), if ~ou send a blank mastape and return postaSe.
(5) A supplement to the Revised Report is included in the
distribution in machine-readable form.

(6) I air, cl..lrr't~nt.ly maint.ain:i.n~.:j it. and will continue to d(J ~:j.(J fc,r the
forseeable future, but I probablw will not do further development
work (i.e. addin~ features)~
I hops this version will be superceded
by an improved version from Hamburg.
(7) GO TO out of the current procedure is not supported. (Trick~ to
implement, and a terrible idea anwway.) Local files not implemented.
(No ECS on a DEC-10 and simulation with random1w- named files seems

l.Jnat t. T'act i

Vf~. )

(8) Compiler plus interactive debussinS packaSe (PASDDT) and a
librarw of useful system functions.
CompletelY inte~rated into eCL
(COMPILl.

(9) The compiler is Quite reliable.
The runtimes are reliable for
standard PASCAL and the most commonlw-used extensionst Some obscure
corners of the extensions have not been well tested (mostly those
involving user error recoverw'.

(10) Modified version of the Hambur. (Na.ell compiler.
The latter
was done from some edition of PASCAL-P, I believe, in several stages.
I did r)ot start out intendinS to have my own version of PASCAL+
Rather I wanted to test out a few ideas, with the hope that Proft
Na.el would adopt those that turned out to work, for use in the
official DEC'wstem-10 PASCAL (which he maintains, and which is
available from DECUS).
I believe this will happen in the Ion. run,

but in the meantime I am publishinS my experiences in the hope that

it will help other PASCAL implementors who are confrontinS similar
problemst
Thus this note is directed at fellow implementors, and is
not intended as an advertisement for our version.
(Indeed I
recommend hi~hls that other people use the HamburS version unless
thew absolutely reauire some of our features.) In the following, an
asterisk (*) indicates a feature not in the edition we submitted to
DECUS~
version~

A plus si~n <+, indicates a feature present in the HamburS
I don't want to take credit for them, but thousht other
implementol'S mi~ht like to know about them+

(II INITPROCEDURE(tll These specifw initial values for variables.
The~ do not compile code, but put the values in the initial co~e
ima~e directl~~
INITPROCEDURE BEGIN  END.
(2) OTHERS in case statement(+):
cases not fittin~ anywhere else.

OTHERS:  will catch any

(3) LOOP<+>:
Allows a loop with exactlY one exit in the middle. Note
that this is still a one-in-one-out construct. LOOP  EXIT
IF ;  END

(4) Program sta'tement(t). There was some Question what the PROGRAM
statement should do in interactive implementations. I believe
HamburS's solution is a good one.
If any files are listed in the
PROGRAM statement, the prosram beSins with a dialoSue asking ~or
specifications for them.
It is important that this dialogue can be
suppressed by not listins an~ filest This sives the proSram the
option of Settins the file names in some other way and specif~in~
them to the RESE1· OT' REWRITE directl~. This follows my
BASIC DESIGN PRINC:IPLEI
It should be possible to write a program
that cannot be identified by its users as a PASCAL pro~rami
I.et one
should be able to take over error handlin~ and file specif~ins if
f.:h:;:.s:i.

T'f:~d.

·Interactive· files:
RESET does an implicit GET in official
PASCAL. This causes PASCAL proSrams to try to read from the user's
terminal before startinS the prusram when i t is INPUT. That makes it
impossible for the pro~ram to Dutput a promptin~ messa~e first, or to
write a pro~ram that doesn't have terminal ir)Put at all.
Most
implementati(Jns on interactive systems allow one tu specify a file as
interactivet
Then when it is RESET, no GET is done.
Instead the
buffer is filled with null (in our easel or blankCfor the CYBER,
which doesn't have a null), and EOLN is set~
This abilit~ is also
useful for ffia~tapes, where one mi~ht wish to issue a positioninS
command (space forward, rewind, etc.) before doins the first GE1+
The CYBER specifies files as interactive by puttin~ a.slash (\) after
their name in the PRociRAM statement. We make this an option
specified in the RESET statement.
(See below.' PuttinS it in the
RESET statemerlt is helpful since not all files are listed in our
PROGRAM statemerlt+ In our·imp!ementatiollf the user's terminal is the
special file TTY, and is alwa~s irlteractive.
(3)

(6) End of line: The Revised Report seems to reGuire us to set the
buffer to blank at end of line~
Alas, the DEC-10 has several
line-te~ffiinato~ characters.
Thus one cannot tell which one has
uccurred+
We put ttle actual terminator in the buffer.
A blank seems
useful for those swsterns that do not have line-terminator characters
(e.S. CYBER). Pro.rams that use IF Ern_N THEN READLN will work either
wa~. (Our READLN also skips the line feed if the initial terminator
i.s (":~I'I'ia,j~' r~'tu~n.) Nd. .. -t.k",+ ct- ...e~u.;res i,""o GET', -tc d<.\~" c'~a.rr,o.S<-r~+unl, 1.~-f',,«4 S~\l~ce) o..ltt......~i-- '" ~."ql" REA&L,," '".>;l\ d •• {;.

""tJ

::t>
G">
IT!

<.0

o

(7) End of file:
111 PASCAL EOF is normally false for input and true
for output.
This lack of S~'ffiffietrY complicates the I/O J'untimes
needlesslyv confuses users~ and makes tl"le ilnplementation (If update
mode difficult.
In update mode, one can do both GET afld PLJT on the
same file.
Howeverv if EOF is truev GET will sive an errorv and if
EOF is false, PUT will Sive all erroy'.
We have not really solved this
problem. Fortunatelw ul-Iciel' most CirClJmstances PUTX is used rather
thai) PUT in update mode.

(13) Random access 1/0(*):
On the DEC-10 random access devices have
fixed size ph~sical blocks.
No slalldard "access methods" are
provided.
(Basicalls we have onls QSAM i~nd BSAM with form~~t U
y'ecoy'ds.) l"hus (Jl"lS call sittler simlllale tile COBOL rlilltiine ShlS"temF or
stick wittl lc)w level primitives+
Tile latteY' seel~s COflsistel"lt with
PASCAL's philosophs.
It ~las "t~le cijsadv3ntB~e of beins
1~~!cl"line-deperldel"l"tv l"l(JWeVer~
~;ir)(:~e it depends UpeJf1 the arc~litectllre of
the DEC file shlstem. (This architectllre is probablY Guite common
o~Jtside of IBMy h()wever.) We use an index into the filet
SETPOSC"filey:index[,slIPpress GET:]) sets one to the illdex'th b~te in
the file.
CNB: b~te, not-disk block. We P81'f(Jrm ttle b~Jffer
maniPl"lliltion fleeded to ~et "t(J the specified byte.) CURPOSCfile)
retuPI""IS ttle posJ"tion a"t the besinr"rirls of -tile last T'ec(Jrd read or

(8) liD to strinSs. STRSEfCfile,arrsY[,start[,endJ]) allows resular
input to be done from "the arri~Y' startin~ at element start and soins
throuSh S11ci.
Similarly STRWRITE foy' output. T'lis allows conversioll
fr(Jm text to intesel' and visa versa using ttle standard READ and
WRITE.
It also provides a sort of poor man's simulation of files in
ECS (which we don't have).
I am not enttlusiastic about this feature v
however v and would be h8PP~ to see it So away. One mlJst re~uire "that
"the ay'ray be declared at ttle same lexical level as tile filev be
~lobal to it, or be or) the heap+ Otherwise one could exit tile block
where the arras is defined and have the file pointin~ into now/lere.

IAY':i.

( :I. ~":":;) BI=\:EAI{, BFi'1 :,,:)1\ I N ~
BF~Er-t.ll\ fo I'C(·:·~~:; out th(":"~ I:"luff(::.' Y' :i" n 1:.luf"i"(~-.:o l'€·~d modC'!:;.
BREAKIN cle~~rs the bu"ffeY' "illS if1 blJffered m(:)de!;~ "fhev 81'e used
before or after magtape positiol"lingv etc. BREAI\ would be needed to
f(lrCe output to the "tel'mil"ldl, except tl"lat the file TTY is ~Iafldled
with a special l~if1d of I/O tha"t clops Ilot l"lse buffers.

READ applied to strings: READCfile,arrsy[:lensttl varJ) will read
characters into the arra~1 ul"ltil the next end of l:ine. Ttlis is reall~
amazingly useful for conductin~ dialo~ues with the user.
T~le
alternative seems to be to reQIJire strin~ Quotes to delimit the
strin~~ or dCl:i"ns somethins like READ(file,arra!~:set[:len~th]), wtlere
the user speci"Pies a set of break characters.
1"11e idea of strin~
~uotes is vers tack~,
impeclin~ the contruction of simple dialo~ues+
1"t)8 br'eak set idea is a Scod orlev that we Just have ~otten around tOt
If a variable is specified after the COlOll' it :is set to tile number
of character's read.
If mc)rs chari~cters are t~ped than the size of
the arras, the extras 21'e isnoy'ed (but couflted ill lensth, so the
proSram can tell what 1"18S h~!ppended)+
If t(JO few are "tspedv the rest
of tl"le al'ras is filled with blanks.
(9)

(16) RENAME
RENAME(file,filej;P8c[,ilnplenrsntatj"(Jn-depsndentJ)
renames the file opel' on .
(:1.7) CL""()SECfile)
safe if1 case t~le
"f(Jr use b~~ utl"IOr
Llle DEC-lO.) All
:;"'rD~,~~ram

(:LS)

(10) RESET and REWRITEI Our RESET and REWRITE are
REWRITE(file[,filespec[,il~plementatioll-dependent

st~JffJ])

2nd

(11) Variable size recoY'cis(*):
Olle call declaY's a file to consist of
a tVP2 that irlvo]"ves vi~rian"Ls.
Then one can u!;e
GET(file[,variarltJ ••• C:sizeJ), sild siiJnilal'l~ for PUT. As witll NEW,
this c~auses onl~1 the appropriate rr~Jmber E:)f words to be I'ead or
written.
:size is used wtlen "tile last elemellt in the declaration is
an arl'BY.
It !;pecifies ttlst (Jflls the "f:ir!;t  elements are to be

ls"d.

~()(TgL()(.K ({';Ie., S<>trr<-,> GEl?) qa\5
l.l:j"lnuln of 16 I/O c'lannels on
files al'e i~utomaticall~1 closed at tf"le ef)d of tl"le

6

DISMISSCfile) aborts cT'eati(Jn of all

OU"tP~Jt

f:ile.

(:1.9) IJPCASE("f:il"e,Booloall e)(preSS;i(Jfl) (::c)f)tr(Jlls IrlsppillS of lower case
t D U }".., F' j"":~ Y' ~": d ~:; c") "~

RESET(fi]"e[v"rilespec[,ir~teractive?[,iffiplement2tion-deperldelltJ]]}

Filespec is a strirlS CPACI(ED ARRAY OF CHAR) of an~1 len~th, includifls
a literal in strin~ Quotes.
It contains a device/file specification
if) "tIle standard DEC-I0 format.
Interactive is true to SlIPPY'eSS the
impllci"L GET, as described above.
l"I"\e ilnplemer~ta"l:ion-"dependeI1t stuff
allows the lJSer to control protect:ioflV version Ilumber', date, I/O
Ihode, bufferin~, etc. In par"ticlJlar, it all(Jws l1im to specif~
buffered elr urlb~J"ffered I/O (*)v arId t() declare that the file is
blocked (in the COBOL sense) C*,.
It also allows ilim to sUPpress the
normal runtime error me!~sa~e!j.
ERSTATCfile) can then be used to see
wi"lst erT'crs, if ar"IY, o(~curred.

1••

ttf:1rt.

(14) APF'END:
APF'ENII :is lik"e REWRITEy blJ"t beSil")s wri"tiflS at the end
of ~~rl exiS"tj"flg file.

il"ltOT'Job CC)mmUI"licat:iE:)rl CIPCF),
(SCAN/WIL"D).

i~l"ld

ca:L

SC~alll"ley'

Dietz MINCAL 621 (Hamburg)

See the letter from H.-H. Nagel under DEC-I0.
1. IMPLEMENTOR/DISTRIBUTOR/~~INTAINER. H. -H. Nagel; Universtat Hamburg; Schluterstrasse
66-72; 0-2000 Hamburg 13, Germany; 040-4123-4151; TELEX: 214 732 uni hh d.
2.

MACHINE. DEC-I0 cross-compiler producing code for the Dietz

3.

SYSTEM CONFIGURATION. (* No information prOVided. *)

4.

DISTRIBUTION. (* No information prOVided. *)

5.

DOCUMENTATION. (* No information provided. *)

6. l1AINTENANCE. (* No information provided. *)
paging of procedures.

7.

STANDARD. (* No information provided. *)

Currently

MI~CAL

being

621 minicomputer.

converted

to

software

8. MEASUREMENTS. The pure code of procedure bodies is allocated in 128 byte pages that
may be loaded from disk to a certain core area and may be overwritten if that core area is
needed. (* No information provided on compilation speed, or execution speed or space.*)
9. RELIABILITY. (* No information provided. *) The nesting of 131 simple procedures has
been successfully tested to verify the loading, overwriting and reloading of procedure

5. DOCUMENTATION. See the article "l'ascal Implementation and Experience", by Masato
Takeichi, Journal £i the Faculty of Engineering, University of Tokyo 34:1 pp 129-136.
6.

MAINTENANCE. (* no information provided. *)

7.

STANDARD. Restrictions: No local file variables; no parametric procedures.

bodies into core.

10. DEVELOPMENT METKOD. Cross-compiler on the DEC-I0 that generates
MINCAL 621 minicomputer.

code

for

the

Dietz

8. MEASUREMENTS. Self co~piles in 309 sec. Compiler object code is 117K bytes, monitor is
8K bytes, and self compilation requires 43K bytes of data store. Execution times, relative

to Fortran, are given in the following table.

11. LIBRARY SUPPORT. (* No information provided. *)

Fortran
1
1

FOXBORO Fox-l

rn
::;:
c:n

OS2/VS
Matrix mUltiply
Sort

:z

Pascal
1.35
1.24
0.96
0.63

Additive parition
Character count

I-'

1. IMPLEMENTOR/DISTRIBUTOR/MAINTAINER.
Foxboro, MA 02035; 617/ 543-8750.

Bob

Matherne;

Jim Pownell; The Foxboro Company;

9. RELIABILITY.
reported. *)

\~orking

very

well.

(*

Number

of sites and first date of release not

10. DEVELOPMENT HErHOD. Based on H.H.Nageli's Trunk compiler (5800 lines of Pascal),
2. MACKINE. Foxboro Fox-l (16-bit minicomputer designed primarily for industrial
control applications).
3.

SYSTEM CONFIGURATION. (* No information provided. *)

4.

DISTRIBUTION. (* No information provided. *)

5.

DOCUMENTATION. (* No information provided. *)

6.

MAINTENANCE. (* No information provided. *)

9.

Extensions: STOP statement,

based

on

Pascal-Po

(*

11. LIBRARY SUPPORT. (* No information provided. *)

Fujitsu FACOM 230

1. IMPLEMENTOR/DISTRIBUTOR/MAINTAINER. Masato Takeichi, formerly at Department of Math.
Engineering and Instr. Physics, University of Tokyo, Bunkyo-ku, Tokyo 113, Japan. Present
COtDpute.r

SCience,

in

with

FASP. The initial version began \'1orking in October, 1975,

c:n

TEL 015-138222 TELEX

Person-months to create system not reported. *)

of

written

rn

RELIABILITY. (* No information provided. *)

Department

monitor

11. LIBRARY SUPPORT. (* no information provided. *)

10. DEVELOPMENT METKOD. Interpreter of P-code written in FORTRAN

1-5-1 Chofugaoka, Chofu-shi

Pascal

after 2-3 months of work.

MEASUREMENTS.
interpretation speed--fairly slow
interpretation space--14K (much overlaying involved)
execution speed--fairly slow. (interpreted with software paging)
execution space--(* No information provided. *)

address:

a

Harris/4

7. STANDARD. Restrictions: sets limited to 48 members.
program controlled trace facility, optional profiler.
8.

process

0

University

of

Electro-Communications,

Tokyo 182, Japan.

2.

MACHINE. FACOM 230-38, 224K bytes.

3.

SYSTEM CONFIGURATION. OS2/VS. (* Minimum hardware required not reported. *)

4.

DISTRIBUTION. (* no information provided. *)

33~67

:ri·.'l!:'.r. Ei'r!~l>.\·!J'r~C P l\SCJ\L P 4 SYSIJ_'j':J\i ON l\. Ill\ l::[,{I S/ 4 COjliPU"fr.:::H..

r.t IJhO-iJ:;bc ~_ }C hCi\'C (-,'. lla.l'r:l ~;/t1 lr;ach.i.~lC "Jith 64l~ of 24 bits words.
\'he:_ implcHK:nc.at:Loi"l \V"'0 done as a. stu~J-:'nt task by O.~·l. van W-ijk from Delft
Un.L\'ersi Ly of Tec}Hlology, def)'::),ri.:emenL of rnathemat..l_cs. Starting- with an
irnnlement,at:i.on kit, obtained Leon E.T~IJ~-Zurich iL took about: 600 hours to
get a :Cl.1nn:i n9 '.,"ert~.i.()ll of t~he compi.le:( th2lt could compi_le .1, tself.
']:h(; P&.sc(),l r:~)lst(}m tt'~n cO:i1si~;;t(-:;d of tfH? p4-compilf.!l", an assembler for t.he
pcude inst:rnction:3, \'ll:'itt,(-'n in fortran! and a runtirne syst.em of about: 11K
Harr:i.f~ c; C,S(jlu~)l.cr code.. The fortrQ.n p4· -asscTPbler sc&ns' the pc ode two tirnes
ancl gen0J.'('1.·l.C~,; d-u::..-:i.nq tho s0-cond scan J inl-ccd p.age::; of subroutine calls.
One page :.;-~ 102!" lilo:n~L:: corte -! :2 \'lordr:.: link_, thc-,se pag-es arQ stored 0;1 disk.
Hunnj.ng a P(,~:"_;ccll pro~f:c(lm is dODe by lO<1dj,ng t}"Je run'tirr:.e system, vlh:Lch is
<1 normal bC::1ckgro\Jllu P)~~ogJ:all1. 11'11:i.5 prc~!:rar!l has tVlO par;:lmet:c::::cs I onc to spccJfy 1:J18 disk fiIe contain:i.ng the pa~T(C-;!.:; vri.."ch the program object, the
second to f:;pccify tbc number of
}leld in core ~ 'I'he pages are alloca~
tc!o in the p~·:.ge c.:CCD, <"'1nd_
acco:cding- the 'lc~i.ist recently used t algorithm. In this construction the code Sj.Z8 of a PaDcal program js not
lil1tit.cd by the size of the J;F:;ch).nes ccn:e, and illIO'\'..Js the l1se of rnax.-LmUItl
37K of the clvaileblc t~2K core r for Pcu::cal duta on st.ack and heap. Rllnnin9
PaBcal thi.!:.; way v:.i.-Lh 15 page:.? in corc, it t:akes th0 compiler about 6 min.
to cornptlc ~i.t,sulf ~
The s8con(1 f~ta~Jc of t.he implc:n1'2nt_atic))'1 \\~as making somc?: extentions to the
cOlr.piler and slight changes .i.ll thE:; code g·eneration. Extentions were made
to allow the use of external procedurss of different kinds of -sou]:ce
J.an~Jua,gGn.
( Pasca.l, fortran r Barr is: (lssemblcr.) External procedure..; ar(~
decL:lred in i-) prefix to the Pasca.l progr('.ICt~ The t.ype of para.meters of
e)~{_ cl·':)a.l procG.dures is r8FtJ_':!.cb:::.d to t.h~ st.andard types. Soft.-_vJ2.rc to
c·--c< '~.C' 'l.ib.l:·,_~J·-:.(~S Vla~ /}C'vcl01.H_~ll. Extcrnc.i.l p:cocedur-ef; of Pa::;cal .c:::ourcc aTe
st\)1-:-~::;d OH di~.:;k in pcode fOX-il1. end inc:-tndc:d by t_hE pli-assc:mhJer f
nO\'l a_:U.:,;o

written in P0scal, on the p~~;2 file. External proc2durcs of fortran/asE0H!hler. source a.re st.orccl on disk as y:clocat.ablc---: nlod~jlc.sF included by
the p4~assel~bler as one record on the l?age filej loaded a;~d relocated by

-c
-l

rn
3:
tJ::I

rn
;::0

lD

N

the runtime system. The use of external procedures also allows a kind of
fortran-like direct access I/O, which was, among the use of existing pro
grams, the main reason to make this extension.

so on.

scheme for running Pascal

core layout

This now appears to be working and I have run a few hand compiled programs
However memory size limited the amount of~I iroUld give the CDDE and

through it.

This is alright for running small programs but the compiler itself

U>

would not fit.

I have thus taken that interpreter and split into two phases - a

J>

The load phase

produce the internal form of code on a disc

now~two
file,~than

passes over the P4 code to

in an array.

The run phase

is then a stripped down version of the normal interpreter with ell irrelevent detail

(post mortom dumps, trig functions etc.) eliminated.

This will have a biggish CODE

array and will basically operate on a virtual storage concept.
fORTRAN but I will rewrits it in HP assembly soon.

This is still in

Thus as soon as I can get a

compiler for the HP compiled I should be able to compile programes, but I feel thet
recompiling the compiler will be beyond me.
Now for the Univec.

I am modifying the original FORTRAN interpreter to make

allowances for the difference in architecture, ~ etc. and will move that on to the
Univac soon.

Then by the usual bootstrap operation I will get PASCAL up there.

That done I will probably bootstrap a more effective (non ininterperative) system
probably the BELfAST compiler for the 1900 series.
Thus by the end of July I should be able to compile programes (albeit slowly) on both

(* This machine is based on the LSI-II microprocessor from DEC and
it is believed that the DEC LSI-II (San Diego) implementation will run
on this machine; though nothing definite has been reported. *)

machines and by the end of the year have efficient systems going on each.

Next year

all my students will learn PASCAL of as a first language as a matter of course in
their algorithms and problem solving course.

Hewlett Packard liP-2IMX (Durban)
See also IIERE AND

TH~;RE

News section under Tao-Yang Hsieh.

UNIVERSITY OF DURBAN-WESTVILLE

Hewlett Packard IIP-2l00 (Trieste, Italy)

Private Ba9 )(5400 I,

relephone: 821211

Durban.

relegrams: INKOL
Rei.

1. IMPLEMENTOR/DISTRIBUTOR/MAINTAINER. Mattia Hmeljak; Instituto di Electrotechnica ed
Electronica; Universita di Trieste; Trieste, Italy; Tel. 040-733033.

4000.

DEPARTMENT

OF

C.C.

COMPUTER

SCIENCE

2.

MACHINE. Hewlett Packard HP-2IOO.

3.

SYST&~

CONFIGURATION. (* No information provided. *)

HANDLEY.
4.

DISTRIBUTION. (* Unknown, implementation not yet complete. *)

Preliminary report on implementation of PASCAL on
HP21MX and Univac 90/30.

5.

DOCUMENTATION. (* Unknown, implementation not yet complete. *)

We bought the P4 system from Zurich early this year and after a few hassles with

6.

MAINTENANCE.

7.

STANDARD. (* No information provided. *)

fronts, namely implementation of the PASCAL defined by the P4 system on the two

8.

MEASUREMENTS. (* Unknown. implementation not yet complete. *)

machines mentioned.

9.

RELIABILITY.

block sizes, end of files and character sets, managed to get the files to tape and
also listed.

(*

Unknown. implementation not yet complete. *)

Since then I have been attacking the problem on two roughly parallel

My major effort has been on the HP as I have easier access to it.
the P4 interpreter in (of all things) FDRTRAN chiefly because

I heve rewritten

could make use of

its horrible features, such es EQUIVALENCing REALs and INTEGERs for the stack and

J>

STACK arrays.

load phase and a run phase.

Heathkit 11-11

""C

(*

Unknown, implementation not yet complete. *)

10. DEVELOPMENT METijOD. A P-code interpreter written in HP-Algol.
11. LIBRARY SUPPORT. (* No information provided •• )

n
r

Hewlett Packard lIP-3000 -- Miscellaneous

See also HERE AND THERE News section under Kurt Cockrum
works at Boeing (CAD) in interactive graphics).
IA

8.

and

R.

A.

Lovestedt

(who

Also, on 77/07/25, Edward o. Thorland, Computer Center, Luther College, Decorah,
52101 (319/387-1043), phoned that he was ordering the P4 compiler to start an HP-3000

implementation.

I1EASUREMENTS. Compiler object size is about 100 kilobytes.
compilation speed--about 350 lines/second.
execution speed--comparable to FORTRAN-compiled objects.
execution space--(* No information provided. *)

9. RELIABILIT~. Good. (* Number of
reported. *)
10. DEVELOPMENT

sites

using

system

and

date

first

released

not

MET~OO.

A 5200 line Pascal program created by modifing Naegeli's Trunk
compiler and bootstrapping it by Pascal-P. Required about 3 person-months to complete.

=

rn

C/l

11. LIBRARY SUPPORT. None - the compiler produces absolue code, not relocatable modules.
Hewlett Packard HP-3000 (Santa Clara)
Honeywell 11316
1.

IMPLEMENTOR/DISTRIBUTOR/MAINTAINER. Ronald Danielson; University of Santa Clara; Santa

Clara, CA 95093; 408/ 984-4482.
2.

MACHINE. Hewlett-Packard HP-3000/Series II.

1. IMPLEMENTOR/DISTRIBUTOR/MAINTAINER. Robert A. Stryk;
55424; 612/ 887-4356.

3.

SYSTEM CONFIGURATION. Runs under MPE with 256K words memory.

2.

MACIII~E.

3.

SYSTEM CONFIGURATION. (* No information provided.

4.

DISTRIBUTlUN. (* No information provided. *)

5.

DOCUMENTATION. (* No information provided. *)

6.

MAINn:NANCE. (* No information provided. *)

4. DISTRIBUTION.
is 78/01.

(* Unknown, project not yet complete. *) A very rough completation date

5441

Halifax

Lane;

Edina,

~

Honeywell H-316.

5.

DOCUMENTATION. (* Unknown, project not yet complete. *)

6.

MAINTENANCE. (* Unknown, project not yet complete. *)

7.

STANDARD. (* No infonnation provided. *)

8.

MEASUREMENTS. (* Unknown, project not yet complete. *)

7. STANDARD.
Pascal.

9.

RELIABILITY. (* Unknown, project not yet complete. *)

8.

MEASUREMENTS. (* No information provided. *)

10. DEVELOPMENT METHUD. Via Pascal-Po

9.

RELIABILITY. (* no information provided. *)

11. LIBRARY SUPPORT. (* No information provided. *)

10. DEVELOPMENT METHOD. (* No information provided. *)

*)

A modified implementation of Concurrent Pascal, which varies from Standard

11. LIBRARY SUPPORT. (* No information provided. *)

HITACHI Hitac 8800/8700 (Tokyo)
Honeywell 6000

(* See also implementation notes for IBM 360/370. *)
1. IMPLEMENTOR/DISTRIBUTUR/MAINTAINER. Teruo Hikita; Kiyoshi Ishihata; Department
Information Science; University of Tokyo; Tokyo, 113, Japan; 03-812-2111 x2947.

of

2.

MACHINE. Hitac 8800/8700.

3.

SYSTEM CONFIGURATION. 057 (Hitachi). (* Minimum hardware requirements not reported. *)

4.

DISTRIBUTION. Reluctantly.

5.

DOCUMENTATION.

'Pascal

Trunk' are available
documentation. *)

6.

from

8000
above

Reference

t1anual',
and 'Bootstrapping Pascal using a
(* Apparently
no
machine
retrievable
address.

MAINTENANCE. No formal support can be promised. Bug reports are welcome.

7. STANDARD. differences: standard procedures pack and unpack not implemented; files must
be declared at main program level; extra loop control structures; Itvalue" initialization
part.

1. IMPLEI1ENTUR/DISTRIBUTOR/MAINTAINER. Implementor: W. Morven Gentleman; Mathematics
Faculty Computing Facilty; University of Waterloo; Waterloo, ONT. N2L 3Gl; CANADA; 519/
885-1211. Distributor: Honeywell Information Systems; 7400 aetro Blvd.; Edina, MN 55435;
(* See local HIS sales office. *)
2. MACHINE. Honeywell 6000, level 66 series. Operates
76/03/08 *) a DRL TASK version is under consideration.

3.

SYSTEM

CONFIGURATION.

Honeywell

level

66

or

under

GCUS

(TSS).

Currently

(*

6000 series with EIS. Minimum of 26k

words.

4.

DISTRIBUTION. (* No information provided. *)

5. DOCUMENTATION. From Honeywell Information Systems; Publication Dept.; MS-339; 40 Guest
St.; Brighton, MA 02135: "A Pascal Product Brief", (IIAI,66, free), 2 pg. (marketing
oriented) and "Pascal User's Guide", (IIA\,65, $1.30), 30 pg. (reference manual). Machine
retrievable supplement to Pascal User Manual and Report; also includes extensions,
restrictions, known bugs, etc.--about 45 pages total.

6.

MAINTENANCE. Supported by HIS.

7.

STANDARD. Restrictions:
-Program statement not accepted. replaced by required procedure 'main'.
-No files wi th components of type file.
-Only files of type char may be read or written.
-Sets limited to 72 members (no sets of char).
Extensions :
-Files may be opened dynamically.
-Extended file handling is available.
-External separately compiled Pascal and FORTRAN procedures may be used.
-Various procedures and functions to provide access to operating system.
-Optional left-to-right evaluation for Boolean expressions and 1£ statements.
-'else' clause in ~ statement.
MEASUREMENTS.
compilation space--minimum of 26k words. Typical programs require less than 30k words
compilation speed--(* No information provided. *)
execution space--can be as small as 4-Sk words depending on the program and the
Pascal support routines required.
execution speed--(* No information provided. *)
(* How this compares to FURTRAN and other languages not reported. *)

8.

9. RELIABILITY. (* No information
system. *) Distributed since 76/05.

provided

on

reliability

Our thanks to W. Bruce Foulkes for sending us new and complete information on his
implementation which now, we are pleased to find, is improved, upgraded, and more
standard!
Also thanks to Richard Kieburtz for sending new information plus an explanation as to
the cost of SUNY Stony Brook Pascal. It is a credit to their dedication to Pascal that
they continue to support an ISt1 compiler when they no longer have IBM equipment!
One final note: Thanks to Philip Malcolm (Computer Associates, Park House, Park
Street, Maidenhead, Berkshire SL6 lSL United Kingdom) who phoned twice this summer to give
us information about plans to evaluate many IBM implementations for the the purpose of
writing production software (on 6 or 8 operating systems!). He found that:

11. LIBRARY SUPPORT. Separately compiled Pascal and FURTRAN routines may be saved and
called from user specified libraries at run time. A post-mortem debugger is planned, but
presently (* 76/10/25 *) far from being implemented.

C/l

1) The Technical Unversity of Berlin has dropped their effort
at
a
P4
implementation and has obtained Imperial College, London's version of a P4
implementation, which "runs nicely ". (* Our only problem here at PUG(USA) is
that no one at Imperial College has told us in writing what they are doing. Here
are
the
names of the PUG members at Imperial College:
P.W.R.Clarke,
R.A.Francis, Jeff Kramer, Stuart James McRae, Greg Pugh, David Slater, lain
Stinson, and Dave Thomas. Their address: Department of Computing and Control,
New Huxley Building, Imperial
College
London,
180 Queensgate,
London,
England SW7 2AZ United Kingdom (phone: 01-589-5111).
Well, how about it?

or number of sites using

10. DEVELUPMENT METHOD. (* No infonnation provided. *)

rn

*)

2) He was procuring the Australian AEC version of Hikita's Hitac-8000 compiler.
3) He rejected the SUNY Stony Brook version.
C/l

4) He could not get the source for the Manitoba version or the source of the run
time system of the Grenoble version.

rn
""""Cl

---i

5) Ruled out virtual memory, and thus the Vancouver version.

rn
3:
ttl

6) Still awaited news from Oslo and from Stanford.
IBM Series 1
Philip promised a followup report and evaluation and we certainly look forward to it.

rn
;;0

-Andy :Uckel
Gus Bjorklund, 2250 Coppersmith Square, Reston, VA 22091, reported in late June that
he had an IBt1 Series 1 implementation nearly complete and should be finished by 77/9.

AUSTRALIAN ATOMIC ENERGY COMMISSION
NUCLEAR SCIENCE AND TECHNOLOGY BRANCH

IBM 360, 370 -- Introduction

RESEARCH
TELEGRAMS
TELEX:
TELEPHONE

As with DEC PDP-lls, requests for and news about IBM 360/370 i~plementations abound.
Last year we tracked over ten different implementation efforts. We have news for this
issue of PUGN regarding improvements to the Hitac-BOOO compatible compiler which has been
converted to IBM systems by the Australian AEC, as well as about the t1anitoba and SUNY
Stony Brook compilers. Following these, summaries
are
given
for
other
known
implementations based on news from last year.
Teruo Hikita's University of Tokyo Hitac-8000 compiler attracted our interest last
fall when it was announced as being (1) written in Pascal, (2) very fast (as fast as the
Fortran compiler), and (3) adaptable to IBM systems. Apparently the project ran short of
resources and not much news developed until Joseph Mezzaroba (PUGN #8) coaxed a copy and
with a team of graduate students had it running in three weeks under DOS. This summer news
came from the Australian Atomic Energy Commission (AEC) that they have finished the job
with respect to making Hitac-8000 Pascal available on IBM systems to non-commercial sites
only. So now we list Hikita's compiler under Hitachi Hitac-8000 and replace its IBM entry
with the AAEC. Joseph Mezzaroba indicates that they (at Villanova) have switched from
their version of the Hitac compiler to the AAEC version.

ESTABLISHMENT,

NEW ILLAWARRA

ATOMRE, SYDNEY
24562
531-01ll

IN REPLY PLEASE QUOTE:

JMT.mwb

Mr. Andy t1ickel,
Editor, Pascal Newsletter,
University Computer Center,
227 Experimental Engineering Bldg. ,
University of Minnesota,
MINNEAPOLIS MN 55455.

ROAD,

LUCAS HEIGHTS
ADDRESS ALL MAIL TO
AAEC RESEARCH ESTABLISHMENT
PRIVATE MAlL BAG, SUTHERLAND 2232
N.S. W. AUSTRALIA

20th June, 1977.

Dear Mr. Mickel,
On the 18th March, 1977, we received a copy of Pascal 8000 from
Professor Teruo Hikita, university of Tokyo, Japan. Pascal 8000 was
developed for use on a Hitachi IIMII series computer, reputed to operate
under an IBM370 compatible operating system. With a few modifications
to the run-time system, we brought up Pascal on our IBM360/65 in only
a few days.

<.D

Vl

Basically, the compiler is excellent. The language implemented is
very nearly standard Pascal with some very significant extensions. The
compiler itself is written in Pascal 8000, and produces very efficient and,
in general, compact machine code.

In the majority of cases, execution

speed of compiled code is faster than that of a similar program compiled
under FORTRAN G. The original version of the compiler coMpiled itself in
about 290K bytes.

The system currently being distributed produces object.code in a form
suitable for its own internal loader; the code produced by the compiler can
be saved for later execution (one example of this being the compiler itself),
but cannot be linked with other modules. We are, however, in the final testing
stages of a version that produces standard IBM linkage-editor compatible object
decks, and linking to externally compiled Pascal, Fortran and Assembler routines
is supported.

This new version will be distributed as well as the original, as

each has its own advantages.

Since March, we have been developing further the compiler for OS and VS
on IBM360 and IBM370 computers. We have completely re-written the run time
system in assembler (it now occupies 6K bytes instead of 36K) and in so
doing have extended and implemented various features such as local file
processing (in the true sense, not just temporary datasets), extended
addressing (procedures can now be up to 24K bytes in length, rather than 4K),
and various traceback and post mortem dump routines. Further, files of
RECFM=F.(B) (A) and V(B) (S) (A) are supported for both input and output.

We are enclosing a brief description of our Pascal System.
are very welcome, and order forms are available from

Yours sincerely,

,"-V (0i,zC__
.\, --/f 4)~

Several areas of the compiler have been restructured and extended.

J. M. Tob~ls
G. w. Cox
Systems Design Section

Procedures PACK and UNPACK are implemented, so now a true superset of standard
Pascal is accepted by the compiler. Internal mechanisms of code generation were
changed and new functions and standard type names added. Exponentiation has been
included, parts of the lexical analyzer have been rewritten, and code has been
optimized in several areas. It is now possible to compile small programs in l28K,
and the compiler compiles itself in 2l0K (corresponding figures were l76K and
286K in the original version).
.
We are now making this modified IBM360/370 version of Pascal 8000 available.
Distribution arrangements have not quite been finalised, however, it is envisaged

that support for ·the system will be provided.

All enquiries are very welcome.

1.

Fully implements 'standard Pascali, with some very significant extensions.

2.

Compiler is itself written in Pascal.

3.
Total system size is relatively small. Moderately sized programs may be
compiled in 128K, with the compiler able to compile itself in 210K.

Je~f~ey

4.

JMT.mwb

19 August, 1977.
Mr. Andy Mickel,

Editor, Pascal Newsletter,

University Computer Center,
227 Experimental Engineering Building,
university of Minnesota,

PASCAL 8000 - IBM360/370 VERSION

YO;1~ce~el~C0
Tobias Systems Design section
Gordon W. Cox

IN REPLY PLEASE QUOTE:

All enquiries

~s.

.

Datasets of RECFM = F[B][SJ[AJ, v[B][SJ[AJ or U[A] are supported.

5.
Fi:es may be ex.ternal,or local. Thu~, structures such as 'array of files'
are ava11able. External f11es are named 10 the program statement, local files
are not. Both external and local files may be declared in a procedure at any

level.
6.

Arithmetic is performed in double precision.

7.

Control of input and output formatting is as described in Jensen and

Wirth (1975).

MINNEAPOLIS MN 55455 U.S.A.

x(:n(:m]J,

Dear Mr. Mickel,
We have now finalised the distribution arrangements of our

IBM360/370 version of Pascal 8000. As you know, this system is
based on Hikita's PASCAL 8000 compiler, which has been extensively
modified and adapted by us for the O.S. family of operating systems.
Important features· of this system are small memory requirement for
compilation (128K for small programs), extensive file support including
local files, and full traceback and post-mortem dump facilities.
we are distributing this system, including documentation, source
and object code for a ·fee of A$50. This is to cover handling expenses
only; no charge is being made for development of the system. We also
require that·an agreement be signed to· the effect that the provided
system will not be used for profitable purposes.
Our policy with respect to maintenance of the system is that no
written undertaking can be given; we are, however, very keen to hear of
any problems that may arise, and we hope to be able to provide solutions.

The torm is
where nand m are integer expressions.

Elements of type packed array of char may now be read on input.
Procedures read and write have also been extended to apply to both non-text and

text files.----

8.

-----

Procedures have a maximum size, depending on their static nesting level.

This size ranges from 4K to 24K of compiled code.
9.

Some.of the language extensions include:
(i) Constant definitions for structured types.

It is therefore possible to

have arrays, records and sets as constants.

(ii)
(iii)

A

'~'

A

.~.

statement of variable initialisation.
statement of the form:

~  ~  ~ 

where  is of type set.

C/)

(iv)

(v)

A 'loop' statement, specifying that a group 6f statements should be
repeatedly executed until an 'event' is encountered. Control may then
be transferred to a statement labelled by that event.

The types of

par&~eters

of procedures or functions passed as parameters

must be specified explicitly, and this enables the compiler to guarantee
integrity.
(vi)

(vii)

The 'type identifier', restriction in a procedure skeleton has been
relaxed to allow 'type'.

July 13, 1977

Functions 'pack' and 'unpack' are supported, as are packed structures in
general.

Dear Andy:

(viii)

Exponentiation is fully supported, and is used via the double character
symbol

(ix)

'**'.

A 'type-change' function has been introduced that extends the role of

Enclosed
This version
releases. I
have earlier

is information about the latest release of the Manitoba Pascal Compiler.
is more standard, more complete, cleaner, and more reliable than previous
am sending complimentary copies of this release to the thirty sites which
versions of the compiler. Work on the file support is now in progress.

'chr' and 'ord'.
(x)

Case-tag lists may now range over a number of constants, without
explicitly having to list each constant.

1.

Implementor and Distributor
Dr. W. Bruce Foulkes
Department of Computer Science
University of Manitoba

Winnipeg, Manitoba
Canada
R3T 2N2
(204) 269-3363

The range is denoted by:
 .. 

2.

Thus,

4,6 •. 10,15,30 •• 45

3.

is now a valid case tag list.

C/)

Machine

~ 360/370,

AMDAHL 470

rr1
-0

Environment
The compiler has been installed under the following operating systems:

-l

MFT, MVT,

VS1, VS2, MVS and CMS (with modifications to the interface routines).
A region of l80K bytes is required.
(Absolute minimum is approximately 160K bytes.)

A default exit is also supplied via

This path

11.

O~ject

code produced by the compiler is compact and efficient.
In general,
speed of PASCAL 8000 programs is faster than that of similar programs

Maximum set size is 64 elements.

Reference
1.

'Pascal - User Manual and Report', Kathleen Jensen and Niklaus Wirth,
Springer Verlag, Second Edition, 1975.

July 1976 version released to 30

=

We require a "SOFTWARE RELEASE AGREEMENT" to be signed.
Cost: $50 for June 1977 release.
Medium: 600-ft. 9-track tape which we provide.
5.

Documentation
Two manuals are included in machine-retrievable form:

"MANITOBA PASCAL USER GUIDE"
"MANITOBA PASCAL CODE GENERATION"

48 pages.
84 pages.

6.

Main tenance
I have supported the compiler since December 1975 and intend to continue, but
I am not in a position to make a formal commitment.
I welcome comments, suggestions, and even bug reports.

7.

Language Supported
Many non-standard features of earlier versions have been eliminated in this
release. Some examples are:

13. Procedure 'new' is fully supported, obtaining the m1n1mum heap requirements
as specified by variant tags. Procedures 'mark' and 'release' are also supported.
Procedure 'dispose' is not supported.

First released in December 1975 to 10 sites.
sites. June 1977 release is now available.

Distributed in load module and object module form with assembler source of the

wr1tten 1n FORTRAN G level.
12.

Distribution

interface routines.

10. Execution errors terminate in a post-mortem dump, providing a complete
execution histo~y that includes procedure invocations, variable values, type
of error, etc.

ex~cut1o~

to
rr1

4.

else: 
i.e. else:
is a valid case tag in every case statement.
will be used if none of the other tags match.

rr1
.3

_ predefined types are now global.
output formatting has been standardized.
[ and] are now allowed for arrays and sets.
(* and *) are now allowed for comments.

PACKED is ignored.
program header is optional.
etc.

-0

:.t>
G>

rr1

to
'.J

Pzscal Compiler Project
Dept. of Computer Science
State Univ.
New York
ot Stony Brook
Stony Brook, N. Y. 11794
July 15, 1977

of

IBM 360,370 (Stony Brook)

Restrictions

- Only the standard input and output files SYSIN and SYSPRINT are supported. All
I/O is accomplished through the use of READ, READLN, WRITE, WRITELN, EOLN, and
EOF.

(This is a temporary restriction.

Work on file support is in progress.)

Procedures PACK and UNPACK are not implemented.
Branches to global labels are not allowed.
SETs of characters. are not supported (temporary restriction).
Built-in procedures and functions are not accepted as actual parameters.
The maximum static nesting of procedure and function declarations is 5.
Program segments are restricted to 4K bytes of code.
Extensions

- Three additional scalar types are supported:
LONGREAL(LREAL), and STRING(n) 1$n$256.

SHORTINTEGER(SHRTINT),

- A substring operation is provided.
- Formatted input is provided and input of BOOLEAN and STRING values is permitted.
- hexadecimal constants are supported.
8.

Compiler Development
The compiler is one pass and uses a top-down parsing strategy.
All semantic
routines are written in PL360 (about 13,000 lines) and system interface routines

in Assembler (500 lines).
The run-time routines are written in PL360 (1600 lines) with an Assembler

interface (500 lines).
Compile speed averages 500-1000 lines of source per second on an IBM 370/168.
Considerable effort has been spent on localized optimizations in areas such as
array subscripting, record field accessing and boolean expression evaluation with
the aim of producing a compiler suitable for the compilation of application programs.

(A 3l00-line Assembler/Loader/Interpreter system has been written locally in PASCAL
and is in production use on our student terminal.)
The compiler has been running on our express student terminal since January 1976.
I haven't run any speed tests recently, but execution speed seems competitive

telephone: (516) 246-7146

!\ndy Mickel
University Computer Center
227 Exp Engr
University of Minnesota
Minneapolis, Minnesota 55455

rn
~
C/)

Dear IIndy:

Enclosed is cn anouncement of the

Reliability
Good and getting better.

(Some routines were borrowed from the translator-

Stony

C/)

rn

mach ine time and we are just breaking 2ven (so far) on our $175
distribution fee.

-l

jt

works. Needless to

52-y,

\\'f'

eDJ3~~-,-

-0

rn
3:
t;d

rn
::0

Richard B. Kieburtz

have been remedied.)

The compiler was hand coded.

th~

must pay for

inconvr::-nient, but

(All problems which have been brought to my attention

10. Method of Development

rcle2se of

lis some of your readers may know, Stony Brook has not had an
IBM 370 for over a year and a h31f, 2nd '#2 now no 10ngC'r have
ellen the Univac Spectra 70 on which the Pascal/360 compiler
could be executed. Our present mode of operation involves doing
all machin"O-independent development work on 3 Uni'J2c 1110 at
Stony Brook, then installing new developments and testing the
operating system interface on an IBM 360/65 at Polytechnic
Tnstituto of New York. This arr,'Ongement is slightly

with the IBM Fortran G compiler.
9.

new~st

Brook Pascal/360 compilers, for publication in the Pascal
NewslettFr. We hove distributed over 100 copies of Release 1,
and under our distribution policy, those who ordered Rel02se 1
will receive Rele~se 2 automatically.

StonyBrook

writing system SYNTICS.)
The project was begun in the summer of 1972 and is still continuing.
I have
spent a total of 60 man-months on the project but was also teaching for 40 of those

months, and have been distributing the compiler (copying and mailing tapes, etc.)
for the last 20 months.
This is my first production compiler, but I now have five years experience.
11. Subprograms
The compiler produces OS-compatible object modules and uses standard IBM linkage
and parameter lists in calls of external routines (Fortran, etc.).
Separate compilation is not yet supported.

If people are interested in the compiler, they can write to me at the above
address and I will send them a copy of my user manual, a description of the distribution tape contents, and a Software Release Agreement and order form.
Best regards,

~-:r~
Bruce Foulkes

STONY BROOK PIISCl\L/J60;

RELE~SE

2.0 liND RELEASE 2.5

ThE' second release of th'" Stony Brook Pase'?l comoiler
for IBM 360 and 370 computers is 110,"/ re~dy for distrib~tion.
!

r

z

;,mplement'20?! stor-Jgc: m;;:ln,:g0ment SChen:0 usi.r,g t.wo-l,2\lcl
rrT
Relt?asp 2.0 implements Standard Pase2l, including indi.rection (se0 [21 for n general chScusslon) 1n whICh a
::;;::
external, ?Ons~and"rd filE~ (implemented using the QSII.'I pointer Jctually is an index into a stor?g0 dpscripto~ tobIe,
C/)
r.ccess methoa). WIth the followIng enhcnc('ments:
invi.sible to th.-;" usr:-r. Descriptors contaIn ~ h'i'ap 2odrcss, 2
hold count, nnd " pointer to 2 stor3ge template. This has th. III so , ~ange~ of constants are "llowso ,2S case
in its heading. External references are declared by gl'lllng a
Ilabels. Thp cardInal lty of " label r2ng2 is not bmlt"" by
proc"dure or function declaration, in which the body is,
Obviously, it is possible for inaccessibl(>, but cyclic any implementation r('stric~ion, but only by the coor.din?lity
replaced by the KGyword ext.ernal. A rna In progrz:m can 2:1so d0ta structures to '?x ist und,-,tpcted 2nd to congest the i of j ts base type. Thr- Imp1effientatlon uses .:3 combln?.tlon of
contain  garbage collection, within the array of fixed-length
program module in .,hich they ere declared.
descriptors.
B. Diagnostic aids
The two pr incipal run-time (Jiagnostic aids provided by
Ea ch compilation prepares an output fil" called a Pasc,al 4. 5trinq processing (to be implemcnted in Release 2.1)
the P2sca]/360 compiler 2r'2 a symbolic, post-mortt'm dump of C/)
Object Module, which contains not only code and data, but
II new, built in type, String, h2'S been added. Values of ,'ct i liP viJriables, ~nd an execution-count profile printed on a rT'l
also .; symbol table describing the names, types, and stor2ge this type are varioble-l"ngth strings over type Char.
formatted source listing. These dbgnostics in Release 1 have ""0
given to its entry points and external references. A new Oper?tors are 211 realized by means of rreccclared funct ions;
proven to be valui"bl2 tools for amlysis and debugging of - I
system module called the Pasc21 Linker accepts Pascal ObJect n'o n progr,3m linker.
The pr incipal reason for this extension is that it
allows the dec1aratjon of subrange types whose bounds can be
al tered wi thou t recompilation; thus array and set types can
have t.heir sizes adjusted to the demands of an application
merely by re-linking z program. This sch"me is admitedly a
compromise between the desire to allow Algol 60 dynamic
a r rays and the desire not to perturb the type formation rules
of Pascel. Only the experience of users will tell wheth€ r or

5. II predeclarecl type IIIfa h2s been defined to be,
IIlfa : packed array [1 •. 801 of Ch?r

Ref€rencps
[1]

Th i s type is principally intended to permit efficient reading
of fix€'d-length, 80 byte records. I f thE' condition Eoln
becomes true curing on 2tt!'mpt to read a variable of type
[21
IllEa, and prior to r('",ding th~ 80th byte, a read error,
occurs.

K:leburtz, R. B., Two Generalizations of the
Programming L2nguage Pascal, Tech. R0pt. No. 66,
Dept. of Computer Science, SUNY at Stony Brook, IIpril
1977.
Bobrow, D. G., lin efficient, incremental, ?utomCltic
gargabecollector, CACM~, No.9, p.522, Sept.

1976.

rT'l
<.0
<.0

IBM 360, 310 (Grenoble)

IBM 360, 310 (Stanford)

1. IMPLEMENTOR/DISTRIBUTOR/MAINTAINER. J. P. Fauche,
Boite Postale 41, F-38040 Grenoble Cedex, France.
2.

Departement

Informatique,

IREP,

MACHINE. IBM 360/61, 310/148.

3. SYSTEM CONFIGURATION.
for self-compilation.

Runs under OS/MVT (360/61) and VS/MFT (310/148). Requires 220K

4.

DISTRIBUTION. Distribution is via 9 track, 800 bpi magnetic tape.

5.

DOCUMENTATION. The implementation is described in a supplement to the User Manual.

6.

MAINTENANCE. (* no information *)

1.

STANDARD. Deviations are described in the documentation.

8.

MEASUREMENTS. The standard compiler

(6000

lines

of

Pascal)

compiles

in

105

1. IMPLEMENTOR/DISTRIBUTOR/MAINTAINER. Sassan Hazeghi, Computation Research Group,
P.O.Box 4349, Stanford, CA 94305.
2.

MACHINE. IBM 360, 310.

3.

SYSTEM CONFIGURATION. (* no information *)

4.

DISTRIBUTION. The entire system is available to the public (as is).

5.

DOCUt1ENTATlON. (* no information *)

6.

MAINTENANCE. No maintenance is promised.

1.

STANDARD. Implements the Pascal-P2 (May, 1914) subset, with a few minor extensions.

8.

11EASUREMENTS.

u>

CPU

seconds; an enhanced compiler compiles in 84 seconds.

9.

SLAC,

Source lines (Pascal)
Bytes, including I/O.

RELIABILITY. (* no information *)

Compiler
4000
16K

Post-processor

2500
52K

Time to process compiler

10. DEVELOPMENT METHOD. (* no information *)

(310/168, 16K cache)
Source lines per second

11. LIBRARY SUPPORT. Assembler procedures are supported.

10 sec.
400

5 sec.

800

The system self-compiles in 130K bytes, 24K of which is returned to the operating system
for I/O buffers.
IBM 360, 310 (Socorro, New Mexico)

9.

Tom

Nartker,

Computer

Science

Department,

~erillat,

and
Distributor:

New Mexico Tech. Socorro, New Mexico

87801

rn

RELIABILITY. (* no information *)

10. DEVELOPMENT METHOD. Developed from Pascal-P2. P-code was first translated to
1. IMPLEMENTOR/DISTRIBUTOR/MAINTAINER. Implementors: Jan V. Garwick, Paul
Robert Knight, Computer Center, New Mexico Tech, Socorro, New Mexico 81801.

u>

assembly

code by macros; a P-code translator was then written in Pascal. The P-translator can
produce either assembler code or a standard OS object module.

11. LIBRARY SUPPORT.. (* no information *)

(505/835-5126). Direct non-distribution questions to Robert Knight.
2.

MACHINE. IBM 360, 310 series.

3.

SYSTEM CONFIGURATION. OS operating system.

4.

DISTRIBUTION. Released January, 1911.

5.

DOCUt1ENTATlON. (* no information *)

1. IMPLEMENTOR/DISTRIBUTOR/MAINTAINER. lvar Laberg, Computer
Hospital Oslo, Rikshospitalet, Oslo I, Norway (411
20 10 50).

6.

MAINTENANCE. (* no information *)

2.

MACHINE. IBM 310/125.

1.

STANDARD. The following are not supported: gotos and labels; unpacked arrays; and sets

3.

SYSTEM CONFIGURATION. DOS/VS operating system.

4.

DISTRIBUTION. (* no information *)

5.

DOCUl1ENTATlUN. (* no information *)

6.

HAINTENANCE. (* no infonnation *)

IBM 360, 310 (Oslo)

of characters.

8.

MEASUREMENTS. (* no information *)

9.

RELIABILITY. Results of one month of testing were good (16/9/20).

10. DEVELOPMENT METHOD. Designed by Jan Garwick and implemented in PL360 using GPM.
11. LIBRARY SUPPORT. (* no information *)

Department.,

University

7. STANDARD. A number of extensions are being considered, including: interface to all
secondary storage access-methods; external procedures written in other languages; and
"external records" (functionally equivalent to "named common fl in Fortran).

-0

::.>

en
rn
f-'

8.

11EASUREMENTS. (* no information *)

o

o
9.

RELI~BILITY.

(* no information *)

Projected extensions:
McCarthy if.

10. DEVELOPMENT METHOD. Based on Pascal-Po

~

11. LIBRARY SUPPORT. (* no information *)

-0

J:>

and and lower precedence than relations.

en

"Usual" precedence used throughout.

n

Sets over the range 0 •• 255.

,

J:>

Better control of input and output formats.
8. MEASUREMENTS. The compiler is written in Pascal and is modeled after the CDC 6400
implementation, but it has been extensively modified and improved. The translator consists

IB11 360,370 (Vancouver)

1. IMPLEMENTOR/DISTRIBUTOR/MAINTAINER. Barry W. Pollack and Robert A. Fraley, Department
of Computer Science, University of British Columbia, Vancouver, British Columbia,
Canada V6T 1W5 (604/228-6794 or 604/228-3061).
2.

MACHINE. IBM 370/168.

of approximately 8000 lines of Pascal code.··The run-time library consists of approx1onate1y
500 lines of Pascal code. The monitor (which contains the interface to the operating
system) consists of approximately 2000 lines of IBM Assembler G code. The translator speed
has not been determined, but it seems faster than our Algol-II compiler. The code produced
has been timed against Algol-W code and is almost uniformly 10-15% better. This is
especially true of any program using a large number of procedure calls. The compiler
compiles

itself

in less than 60 seconds of 370/168 processor time. The compiler requires

320K bytes of core.
3 •. SYSTEM CONFIGURAtION. The current version runs under the tiTS operating system. The
monitor may be modified with minimal effort to run under VS, OS, etc. Standard OS object
modules are generated. The translator requires about 320K bytes of store. Division of the
compiler into overlays for non-VM systems would be possible.

9.

RELIABILITY. To date has been excellent. A student version of the translator has

running

since

version has

September, 1976,

been

in

operation

with

since

only

been

one detected compiler error. The main system

December, 1975.

All

problems

which

have

been

encountered to date have been corrected.

4. DISTRIBUTION. The current version
magnetic tape. Costs will be limited to
supplied) •
5.

DOCUMENTATION.

A

User's

Guide

for distribution now, via 9 track
tape purchase, if one is not

is available
postage (and

describes completely the implementation's departures

10. I)EVELOP11ENT METIIOIl. The original translator was developed by Wirth and several
graduate students at Stanford University as a partial re-write of the CIlC 6400 version in
1972. The current translator and monitor have been extensively modified, a run-time
library has been implemented, and a post-mortem symbolic dump package has been developed.

The

from the Jensen and Wirth Pascal User Manual and Report.

translator

has been under continuous development at UBC since December, 1975, by two

faculty members and one (* anonymous? *) graduate student.

6. MAINTENANCE. No policy has been decided. It is anticipated that periodic upgrades and
modifications will be distributed at least once a year. Reported bugs will be corrected as
quickly as possible with notification to users.

11. LIBRARY SUPPORT. Fortran routines can be called. The compiler
object modules.

en
generates

standard

OS

--i
f"T1

7. STANDARD. The compiler provides numerous extensions and a few restrictions. A compiler
option issues error messages when non-standard features are used. A complete description

is contained within the documentation provided. A summary of the differences follows.

f"T1
-0

3:

to

IBM 1130

f"T1
:::0

Extensions:
Strings are padded on the right with blanks.

We have heard of two possible implementations, by:

The is a case default label: n<>".

Optional ~allowed before ~.
11( ••• )11 may be used instead of "[ ••• )".

The character

~

(1) H. Sandmayr, Neu-Technikum, CH-9470 Buchs, Switzerland (085/6 45 24).

has been retained.

Packed is ignored.
Input of character strings using read is allowed.
Support of EBCDIC characters "&", "I", and (logical not sign). (* Sorry, we
ASCII at PUG News. *)
Use

II • • • II

(2) Fred Powell, Innovative Management Systems, 865 Middlebrook Av., Staunton, Virginia
(703/885-4950). (Fred was formerly at Mary Baldwin College.) "Little has been done so
far," according to Fred (76/12/10).
use

for comments.

ICL 1900 (Belfast) - MK2.

Value section exists for variable initialization.
Hexadecimal integers are supported.

FORTRAN
subroutines may
pre-declared variable

be

called.

A return

code

is

available

in

the

~.

Direct access files are supported.

.

Additional built-in functions include: min, max, substr (using constant length),
position (direct access files), I/o-interface functions and extensions to
~ and rewrite, and ~ for data packing.
Restrictions:
Sets are limited to 32 elements (0 •• 31).
Program heading is not used.
Files may not be components of other structures.
Set constructors may not include  •• .

Input@

is

initially

eol

instead

transparent when read is used.

1. IMPLEMENTOR/UI5TRIBUTOR/t1AINTAINER. Jim Welsh, Colum Quinn, and Kathleen McShane,
Department of Computer SCience, Queens University, Belfast BT7 INN, Northern Ireland, U.K.
(* No phone number provided. *) Enhancements by David Watts and Bill Findlay, Cooputer
Science I)epartment, University of Glasgow, Glasgow GIl 8QQ, Scotland, U.K. (* No phone
number provided. *)
2.

3. SYSTEM CONFIGURATION. Has been installed under George 3, George 4, Executive,
and COOP operating systems. Requires 32K.

of the first character of the file. This is
4.

DISTRIBUTION. (* no information *)

-0

J:>

MACHINE. ICL 1900

G>

~IMOP,

f"T1

i-'

o
i-'

Intel B080

(I~~ITE)

5. DOCUHENTATION. A clearly written machine retrievable Supplement to the Revised Report,
dated 77/2/23.
6.

MAINTENANCE. (* no information *)

7. STANDARD. Primarily implements the Revised Repo~; exceptions include (a) files not
allowed as components of structured types, and (b) non-discriminated variant records are
not allowed. A six bit character set is used. Sets may have at most 48 elements.

A

value

1. IHPLEClENTOR/UISTRIBUTOR/!1AINTAINr:R. Implemented by Thomas A. Rolander, 1012 Smith
Ave., Campbell, CA 95008 (408/378-5785). Uistributed by INSITE, Intel User's Library,
Microcomputer DIvision, 3065 Bowers Ave., Santa Clara, CA 95051 (408/246-7501 x294B).
2.

MACHINE. Intel H080A using the Intel Intellec Hicrocomputer Development System.

::e:

initialization part is implemented.
8. MEASUREHENTS. Compares favorably to Fortran, requ1r1ng about 32K to compile. Generated
code is better than that produced by the old 1900 Pascal compiler. (* Compilation speed
not reported. *)
9.

z
rn

3. SYSTEH CONFIGURATION. Operating system: Intel MUS ISIS-II. Hardware: 64K bytes of
and dual floppy disks.

RM!

(/)

4. DISTRIBUTION. The software is distributed on two soft-sectored diskettes, and includes
the binaries and sources.

RELIABILITY. Reported to be good. The compiler is in use at about 50 sites.

10. DEVELOPHENT METHOD. This compiler resulted from a complete rewrite of tile old ICL 1900
compiler. The new compiler is designed for portability, with a
semantic analysis and code generation.

clean

separation

between

11. LIBRARY SUPPORT. Allows access to Fortran routines.

5.

DOCUt1ENTATION.

Consists

of

a short User's Guide~ syntax graphs, and the source code

for the virtual machine and the compiler.

6.

11AINTENANCE. Bug reports will be accepted.

7.

STANUARD. Implements Brinch Hansen's Sequential

Pascal,

except

for

floating

point

(which is under development - 77/2/22).
8.

ICL 2970, 2980 (London)

9.
1. IHPLEMENTOR(DISTRIBUTOR/MAINTAINER. John Reynolds and Jules Zell, Department of
Computing and Control, Imperial College, London SI/7, U.K. (* No phone number provided. *)

MACHINE. ICL 2970, 29BO series.

3.

SYSTEM CONFIGURATION. (* no information *)

5.

Contact

The virtual machine interpreter is 1300 lines of code (PL/H-80) and 10K

David

Joslin,

Sussex

RELIABILITY. Will self-compile and has been used successfully by

students.

(* Number

of sites using system not reported. *)

10.
2.

4. DISTRIBUTION.
Sussex, U. K.

HEASUREHENTS.

bytes. Compilation speed is 30 lines/minute. (* Execution speed and size of generated code
not reported. *)

UEVELOP~1ENT

HETHOD.

An

interpreter

(PAS80)

was written in PL/H-BO, and emulates a

16-bit machine. The implementation required about "2 man-months-of-evenings" and was
accomplished in the implementor's spare time. The i~plementor was familiar with the
process of implementing the virtual machine. "Credit for the ease of implementation is due
to Per Brinch Hansen who developed the virtual machine."

University

Computer Centre, Brighton,
11. LIBRARY SUPPORT. (* no information *)

DOCUMENTATION. (* no information *)

6.

MAINTENANCE. (* no information *)

7.

STANDARD. Presumably similar to the ICL 1900 HK2 compiler.

B. MEASUR&~NTS. Code generated is fairly compact, the compiler itself producing 80000
bytes. This is better than the 2900 standard compilers. The (CUC) Pascal 6000 compiler
compiles the 2900 compiler on a CUC 6400 in 82 seconds. The ICL compiler self-compiles on
the 6400 in 100 sees. Running on a 2900, the 2900 compiler self-compiles in 360 seconds.
John Reynolds tells us, "I've determined that almost all time required for a compilation
on the 2900 is just burnt up by the system and that hardly any time at all goes in the
actual act of code generation." (77/7/8) (* Execution speed of generated code not
reported. *)
9. RELIABILITY. The compiler has been extensively tested and seems to work fairly well.
(* Date of first release and number of sites using system not reported. *)

10. DEVELOPMENT METHOD. Based on the ICL 1900 t1K2 compiler, with code generators
rewritten. Poor performance of the ICL 2970 system led to development on a Control Data
7600 using Zurich's Pascal-6000.
11. LIBRARY SUPPORT. (* no information *)

Intel 8080 (Minneapolis)

1. I'1PLEMENTOR/DISTRIBUTOR/HAINTAINER. Peter Zechmeister, University Computer
227 Exp Eng, University of Minnesota, Hinneapolis, MN 55455 (612/373-41Bl).
2.

Center:

MACHINE. Intel B080.

3. SYSTEM CONFIGURATION. An operating system is included with the implementation. The
minimal hardware required is an I/O device (TTY) and about 16K bytes for the compiler.
4.

DISTRIBUTION. Has not been determined.

5.

DOCut1ENTATION. In progress.

6.

HAINTENANCE. Under development.

7.

STANDARD. The implementation is called Tiny Pascal (TP). It does not provide a

-0

:J:>
G>

number

of standard features due to size constraints.

8. HEASURB1ENTS. The bootstrap cross-compiler runs at 2400 lines/minute on a CUC 6400.
The TP compiler itself loads in about 14K.

rn
I--'
<.:)

N

9.

RELIABILITY. !tIe reliability of the compiler is excellent. (* Number

of

sites

using

9.

RELIABILITY. (* no information *)

system not reported. *)

10. DEVELOPMENT METHOD. (* no information *)
10. DEVELOPMENT

METHOD.

Based

on

the PLO compiler by Niklaus Wirth. Modifications were

made to implement "variable types, Pascal statements, code generation, and register
mapping. II A cross-compiler running on a Control Data 6400 has been used to develop the

Tiny Pascal (BOBO) compiler, which

WaS

11. LIBRARY SUPPORT. (* no information *)

not complete as of PUGN #B.
Interdata 8/32 (Parkville, Australia)

11. LIBRARY SUPPORT. None.

1.

Intel 8080a (San Diego)

IMPLEMENTOR/DISTRIBUTOR/MAI~TAI~ER.

Guy

Ward,

2.

MACHINE. Interdata 8/32.

3.

SYSTEM CONFIGURATION. (* no information *)

4.

DISTRIBUTION. (* no information *)

5.

DOCU~IENTATlON.

6.

MAINTENANCE. (* no information

7.

STANDARD. (* no information *)

8.

MEASUREMENTS. (* no information *)

9.

RELIABILITY. (* no information *)

See DEC LSI-11 (San Diego), above.

lJepartment

of

Computer

Science,

3052, Australia (345 1844).

University of Melbourne, Parkville, Victoria

Interdata 7/16
Two possibilities to check out:

Mike

Ball

(see

Interdata

8/32

for

address)

has

Concurrent

and

Sequential

Pascal

(*

no information *)
*)

cross-compilers running on the UllOa generating code for the Interdata 7/16.

Rod Steel, Tektronix, MS 60-456, PO Box 500,
reported

a

year

Beaverton,

OR

97707

(503/638-3411 x2516),

ago that he might attempt to bring up Pascal on the_ 7/16. No news since

then.
10. DEVELOPHENT METrlOU. Using Pascal-J (University of Colorado). Stage2
into CAL (assembly).

translates

11. LIBRARY SUPPORT. (* no information *)

Interdata 7/32

!~E~E~~E~_~L~~_~~~~~~2
See Kardios Duo 70, below.

KRnSRS STRTE unIVERSITY
Department of
Science
Manhattan,
66506
Phone: 913 532-6350

Interdata 8/32 (San Diego)
August 11, 1977
(* See Mike's letter in the OPEN FORUI! section *)

1. IMPLEMENTOR/DISTRIBUTOR/MAINTAINER. Mike Ball, Code 632, Naval Ocean
San Diego, CA 92152. (* No phone number reported. *)

Dear Mr. Mickel:
Systems

Center,

2.

MACHINE. Interdata 8/32.

3.

SYSTEM CONFIGURATION. (* no information *)

4.

IHSTRLBUTION. lilt will not be available for distribution for at least several months."

As reported by Mike Ball in the Pascal Newsletter 117, we have
transported the Brinch Hansen Concurrent Pascal system from the PDP 11/45
to the Interdata 8/32.
This implementation in its present form
uses an interpreter for a slightly modified version of the abstract
code as distributed by Brinch Hansen.
I am enclosing for your
information a copy of the Implementation manual for the system
and the implementation checklist as requested for the Implementation
notes section of the Pascal newsletter.

(77/6/15)
Sincerely,

5.

DOCUMENTATION. (* no information *)

6.

HAINTENANCE. (* no information *)

7.

STANDARD. Brinch Hansen's Sequential and Concurrent Pascal.

B.

MEASUREMENTS. (* no information *)

J

-/C-)

;y) CV~Lf 0-

It- <---<'L-

David Neal
Research Assistant

DCN: tlb
Enclosure (1)

(.7

Janus

1.

10.

Imp1ementors:

Transported from the Brinch Hansen PDP 11/45 implementation.

David Neal, Gary Anderson, Jim Ratliff, and Virgil Wa11entine.

66506
11.

Distributors:

Interchange (Interdata Users Group)

Sequential Pascal programs may call one another in arbitrary,
recursive fashion using the interfaces of the SOLO operating
system (which is written in Concurrent Pascal). No provision

is made for FORTRAN or any other language. The utility programs
of the SOLO operating system include the Sequential and Concurrent

Interdata, Inc.

Oceanport, New Jersey
2.

The

system was moved with an approximate outlay of 4 person-months of
experienced graduate student effort.

Department of Computer Science
Kansas State University

Manhattan, Kansas

Method of development:

07757

Pascal Compilers, a text editor similar to Interdata's OS-Edit, and
the source code configurer program mentioned by Mike Ball (Pascal

Newsletter #7 p. 29). All programs are maintained by the SOLO
file system and appears to OS/32-MT as a single contiguous file.

Hardware:
Interdata 7/32 or 8/32.

3.

lTEL AS/4, AS/5

Operating System:
OS/32-MT, minimum partition size 72.75 K, disk storage required,
floating point support necessary.

See IBM 360, 370, above.
4.

Method of distribution:
Nine track tape -- details available through Interchange.

5.

Kardios Duo 70

Documentation:

See IBM 360, 370, above.

KSU Implementation of Concurrent Pascal -- A reference Manual, KSU

Technical Report CS 76-16 will be provided with the implementation
package. It may be provided in machine retrievable form. The
Brinch Hansen SOLO manuals are not provided with the implementation.
The availability of these references is a necessity.

The Kardios Duo 70 consists of an Interdata 7/32 modified by Kardios Systems Corp.,
3820 Court leigh Dr., Randallstown, ~ 21133 (301/542-6826). The machine includes firmware
which emulates both Interdata and IBM 360, 370 systems. The system is designed to
concurrently execute both Interdata and IBM software. According to Kardios, most software
such as the ISH

6.

Pascal

implementations

will

run

on

the

Duo 70

with

little

or

no

modifications. The changes most often required are: use Interdata CSS instead of IBM JCL;
change IBM file access calls to Interdata access calls (this is only necessary in the few
cases where the IBM file access methods are not supported by Interdata). The Duo 70 will
execute 360, 370 object modules produced by a compiler with no changes at all. Kardios
reports that their customers have reported very little trouble in modifying 360, 370

Maintenence Policy:
None

software to run on this system.

7.

Fully implements Concurrent Pascal and Sequential Pascal (SPASCAL)
a subset of Standard Pascal.
Mitsubishi

8.

Sequential and Concurrent Pascal programs are executed by a code
interpreter written in Interdata CAL assembler language. This
interpreter as well as the Concurrent Pascal Kernel are provided in
source and object. The system consists of about 5000 source lines
and requires a library segment of 7.50 K for execution. Pascal
source is translated into code by the Hartman Compilers which are

written in Sequential Pascal (SPASCAL).

The source and object of

these compilers are also contained in the package.

Microcode

routine for virtual instruction decode are included for the 8/32.

9.

Reliability:
Excellent -- all errors detected at KSU have been traced to hardware.

1.

~ELCOM

7700.

I)1]'LEMENTOR/DISTRIBUTOR/MAISTAI~ER.

~lasato

Takeichi,

formerly

at

Dept.

of

Math.

Engineering and lnstr. Physics, University of Tokyo, Bunkyo-ku, Tokyo 113, Japan. Present
address:
Department
of
Computer
Science,
University of Electro-Communications,

1-5-1 Chofugaoka, Chofu-shi Tokyo 182, Japan.
2.

MACHINE. MELCOM 7700, 256K bytes.

3.

SYSTEM CONFIGURATION. BPM. (* Minimum hardware required not reported. *)

4.

DISTRIBUTION. (* no information provided. *)

5.

DOCUMENTATION. See "Pascal Implementation and Experience" by Masato Takeichi,

£i the Faculty of Engineering, University of Tokyo 34: 1, pp 129-136.

Journal

6.

MAINTENANCE. (* no information provided. *)

7.

STANDARD. Comparable to CII IRIS 80 implementation by Mancel and Thibault.

8.

MEASUREMENTS.

Self

compiles

in

150

sec.

and

150

Kbytes (10SK for code, 10K for

monitor, 32K for data). Execution times, relative to Fortran, are given in

the

following

table.
Extended
Fortran IV
Matrix multiply

Pascal
1.90
1. 75
0.48
0.34

1
1
1

Sort

Additive partition
Character count

6.

MAINTENANCE. (* no information *)

7.

STANDARD. The following are not supported: files (except TTY input

get, put,
unpack.

reset,

rewrite;

with

and

goto;

and

output),

and

sin, cos, arctan, exp, 1n, sqrt, pack, and

8.

MEASUREMENTS. Compiler code occupies 24K bytes, the interpreter requires 3K bytes.

9.

RELIABILITY. Seems to be excellent. Not yet released.

rn

10. DEVELOP~1ENT METHOD. Based on Pascal-P2, cross-compiled first from a Univac 1100 (using
San Diego Pascal), and later from a CDC 6400. As of 76/11/4, about 2 man-months had been
invested. The compiler source is ahout 2200 lines. The cross-compiler has been designed to

be

independent

of the host-machine's character set. The interpreter could be implemented

on other 8-bit machines with minimal work.

9.

RELIABILITY.

Was

first

released

in

April, 1976, with the author using for several

months before that. Several compiler errors have been corrected. (* Number

of

sites

not

11. LIBRARY SUPPllRT. (* no information *)

reported *l
10. DEVELOPMENT

METHOD.

The

compiler is based on the CIl IRIS 80 compiler by Hance I and

Thibault, with modified code generation. The monitor and library procedures were rewritten

Nanodata QM-1

to interface with BPM.
11. LIBRARY SUPPORT. (* no information provided. *)

1. IHPLEMENTOR/DISTRIBUTOR/MAINTAINER. Dennis Heimbigner, TRW DSSG, Mail Station R3/1072,
1 Space Park, Redondo Beach, CA 90278 (213/535-0833).
2.

HITS Altair 680b

MACHINE. Nanodata QM-1.

en

3. SYSTEM CllNFIGURATION. 256K words nanostore; 8K words control store; 60K words main
store; 9755 (55M byte) disk; TASK version 1.04.02 (or later); PRllll version 2.04.01 (or
later). Optional: Card Reader, Printer (very desirable).

(* See implementation notes for Motorola 6800. *)

4.

DISTRIBUTION.

ttRelease

by

TRW

is

currently

under

consideration.

Inquiries

are

welcome." (77/3/17)

HOS Technology 6502 (San Diego)

5.

rn
-0

-I

rn
:;;::
t;d

rn

DOCUMENTATION. Brinch Hansen's SOLO manuals (not available from TRW); machine readable

;;0

document describing the implementation and ways to modify it.

See DEC LSI-ll (San Diego), above.

Motorola 6800 (San Diego)

6.

HAINTENANCE.

(* no infonnation *)

'I.

STANDARD. (* no information *)

8. 11EASUREMENTS. Executes at about one-third the speed of
(* Space requirements not reported. *)

9.

See DEC LSI-II (San Diego), above.

the

Pl)Pll/45

(SOLO)

system.

RELIABILITY. (* no information *)

10. DEVELOPMENT

METHOD.

The Concurrent Pascal system kernel was programmed in micro-code

in 6 months of part-time work. Half of that time was spent on I/O drivers.

Motorola 6800 (St. Paul)

1. IMPLEMENTOR/DISTRIBUTOR/MAINTAINER.
St. Paul, MN 55112 (612/483-0589).

11. LIBRARY SUPPORT. (* no information *)

Mark

D.

Rustad,

585

Harriet

2.

MACHINE. Designed for the HITS Altair 680b, based on a Motorola 6800.

3.

SYSTEM CONFIGURATION. Requires 32K bytes and a TTY. No disk needed.

4.

DISTRIBUTION. (* no information *)

5.

DOCUMENTATION. (* no information *)

Ave.,

Apt #213,

NCR Century 200

Jack Laffe, 320 19th Ave. 5., Minneapolis, MN 55454 (612/336-4946)
(77/08/30) that he is writing a Pascal compiler in Neat 3 for the Century 200.

tells

us
f--'

o
Vl

Norsk Data NORD-l0 (CERN)

Prime P-400

1. IIWLEMENTOR/DISTRIBUTOR/MAINTAINER. David L. Bates and Robert Caillian, PS/CCI Group,
CERN, 1211 Geneva 23, Switzerland. (Tel. 41-98-11)

1. IMPLEMENTOR/DISTRIBUTOR/l~INTAINER. Phillip H Enslow, School
Computer Science, Georgia Tech., Atlanta, GA 30332 (404/894-3187).

2.

MACHINE. Norsk Data NORD-l0.

2.

MACHINE. Prime P-400.

3.

SYSTEM CONFIGURATION.

3.

SYSTEM CONFIGURATION. Virtual memory operating system.

4.

DISTRIBUTION. "Anyone is welcome to receive a copy of our system." (77/1/19)

4.

DISTRIBUTl
G>

I"T1
I-'

o
00

Machine independent parts of the system,
i.e.,
the compiler and part of the
interpreter are in the intermediate language. Only the nucleus of the interpreter is
machine-dependent and therefore handcoded. The input device is a mark-sense card reader
accepting specially coded cards (reserved words have their own punch codes).

TeRAK 8510 (San Diego)

(* See

i~plementation

notes for DEC LSI-ll (San Diego). *)

11. LIBRARY SUPPORT. (* no information *)

Texas Instruments TI-ASC.

rn

Univac 90/30.

::e:::
en

See letter from C.C. Handley under Hewlett Packard HP-21'IX.

Philip Bergstresser (see HERE AND THERE News section) phoned 77/05/26 to correct our
information in PUGN #8. The POL (Production Development Language) system TI implemented
included a superset of Pascal and a library management system. This included software
tools, a check for matching source and binary module interfaces, procedures recompiled
independently with scope, complete reversible overlay process, cross reference and
instrumentation code. Documentation is available from Bill Bixler at TRW Huntsville. The

TI-ASC is a 650K 32 bit word machine with IBM
scalar hardware. It has 48 registers.

360-like

floating

point

and

vector

Univac 90/70.

and
See Siemens 4004, 7000 series.
The U90/70 (formerly RCA
hardware and software (Vli0S

Spectra 70) is very similar to the Siemens machines, both in
BS2000).

~

Texas Instruments 9900/4 (Vienna)
Univac 1100 (San Diego)
1. IMPLEMENTOR/DISTRIBUTOR/MAINTAINER. Implementors: H. Schauer, R. Nagler, and A. Szer,
Institut fuer Informationssysteme, A-l040 Wein, Argentinierstrasse 8, Austria
(Tel.
65 87 31/313). Distributors: ECO-Computer GesmbH&Co Kg (Fa. Langschwert), A-lOla Wein,
Tuchlauben 14, Austria (Tel. 63 35 80).
2.
3.

MACHINE. TI 9900/4.
SYSTEM CONFIGURATION. No operating system; requires a mark-sense

card

reader

and

1. IMPLEMENTOR/DISTRIBUTOR/MAINTAINER. Hichael 5. Ball, Code
Center, San Diego, CA 92152. (* No phone number provided. *)
2.

MACHINE. Univac 1100 series.

3.

SYST~M

4.

DISTRIBUTION.

632,

Naval

Ocean

Systems

-0

--i

rn

CONFIGURATION. Exec-8 operating system; can be run in Demand mode.

a

line printer.

As

a

member of USE, you may request a copy from

~ike

by sending a mag

tape and noting any res.trictions on its format.

4. DISTRIBUTION. The system
Schillings (about $1500 U.S.).

(hardware

and

software)

MAINTENANCE.

"We

intend

sold

to

the

Pascal

Report.

(* Not

bug reports."

7. STANDARD. The following are not supported:
files;
procedures/functions. Sets of 64 characters are supported.
8.

MEASUREMENTS.

It

is

very

with

and

goto;

formal

slow compared with other systems. The system uses 12K Rmi

words and no external memory.

9. RELIABILITY. The reliability of the system is excellent. (* Date
number of sites using system not reported. *)
10. DEVELOPMENT

METHOD.

The

system

is

first

released

written in Pascal and machine code (3000 source

lines). It took 3 months to implement it on any microprocessor with no special

of

and

experience

DOCUMENTATION. A 29 page machine readable supplement to the

represented

the

source

program

into

an

consists of the intermediate code of a PASCAL block in reversed Polish notation. This tree
is the static information of the program. The compilation does not exceed the level of
syntactic decomposition defined by the syntax diagrams in the PASCAL report. The
interpreter performs all context-sensitive checking at execution time.

and

allowed. Sets may have at most 144 elements. The compiler accepts the full ASCII character
set. A compiler optiori allows processing of Brinch Hansen Sequential Pascal programs.

8.

MEASUR&~ENTS.

The

compiler

compiles into 34K words and requires 6K words of library

routines. Self-compilation requires about lS.SK for stack and heap.
Execution times for code compiled by Pascal was com?ared with code generated by the NUALG
and ASCII FORTRAN processors. Fortran's local optimization was taken as a base value. The
programs used for comparison were taken from Hirth's paper on the design of a Pascal

compiler

(Software

- Practice and Experience, Vol. 1 (1971), pages 309-333). The results

are summarized in the following table.
-0

Pascal

intermediate

as a tree, where each node represents one declaration and each leaf

Manual

7. STANDARD. Restrictions: entry, processor, and univ are reserved words; standard
procedures and functions may not be passed as actual parameters; file of file is not

the implementors. The machine independent parts are bootstrapped by an existing Pascal
Basic concepts: the compiler translates

User

MAINTENANCE. (* no information *)

compiler. The system is intended primarily to support programming education.
language

Pascal

Report entitled "Pascal 1100 11 documents the i:nplementation.

6.

to make more of i t [the system] and we would like to accept

3:
tJ:I

rn
;:c

for 200.000. Austrian
5.

5. DOCUMENTATION. Available in the form of a supplement
known if this is machine retrievable. *)
6.

is

en
rn

PART
PARTNP
SORT
MATMUL
COUNT

Pascal
(reI)
0.62
1.18
1.37
1.82
0.30

no tests

(reI)
0.61
1.06
1.12
1.43
0.28

~UALG

NUALG
(reI)
0.85
3.29
1.83
2.05
0.72

no tests

(reI)
0.34
3.17
1.49
1.70
0.66

FORTRAN
(reI)
1.00
0.94
1.00
1.00
1.00

FORTRAN
FORTRAN
local opt. global opt.
(reI)
(reI) (time)
15.10
1.00
0.99
1.00
0.93
0.85
1.00
18.01
0.59
1.00
10.26
0.39
1.00
16.83
0.97

:l>
C)

rn
I--'
Cl
<.D

Univac 1100 (Madison)

9.

RELIABILITY. Quite good; i t should approach excellent. The system has

been

in

local

about February, 1976, and i~ has been installed at 25 sites (11 university, 4
government, 10 industry).
use

since

10. DEVELUPMENT ~lLTIlOIl. The compiler was
develop system not reported. *)

developed

from

Pascal-P2.

(* Person-hours

ACADEMIC COMPUTING CENTER
THE UNIVERSITY OF WISCONSIN - MADISON

to

1210 WEST DAYTON STREET
MADISON, WISCONSIN 53706

608-262-1166

11. LIBRARY
assembler.

SUPPORT.

Generated

code

can be linked to subprograms written in Fortran or

August 31, 1977

Univac 1100 (Copenhagen)

1. I~lPLEHENTOR/DISTRIBUTUR/aAINTAI~ER. J. Steensgaard-Madsen, DIKU (Datalogisk Institut,
(* No phone
Kobenhavns Universitet), Sigurdsgade 41, UK-2200 Copenhagen N., Denmark.

PASCAL Implementations
University Computer Center
227 Experimental Engineering Bldg.
University of Minnesota
Minneapolis, MN 55455

number reported. *)

Dear Mr. Bonham:

2.

MACHINE. Univac 1100 series.

3.

SYSTDI CONFIGURATION. Exec-8 operating system.

Enclosed please find a description of our new diagnostic PASCAL compiler.
The following will outline the development of the compiler (which isn't
specifically dealt with in the description).

4. DISTRIBUTIUN. The charge for distribution from Datalogisk Institut is Dkr. 200. The
distributors are attempting to maintain a distribution tree to reduce costs and hassles.
Purchasers must sign a license agreement. The system is released only in relocatab1e form.
5. DOCUMENTATION. A 19-page machine readable supplement to the Pascal User Hanual and
Report is available. It is "A Pascal Compiler for the Univac 1100 machines II , by J.
Steensgaard-tladsen and Henrik Snog of DIKU.
6. t1AINTE.NANCE. There
the license aggreement.

is

no promise of maintenance, but bug reports are required under

7. STANDARU. Deviations from the standard: Reset(E) on any textfile
will cause
eof(f) = false and eoln(f) = true; Parameter types of formal procedures and functions must
be specified.
Restrictions: file £f file is not allowed; standard procedures cannot be
passed as actual parameters.
Machine dependencies: Sets may have 72 elements, char is
defined as (6-bit) Fieldata, ascii is an additional type; real is double precision always.
8. HEASUREMENTS. Compilation space is roughly 42K; speed is 100 lines per SUP second.
Compiled programs run efficiently compared to other processors.
9. RELIABILITY. Excellent. (* Date first released and number of sites
reported. *)

using

system

may

of five people (myself, Richard
Gary Holmes). It currently
was initiated during the sumreleased to users in late 1976.

The compiler was designed from scratch, using a syntax-directed organization. The compiler uses a table-driven LALR(l) parser and an error corrector which is driven by the parsing tables. Initially the compiler was
bootstrapped through a version of the P-compiler. Later, Mike Ball's
N.D.S.C. compiler was used. At present, of course, we bootstrap through
our own compiler. This has the added benefit of allowing our diagnostic
checks to monitor our own compiler (at a very acceptable level of overhead). Indeed, the preponderance of compiler bugs are found in this manner. As a result, errors are automatically linked to the offending source
statement in the compiler and readily fixed.
In case you are interested, I'm including a copy of our current User's
guide (an updated version is being prepared). rfm also posting a copy
of the compiler description to Andy Mickel for inclusion in the PUG Newsletter (or are you the person who handles that department?)

not

10. DEVELOPMENT METHOD. Pascal-P with a team of 4 persons.
11. LIBRARY SUPPORT. External procedures
Incluslon of assembler code is possible.

The UW-PASCAL compiler is the joint effort
LeBlanc, Masahiro Honda, Steve Zeigler and
represents about 24-30 man months. Design
mer of 1975 and the first test version was

be written in Pascal or (ASCII) Fortran.

If youfd like. further information, please feel free to write me.
Sincerely,

~1LF~
Charles N. Fischer
CNF:rb
enc.

Diagnostic PASCAL Compiler for Univac 1100 Series

environment of their declaration.

This allows complete compile-

time checking of procedure interfaces as well as access to global
The University of Wisconsin-Madison Academic Computing Center (MACC)

variables.

The compiler is especially designed for research and instructional use.

(b)

It emphasizes careful and complete diagnostic checking at both cornpiletime and run-time.

V0

Conditional compilation facilities are provided.

These in-

clude the optional compilation of code sequences enclosed by

Included are subscript and subrange checks, pointer

validity checks, record variant and set range checks.

Linkage to externally defined assembly language pro-

cedures is also provided.

has developed a diagnost'ic PASCAL compiler for the Univac 1100 series.

comment brackets (llconditional comments tl ) .

When run-time er-

Further, code is

not generated for unreachable prugram statements.

rors are discovered a procedure walk back (with source program line numbers)
as well as a symbolic dump of scalar variables are available.

(c)

During com-

The DISPOSE procedure is implemented.

Run-time pointer checks

pilation, a complete analysis of the syntactic and semantic correctness of

ensure that disposed objects cannot subsequently be referenced.

the source program is performed.

Heap objects may be grouped into logical units (termed "sub-

Automatic correction of minor syntax er-

pools") which may be freed in a single DISPOSE operation.

rors (e.g. missing semicolons or parentheses) is included.

This

often significantly simplifies reclamation of heap storage.
The following provides detailed information about the compiler and its

(4)

distribution policy.

UW-PASCAL has been in use since early in 1977.

It has received

rather heavy use and has been found to be very reliable (at present
(1)

The

~T-PASCAL

compiler is an ASCII processor which operates on any

Univac 1100 series computer under EXEC-8a
compiler are available.

no extant bugs are known).

Two versions of the
MACC currently maintains UW-PASCAL as a fully supported software

The first produces standard relocatable

product a

elements which may be collected to produce executable absolute
elements.

The second version operates in a lILoad and GoT! manner.

Both the source and absolute modules of both

versions of the compiler as well as PASCAL support routines will be

PASCAL source programs are compiled directly into core and immediately executed.

The compiler, with a year of compiler support, is available

for a fee of $750.
provided.

No collection step is used.

Prompt distribution of corrections to compiler bugs as

well as improvements to the compiler are also included.
(2)'

m,-PASCAL is written in PASCAL.
sions) is about 14K lines.
min (on an 1110).

Its source (including all ver-

Compilation speed is about 4000 lines/

and extensions) is available for a fee of $600 per year.

A surcharge

The compiler requires about 70K words to operate

('l:vhich is larger than most other Univac compilers).

of $100 will be added for users outside of the United States.

However overall

A m,-PASCAL User Guide (included in machine-readable form with the

compilation costs appear to be comparable to other Univac ASCII
compilers.

After this

initial period, continuing support (including compiler improvements

compiler) which further details this compiler is available for a

Code generated by the compiler is as good as, or better,

than that generated by other ASCII compilers operating in a non-

postage and handling fee of $3 ($5 foreign).

optimizing mode.

is distributed on a 9-track 1600 BPI tape.

Normally, the compiler
However, other tape

formats and densities may be available upon special request.
The Load and Go version is marginally smaller and faster than
the standard compiler.

All inquiries should be directed to:

For small programs, its cost (for compila-

tion and execution) is about 60% of the standard compiler.

(3)

PASCAL Development Group
Attn: Dr. C. N. Fischer
MACC
1210 West Dayton Street
Madison, Wisconsin 53706

UW-PASCAL implements all of the Standard PASCAL language with the
exception of GOTO's out of procedures.

(STOP and ABORT statements

are available as a partial alternative.)

Information may also be obtained by contacting Dr. Charles N. Fischer
at (608) 262-7870.

In addition to the extensive diagnostic capabilities noted above,
a number of other language extensions are available.
(a)

A very powerful external compilation capability.

These include:
Procedures

which are compiled independently are always compiled in the

--0

J>
Gl

rn
(5)

UW-PASCAL is an on-going research project at the University of Wisconsin.
(a)

Future development plans include:

Compiler tuning to reduce core requirement (to about 45K for

small programs) and to reduce overall compilation costs.
(b)

Inclusion of a varying-length string manipulation capability

4. DISTRIBUTION. Distributed on magnetic tape (9 track, 800 bpi, structured much like a
standard Xerox processor distribution tape - labelled in account :SYSGEN). Distribution
cost is $250, payable to Pierre Desjardins. The distribution includes documentation.

(similar to PL/I varying length strings), with catenation and
5. DOCUHENTATION. Program comments are in English. The following
documents
are
distributed:
"Program Description" (English) contains installation and maintenance
information; "Manuel d'utilisation ••• " (French) is the user's manual; "METAPASC ••• tI
(French) provides macro-procedures to aid writing external procedures or functions in
Meta-symbol; "Pascal 2 - Sigma: un systeme de prograrnmation Pascal" (French) describes the
functional structure of the compiler.

substring operations, I/O, etc.
(c)

Addition of an interface to ASCII Fortran subprograms.

6. t1AINTENANCE. Bug reports are welcome, and "update sheets could be sent. fI The
distribution fee does not imply any responsibility or maintenance service on the part of
the distributor, implementor, or the Universite de Montreal.

Varian (Sperry-Univac) V-70

1. IMPLEHENTOR/DISTRIBUTOR/HAINTAINER. I)istributed by the Varian Users Group (VOICE).
Varian
Data
Hachines
(Sperry
Univac), 2722 Michelson Drive, Irvine, CA 92713
(714/833-2400) •
2.

HACHINE. Varian V-70 series.

3. SYSTEH CONFIGURATION. Requires 32K+ memory, memory map, Vortex I I operating
extended instruction set, and 512 words of writable control store (WCS).
4.

A

120

page

manual (non-machine retrievable) is available as part of

HAINTENANCE. (* no information *)

7. STANI)ARD. This is Brinch Hansen style Pascal. 1/0 is non-standard and oriented toward
the Vortex-II 1/0 macros. Reference to files is by unit number. Additional restrictions:
Strings must have an even number of characters. Gota's are not supported. Enumeration
types cannot be defined within record declarations. Records may have at most 16 variants,
and the ordinals of the variant labels (constants) must be in the subrange 0 •• 15. Sets may
have 128"elements. Uses Hark-Release.
8. HEASURE~!ENTS. Compiles over 1000 statements per minute. Compiler requires 17K
words of main memory.
9.

decimal

10. DEVELOPHENT r·IETHOD. Based on Brinch Hansen's Sequential Pascal.
11. LIBRARY SUPPORT. (* no information *)

tIACHD1E. Xerox Sigma 6 and 9.

3.

SYSTEH CONFIGURATION. (* no information *)

11. LIBRARY SUPPORT. The compiler produces a relocatable object module (in Xerox Standard
Object Language) for each procedure and function. Provision is made for external
procedures and functions written in t1eta-symbol.

Xerox Sigma 7.

See also CII 10070.

Another Sigma
project, apparently incomplete and
Bauer, III, Computer Science Department, University
WY 82071 (307/766-5134).

Xerox Sigma 6, 9.

2.

10. DEVELOPHENT HETHOD. The compiler source is 6200 lines of Pascal. It was produced by
cross-compiling from a cl)e Cyber 74. Effort was 18 person-months (without any prior
knowledge of Sigma machines).

The GIl Iris-80 compiler (described above) has been transposed to the the Xerox Sigma 7
running under the BPM monitor by t1asato Iakeichi, formerly at Department of Mathematical
Engineering, University of Tokyo, Bunkyo-ku, Tokyo 113, Japan. Present address: Department
of Computer Science, University of Electro-Coffil:runications, 1-5-1 Chofugaoka, Chofu-shi
Tokyo 182, Japan.

RELIABILITY. Good. Distributed to over 10 sites.

i. I'1PL;:HENTOR/I)ISTRIBUTOR/~IAINTAINER.
Pierre
DeSjardins,
Universite
Informatique, C.P. 6128, '10ntreal 101, Quebec, Canada (514/343-7662).

8. t1EASUREHENTS. Compiler peak code size is 25K. Self-compilation takes 35K. Compilation
rates are: 600 lines per minute (Sigma 6 - BPH/BTH) and 1200 lines per minute (Sigma 9
CP-V). (* Size and execution speed of generated code not reported. *)
9. RELIABILITY. Good to excellent. (* Date first release and number of sites using system
not reported. *)

DISTRIBUTION. Available from Varian as VOICE i1183C8.

5. I)OCUMENTATION.
distribution.
6.

system,

7. STANDARD. Corresponds to Pascal User Manual except: files may not ,be components of
arrays, records or files; string constants may not occur in the ~ section; standard
procedures and functions may not be passed as actual parameters. Sets may have at most 32
elements.

de

Hontreal,

inactive, was headed by Henry
of HyOining, Box 3682, Laramie,

Z110g Z-80.

Ken Bowles and co-workers, UCSD, have adapted the San I)iego DEC LSI-ll implementation to
run on the Z110g Z-80 running (at 2.5 lUtz) about 70% as fast as the LSI-ll. Release is
expected by the end of 1977. See the DEC LSI-11 (San Diego) note, above.

I-'
I-'

N



---

Source Exif Data:

File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.3
Linearized                      : No
XMP Toolkit                     : Adobe XMP Core 4.2.1-c043 52.372728, 2009/01/18-15:56:37
Create Date                     : 2011:06:15 13:08:07-08:00
Modify Date                     : 2011:06:15 13:22:08-07:00
Metadata Date                   : 2011:06:15 13:22:08-07:00
Producer                        : Adobe Acrobat 9.43 Paper Capture Plug-in
Format                          : application/pdf
Document ID                     : uuid:b0b2fca9-c791-4414-8eba-fb2c10872467
Instance ID                     : uuid:956bc5cb-482a-4e22-812f-f8a0131cd866
Page Layout                     : SinglePage
Page Mode                       : UseNone
Page Count                      : 114

EXIF Metadata provided by EXIF.tools