11_Pascal_News_Feb78 11 Pascal News Feb78

11_Pascal_News_Feb78 11_Pascal_News_Feb78

User Manual: 11_Pascal_News_Feb78

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

Download
Open PDF In Browser	View PDF

PASCAL USER'S GROUP

Pascal News
(FORMERLY PASCAL NEWSLETTER)
NU~1BER

11

COMMUNICATIONS ABOUT THE PROGRAMMING LANGUAGE PASCAL BY PASCALERS

FEBRUARY) 1978
TAB LEO F CON TEN T S

o
1
3
4
4
8
10
10
13
16

19

33
·33
34
36
40
41
48
51
54
57
64
70
70
70
70
72
75
80
104
105

COVER: Paper Fasteners from the mail of international
Pascalers
POLICY: Pascal News
AI.L PURPOSE COUPON
EDITOR'S CONTRIBUTION
HERE AND THERE WITH PASCAL
News (Jobs, Help Wanted!, Tidbits from Pascalers)
Pascal in the News
Conferences
Books and Articles
Errata to Pascal User Manual and Report, Second Edition
Review of Pascal Newsletters 5 - 8
Roster Increment
ARTICLES
"Type Compatibility Checking in Pascal Compilers"
Pierre Desjardins
"A Novel Appro,ach to Compiler Design" James Q. Arnold
"Status of UCSD Pascal Project" Kenneth L. Bowles
"Suggestions for Pascal Implementations"
Wi 11 ett Kempton
"Suggested Extensions to Pascal" Robert A. Fraley
"What to do After a While" David W. Barron and
Judy M. Mullins
"Adapting Pascal for the PDP 11/45" David D. Miller
"Pascal: Standards and Extensions" Chris Bishop
OPEN FORUM FOR MEMBERS
Special Topic: Pascal Standards
IMPLEMENTATION NOTES
General Information
Applications
Portable Pascals
Pascal Variants
Feature Impl ementation Notes
Machine Dependent Implementations
Index to Implementation Notes
POLICY: Pascal User's Group

I
1

(C::: J

POLICY:

PASCAL NEWS

(77/12/30)

* 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 lIabout Pascal II 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 IIconcentratorsli (our phones and
mailboxes). We are trying honestly to say: IIwe cannot p1'omise 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.

* 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.

* Pascal News is divided into flexible sections:

~

u

-o
--

11.

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
Rich Stevens - Books and Articles editor
Rich Cichelli - Software Tools and Applications editor
George Richmond - past editor (issues 1 through 4)

PASCAL USER'S GROUP

ALL PURPOSE COUPON

USER'S

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

GROUP

(77/12130 )
Pascal Userls Group, c/o Andy Mickel
University Computer Center: 227 EX
208 SE Union Street
University of Minnesota
Minneapolis, MN 55455 USA

+

Clip, photoQopy,

+

~e~oduQe,

O~

etQ. and

/ / 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 Pa6Qal N0W~
for each year. Enclosed please find
($4.00 for each year). (* When
joining from overseas, check the Pa6Qal N~ POLICY section on the reverse
side for a PUG "regional representative. 1I *)
/ / Please renew my membership in PASCAL USER'S GROUP for ___ Academic year(s)
ending June 30
Enclosed please find
($4.00 for each year).
. (* See the Pa6Qal
/ / Please send a copy of Pa6Qal N0W~ Number(s)
POLICY section on the reverse side for price-s-a-n'd~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.

N0W~

1111 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 Pa6Qal N0W~. (* Please send bug reports
to the maintainer of the appropriate implementation listed in the Pa6Qal N0W~
IMPLEMENTATION NOTES section. *)
/ / None of the above.

Other comments:

From:

name ______________

mailing address ______________

phone _________-:..-_ _ __
computer system(s) ______________
date ______________

>.......

u

-l

o

CL

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 ~oin PUG anytime within an academic year: July 1 to June 30, you will
receive all issues of Pascal i~ews 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 .
THROUGH "REGIONAL REPRESENTATIVES" ?
- To join through PUG(USA) , see address on reverse side. International telephone:
1-612-376-7290. PUG(USA) produces Pascal News and keeps all mailing addresses on
on a common list. Regional representatives collect memberships from their regions
as a service and reprint and distribute Pascal News using mailing labels sent from
PUG(USA). Persons in the Australasian Region must join through PUG(AUS).
European Region (Europe, North Africa,
Australasian (Australia, New Zealand,
Region Indonesia, Malaysia):
Middle and Near. East):
send '£2.50 to: Pascal Users' Group (UK)
send $AI0 to: Pascal Users Group (AUS)
c/o Computer Studies Group
c/o Arthur Sale
Dept. of Information Sci.
Mathematics Department
University of Tasmania
The University
Southampton S09 5NH
GPO Box 252C
Un i ted Ki ngdom
Hobart, Tasmania 7001
telephone: 44-703-559122 x700
Australia
telephone: (002) 23 0561
RENHJING?
- 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 wh~n you renew.

JOIi~ING

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) are out of print.
(A few copies of issue 8 remain at PUG(UK) available for tl each.)
- Extra single copies of new issues (current academic year) 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 individual requests.

l5i1

Postage for 9/lD was

UNIVERSITY OF MINNESOTA
lWlN CITIES

Country

University Computer Center
227 Experimental Engineering Building

U.K.

Minneapolis, Minnesota 55455

(612) 376-7290

Europe

group
3S0g
SOOg

Previous group

Unit Cost

Unit Cost

4Sc

300g

39c

48c

2S0g

26c

The DEADLINE for written contributions to Pascal News #12 is March 20. Please send DARK copy!
New companies committed to Pascal (add to the list in PUGN#9): Ericsson Telephone and ICL in
Europe, Interdata and Tektronix in the US. TI continu~be very mysterious about their
heavy use of Pascal - they haven't told us a word in a year now! DEC may be finally waking up
because of DOD-1 (see Here and There). Thanks to everyone who sent material for this issue.
We sent renewal notices to 315 holdouts in November. We may have to stop sending receipts for
membership - it is getting too time consuming. We will probably have to combine issues 13&14
next autumn.
Judy sent the letter below to "The Editor, Pascal News":

and came to a total of $llS (approx.). The mailing included close on SO
renewals received after you ran the labels off. As you can see, it is
unlikely that any future issue will hit the lower group for European postage,
so that we might have to face 90c + 48c = $1.38 for getting a copy to a
European member. However, with luck we can still do it at under a dollar.

UNIVERSITY OF SOUTHAMPTON

Thank you very much for all the numerous snippets of information over the
past year, and for the most recent one. on South Africa. The personal touch
is sincerely appreciated. You will be glad to know that ~its are seriously
contemplating switching from Fortran to Pascal for first years (including
engineers) in January. It all depends on whether a decent 370 compiler is
ready.

Faculty of Mathematical Studies
Southampton, S095NH. Telex 47661. Tel 0703 559122Ext 238 7

~:.:

That seems to be all. I have today handed over the files in good order to
David who will handle everything after my departure. Following his article
in Computing we have had an influx of queries, especially from Industry.
Pascal lives:

I'll keep in touch, of course, and won't forget to send a photo of the
wedding.

Sth December, 1977.
All the best,

Dear Andy,

~

=

{

:::0

.

PUG (UK) PRINTING and POSTAGE

"7_

,~.-.--/

/'

~

:/"

Now that PUGN 9/10 is out of the way, I thought I would share some statistics
on printing costs.
PUGN
number
S
6
7
8
9/10

USA
pages
64
96
48
64
112

per copy

per page

$0.70
$1.18
$0.69
$1.07

1.09c
1.23c
1.44c
1.67c

per copy

$O.SO
$0.14
$0.40
$0.S6

per page

.S2c
.29c
.62c
.Slc

As you can see, we have managed to keep our costs at well below half yours.
After No.8, we outgrew the Departmental printing service and took 9/10 to
the University Printing Unit. They were able to do the job at the same
price - in fact slightly cheaper because I did much of the collating myself
to hurry it along. However, indications are that there could be a steep
rise in costs in the New Year. It may be possible to avoid it, and in order
to do so we need to know, accurately,
No. of pages in No. 11
Date of arrival of Masters.
However, should it not be possible to get preferencial rates, we shall have
to face a cost of about 90c for a 64 page issue (compared to $1.07 in the
U.S.A. and 40c previously). Are you still relying on our ultra cheap rates
or can PUG afford to pay the going rate?

Editor's Contribution

(

Juay Mullins

UK

-n
rn

Professors: H.B. Griffiths, S.A. Robertson (Pure Mathematics); P.T. Landsberg (Applied Mathematics);
1.W. Craggs (Engineering Mathematics); D,W. Barron (Computer Studies); T,M,F, Smith (Statistics).

(* It might help explain to new PUG members a few related facts. Judy Mullins last year
(76-77) proposed and implemented a reprinting and distribution service of PUGN for PUG members
in Europe. Not only was delivery speeded, but also the rates were kept low. Last March, the
University of Southampton Computer Studies Group headed by Prof. David Barron held their
third annual computing symposium on "Pascal - the Language and Implementation." Both Judy and
David have done PUG many great services. Judy graduated this month and is going home to South
Africa where she will marry her fiance. David (who by the way edits the ever-popular journal:
SOFTWARE - Practice and Ex erience) recently wrote an outstanding article for the 77/10/24
issue of Computing Europe a kin of Computerworld for Europe); please see Here and There.
David continues to man the PUG European region and as a result had to quit as a Books and
Articles editor for PUGN.
Regarding the question marks under "USA" for PUGN 9/10 in Judy's letter, the costs were $1.10
and $0.96. Ken Robinson (see Open Forum) asks for a public explanation of the high ($A10)
cost of PUGN for Australasian members for the new distribution service provided this year by
Arthur S~ Arthur on 77/09/07 sent this information about his estimated costs: $2.80 for
printing per issue (based on the size of #8); postage within Australia = $0.70. Arthur says
that he thinks the cost is "dubiously low" and that $10 might leave his operation "out of
pocket, and to understand the costing, you have to realize that Australia has a high postal
charge, and I also am taking on New Zealand." I think it is unfortunate that Arthur's costs
are so high,because it is not in the cheap spirit of PUG. Until Ken wrote I didn't know the
$A10 price was relatively "high". Remember though that last year we had severe distribution
problems to Australia. I'm grateful to Arthur for volunteering to do the work, and I'm sure
he's watching costs. - Andy *)

to
::0
;t:>

-<
I--'
<.P
'-J

CO

Here and There With Pascal
NEHS
PASCAL JOBS""
People keep calling us at PUG central asking for people to employ who know Pascal. (*If
that isn't evidence of Pascal's viability, I don't know what is!*) ~Iith the interest of
Pascalers in mind we list here as a service contacts who desire people with compiler
experience and knowledge of Pascal:
David Shaw, Structured Systems Corp., Suite 605,2600 El Camino Real, Palo Alto, CA 94306.
(415) 321-8111
Charl es Moore, ADP Network Services, 175 Jackson Pl aza, Ann Arbor, fll 48106.
(313) 769-6800 (also Neil Barta, same address and phone)
Gregory Hopwood, Sperry Univac Mini Computer Division (formerly Varian), 2722 Michelson
Drive, Irvine, CA 92713. (714) 833-2400

HELP WANTED!
Pascal is to make any inroads into serious scientific computing (currently the almost
exclusive preserve of FORTRAN) it must have a decent library of scientific subroutines which means, as far as the U.K. is concerned, that there must be a Pascal version of the
NAG (Numerical Algorithms Group) library. (* ... and as far as the U.S. is concerned, that
there must be a Pascal version of the IMSL (International Mathematics and Statistics
Library) library ... *)
If

It should be possible to make a Pascal NAG library largely machine-independent, with all
machine-dependent features begin coll ected into the "X" routines. Probably the easi est
method of production of the library would be straight transcription of the existing
ALGOL-60 versions, together with the writing of the set of "X" routines for each different
range of machines.
Please send your views on this matter, and offers of help, to:
Professor D. W. Barron,
Computer Studies Group,
Department of Mathematics,
The University,
Southampton, Hants, S09 5NH (United Kingdom)
who is coordinating this project and negotiating with NAG.

TIDBITS
D. B. Anderson, 280 Bella Vista Drive, Hillsborough, CA 94010: "I am particularly
interested in implementations usable on my company's Interdata 7-32." (* 77/12/12 *)
David B. Anderson, Dept. of Math., Lehigh University, Bethlehem, PA 18015: "By the way,
the section in the newsletter called 'Here and There with Pascal' has been very helpful
in stimulating the interest of non-believers." (* 77/12/17 *)
Peter A. Armstrong, Digital Data Systems, 1113 Dexter Ave. N., Seattle, WA 98109: "We
are immediately interested in information on PASCAL compilers for PDP-II processors
running DEC's RSTS/E monitor. However, we are also interested in any mini- and or

microcomputer PASCAL capabilities." (* 77/12/13 *)

-0

»

Paul Barr, Raytheon Co., Equipment Div., Boston Post Road, Wayland, MA 01778: "Am
attempting to use PASCAL for a Signal Processing application (FFT). Am designing
hardware to fit the compiler." (* 77/11/21 *)

V>

"

»

Michael Behar, 428 Windy Hill Rd., Orange, CT 06477: "Do you know if there is a version
of PASCAL for a MICRO-MIND-II computer (manufactured by ECD of Cambridge, MA)?"
(* 77/9/22 *)
Roy E. Bollinger, Dept. 1965, BLD 529, Lockheed, P. O. Box 504, Sunnyvale,
"Are there any plans to have any Pascal seminars?" (* 77/11/8 *)

CA

94088:

Steven L. Brecher, 5221 Marina Pacifica Dr., N. Key 19, Long Beach, CA 90803: "More
generally, I am interested in information on any implementation which can be run
on/adapted to a Digital Equipment LSI-ll based system." (* 77/12/19 *)
A. Charles Buckley, Data/Information Systems, Urban Studies Center, Gardencourt/Alta
Vista Road, Louisville, KY 40205: "We are currently interested in any work being done
to implement Hansen's CONCURRENT PASCAL on a DEC-I0 and/or an IBM 370." (* 77/11/28 *)
David Burnett-Hall, Univ. of York, Heslington, York, YOI 500, England: "In the
discussions on whether array parameters could be dynamic in size, there have been some
suggestions that only numerical analysts handling matrices need these facilities. A
much more important use, to my mind, is to be able to pass strings of varying lengths.
E. g., the DEC-I0 compiler has to have 9 almost identical error routines, to handle
errors of lengths 15, 20, 25, • • • 55 characters: Stupid." (* 77/8/10 *)
Joe Celko, Box II 11023,
around?"(* 77/12/6 *)

Atlanta,

GA

30310:

"Is

there

a

Nova

Pascal

sitting

Grant M. Colvin, Management Shares, 2121 W. Airport Frwy., Suite 660, Irving, TX 75062:
"Do you know of PASCAL implementations for the Hewlett-Packard 3000
series?"
(* 77/12/5 *)
C. R. Corner, 514 S. 9th St., Moorhead, MN 56560: "I have a PDP 11/05 and am interested
in Pascal activity on the 11 and on micro-based systems." (* 77/09/29 *)
Lawrence S. Cram, 64 Bowen Street, Newton, MA 02159: "Although I am not now a user of
PASCAL, I certainly would like to be, and I would like to be on your mailing list. I
program commercial applications on a DECsystem-l0 in COBOL and am fed up with the
limitations inherent in COBOL. I was introduced to PASCAL in Wirth's book, Data
Structures + Algorithms = Programs and have followed up with Hansen's Principles of
Operating Systems and the PASCAL Users' Guide. I currently have a second-hand bootleg
PASCAL compiler and I dabble with it occasionally." (* 77/11/8 *)
Pierre Desjardins, Departement d'informatique, Universite de
Montreal,
Immeuble
principal V-240, Montreal 101 Quebec H3C 3J7, Canada: '~y implementation of the
Concurrent Pascal machine on Sigma 6 is presently being used to implement (using
Concurrent Pascal, of course) the "line access protocol" necessary for communicating
with a packet switching service of Bell Canada called DATAPAC.
"I am currently involved in the organisation and realization of a primitive distributed
microprocessor system. System programs will be written in CP and executed by a CP
machine contained in every MP." (* 77/10/13 *)

Robert I. Demrow, 11 Linda Rd., Andover, MA 01810: "I am interested in finding a copy of
Pascal that will run on my 8080 computer--presently have 32K and am planning an
expansion." (* 77/11/26 *)
John DeRosa, The Boston Systems Office, 400-1 Totten Pond Road, Waltham, MA 02154:
"We're presently beginning development of PASCAL systems ·for micro's as well as
resident compilers with the intent of creating a PASCAL well-suited for writing system
software. Any news from people working in this direction would be appreciated."
(* 77/9/21 *)

"Tl

!'T1

t>oJ

=
=

»

=
-<
f-'
LO

'-I
CO

George B. Diamond, Diamond Aerosol Corp., RD 1/ I, Glen Gardner, NJ 08826: "Any, other
information on PASCAL would be appreciated especially compilers or assemblers for the
Z80 CPU." (* 77/12/14 *)

Thomas Giventer, 1250 Post Road, Scarsdale, NY 10583, "1 am currently working on a
PASCAL compiler for the TMS 9900 and would like to find out what other work is being

Roberio Dias, 134 Colin Ave., Toronto, Ont MSP 2C3, Canada: "I am a humble owner of a
digital~oup Z-80 minicomputer and as such very interested in learning new languages.

Steven B. Hall and Arthur Dartt, 1599 Orchard Grove, Lakewood, OR 44107 (* address for
Hall *): "The installation with which we are professionally affiliated and are students
(Cleveland State University) currently is running VSl on a 370/158..
Any help you
can give us in differentiating between the various PASCALs will be appreciated (as we
do not wish to waste valuable man-hours at vain attempts). We will look forward to

I understand that you are publishing four times a year a paper on Pascal. I would very
much like to subscribe to it but instead of sending US$4 right now, I would like to
know if the price would be the same for a subscriber in Brazil, as I will be moving to
that country in February 78, with my computer." (* 77/11/30 *)
Richard Dievendorff, Dept. 84F, IBM, 620 North Brand Blvd.,
"Although I am having this sent to my business address, this is
venture." (* 77/12/3 *)
Felix

F.

Dreher,

Computer

Glendale, CA 91203:
a personal, hobby

Science, Pittsburg State Univ., Pittsburg, KS 66762: "I am

interested in obtaining information about the possible implementation of

PASCAL

on

a

small IBM 370/125 machine. Do you have any data suggesting that this has been done? Is
there a bootstrap interpreter/compiler available that might be modified for this
system? I f so, from whom can it be obtained?" (* 77/10/13 *)
William E. Drobish, Silicon Systems, 16692 Hale Ave., Irvine, CA 92714: "Additionally, I
would appreciate any information on PASCAL compilers and the availability of one for
the Interdata 7/32." (* 77/11/14 *)
C. E. Duncan, 865 Thornwood Dr., Palo Alto, CA 94303: "I am not at present a
would

like

user,

but

to be one. We have available a number of computing systems, and I would be

particularly interested to obtain a running system for IBM 360/370, Univac 1110, Data
General NOVA and Intel 8080A. Perhaps not altogether at once; these systems happen to
be conveniently available." (* 77/10/24 *)
Randall B. Enger, 28 Briar Patch Lane, Sudbury,

MA

01776:

"I'm

planning

to

try

an

implementation on a small machine, mostly because I'm tired of assembly language, but
also because I've been away from programming languages stuff for too long.
"I like to believe I'm relatively free from 'N. I .H.' disease--'not invented here,' and

done in this area."

hearing from you,
(* 77/12/6 *)

as

several

people

are

anxious

to

implement

and

use

PASCAL."

Michael E. Harris, 309 W. Edwards II 4, Springfield, IL 62704: "Does anyone have a "full"
PASCAL that will work with minor modification on an HP3000 ~r on an IBM 370/MVS system?
Micros? Any computer graphics activity in PASCAL?" (* 77/10/26 *)
Charles

Hedrick,

Computer Science Dept., Rutgers Univ., Hill Center, New Brunswick, NJ

08923: "Implementors should give some thought to implementing machine-independent
representations of data so that data is transportable as well as programs. This
involves the generating of files which are not textfiles. What may be the only way out
is to use ASCII text representations (using blanks as separators where appropriate)."
(* 77/09/20 *)

H. F. Hession, Adv. Record Systems Eng., Gov't. Systems Div., Western Union, 7916
Westpark Drive, McLean, VA 22101: "We are programming Zilog Z-80 microprocessors in
assembly language for communications controller applications, and noted an article in
the December 1977 issue of BYTE magaZine referring to 'your user group on PASCAL.
"None of us has had training in PASCAL, but given the proper documentation, we are
confident we can master it." (* 77/12/5 *)

Charles Hethcoat, 2416 Yorktown II 371, Houston, TX 77056: "I obtained a copy of the
Pascal PCODE assembler-interpreter with a view to study how it works. I suggest that a
worthwhile project would be collect copies of this program as written for a variety of
machines

and

languages,

or

to write them up for those machines not having a version

yet. (This would be especially appealing as a way to implement

Pascal

on

the

8

bit

consequently will eagerly build upon the work of others (borrow from, steal from • • • ).

micros). A project like this would go a long way toward assuring that a common language

Whatever

is widely distributed, and a the same time it would simplify life for those wishing to
tryout language extensions. Also, the PCODE language can be extended to include

will

help me get an implementation going--listings/source on tape/whatever -

I'd be willing to spend a few $
charges • • • )" (* 77/11/10 *)

happily

(especially

if

it

were

to

cover

copying

interruption

handling,

queues

and

other

real-time

techniques for operating system

development, as Brinch-Hansen has done with Concurrent Pascal." (* 77/10/10 *)
Robert B. Finch, 910 N. Lk. Sarnish Dr. II 30, Bellingham, WA 98225, "My interest is
personal/hobbiest computing, and I am currently in the process of implementing Per
Brinch Hansen's Sequential Pascal on an Alpha-Microsystems AM-I00."
Read

T. Fleming, Program in Computer Science, Box F, Brown Univ., Providence, RI 02912:

"Brown has an IBM 360/67 running CP-CMS for interactive work, an IBM 370/138 for batch,
running VS 1. We have on order a Pascal compiler from the Australian Atomic Energy
Commission. When it arrives, we hope to put it up on the batch machine immediately, and

at some later date add it to the interactive (CP/CMS) system.
"Everybody here is looking forward to Pascal; we hope to use it in a course on compile
design next semester, and we're anxious to see how it works in an instructional

environment." (* 77/12/18 *)
Jim Fontana, 3519 W. Warner Ave., Santa Ana, CA 92704: "The implementor/maintainer of
the 2550/Cyber 18 Pascal compiler is Gordon Wood at CDC LaJolla operation. The compiler
is distributed from PSD in Sunnyvale." (* 777TfT2 *)
Sciences Bldg., Purdue Univ., West
Lafayette, IN 47907: "You guys sure are ).ax about sending out renewal notices. Most
periodicals bombard you with notices for months befo,re your subscription expires. With
PUG, you don't get a single notification until 5 months after your subscription
expires." (* 77/12/16 *)

Ed F. Gehringer, Dept. of Computer Science, Math

Here and There With Pascal

microprocessor devices. Our main product, the Eyedentifier, is a microprocessor based
image recognition system that utilizes the retinal image as a means of identification

(as opposed to a finger print).
"Although the Eyedentifier is a simple machine whose software was written in Motorola
6800 assembly language, we anticipate the support products we intend to build for it
will require development with a high level structured language.
Lewis

and

Clark

college

near

here, by Kenneth L. Bowles, UCSD on the PASCAL language. As a result, we are very
interested in implementing it on a 6800."
Philip T. Hodge, Habco,
microprocessor

P.O.

Box

305,

Schererville,

IN

46375:

"As

a

Z-80

rn
t:O
:::0

c:::
J:>o
:::0

-<
I-'
LO
'I
00

Robert B. (Buzz) Hill, Eyedentify, Inc., P.O. Box 2006, Longview, WA 98632: "We are a
new
company i~he business of developing and manufacturing custom dedicated

"Recently, a group from my company attended a talk at

-n

based

user anxiously awaiting the UCSD version of Pascal, it is heartening to

find others who share my opinion of both Basic and Pascal." (* 77/12/6 *)
Ross F. Householder, 1725 Brooks Drive, Arlington, TX 76012: "I am a Pascal user working
at Texas Instruments and would like to see what is going on with Pascal in other parts
of the country." (* 77/09/11 *)
R. Warren Johnson, Dept. of Math. and Compo Sci., St. Cloud State U., St. Cloud, MN
56301: "I am seeing more and more hobbyists in beginning courses who need some
convincing that PASCAL is real." (* 77/09/15 *)

Ernest W. Jones, 59 Billou St., San Rafael, CA 94901: "I am interested in certain
languages for use on 16-bit micro's and have investigated the MID!PS language. Pascal
would no doubt provide more suitable capabilities, but may not be suitable for so small
a machine. I would like to learn more about i t nevertheless." (* 77/12/81 *)

K. P. Lee, Dept. of Computer Science, 102 Nicholson, Louisiana State Univ., Baton Rouge,
LA 70803: "You may be interested to know that we are in the process of getting the
Australian compiler. We will be happy to share with PUG any experience we may have with
it." (* 77/10/6 *)

Hark Jungworth, 13318 Newland St., Garden Grove, CA 92644: "We have recently implemented
Pascal on our CDC 7000 machines at HcDonnell Douglas in Huntington Beach. I am a
complete novice at Pascal usage, but can't wait to BEGIN." (* 77/09/12 *)

Haria Lindsay, Hicrocomputer Library ! Resource Center, 5150 Anton Dr., Room 212,
Hadison, WI 53719: "Thank you so much for sending us your brochures and issues. Your
You

=
rn

sure that when we are asked about computer languages t Pascal is mentioned in a
very favorable light." (* 77/9/21 *)

en

newsletter

is

very

impressive.

It for one t now view Pascal as a favorable language.

Hopefully it will be available for microcomputers through the
Hilan Karspeck, 1149 North Hichigan, Pasadena, CA 91104: "I am dying to get my hands on
a PDP-11 PASCAl implementation. According to the December editorial in Byte Hagazine,
you ran a list of PASCAl implementations in your issue # 8. I would appreciate it if
you could begin my subscription with that issue." (* 77/12/11 *)
Neil T. Keane, Stansaab Elektronik AB, System Development, Veddestavagen 13, Jaarfaalla,

Sweden

S-175

62:

"As

a

manufacturer

like to know the extent to which it has been implemented in the US (apart from the Solo
System), and the status of such implementations." (* 77/11/17 *)
Paul Kelly, Educational Data Systems, 1682 Langley Ave., Irvine, CA 92714: "If you are
aware of any FORTRAN compilers written in PASCAl which are available at a reasonable
cost, I would be quite interested to hear about it." (* 77/10/26 *)
Thomas J. Kelly, Jr., 58-B Headowlake Drive, Downington, PA 19335: "Here at Burroughs I
have been using the UCSD implementation of PASCAl for the B6700. It is fairly reliable,
although a number of problems have been noted. I have been sending bug reports (most
with fixes) directly to UCSD. If anyone is interested in the bugs and/or the fixes,
drop me a line. I'll be glad to send listings (most fixes are less than 1 page).
"You may also be interested in the fact that a colleague and I have brought up the CDC
6000 compiler at Burroughs (although the code generation. has been disabled). This is to
us

to

run

checks

soon.

William Kempton, Language Behavior Research Lab, 2220 Piedmont Ave., University of
California, Berkeley, Berkeley, CA 94720: "As a linguistic anthropologist, I find the
reasons for using Pascal versus other languages fascinating. You find a lot of the same

factors operating that operate in any other multilingual speech community. Clearly the
merit of the language and the utility of the compiler are only two of many factors
affecting language choice, they may not be the most important for most users. The best
strategy for a long large change is to have computation center staff at least very
familiar with Pascal t and to have it taught in
science." (* 77/09/22 *)

the

introductory

course

in

computer

John Kenyon, Technical Staff, International Computing, 4330 East-West Highway, Bethesda,
no . 20014: "We are currently involved in the planning and concept development for the
USAF Foreign Technology Division data processing for FY78-82. One of the primary
subjects of our study will be the use of standard higher-order systems programming
languages within the Department of

Defen~e.

I understand that Pascal has been chosen as

the candidate language for all DOD and I would appreciate

any

information

you

Ron

Hahon,

Video

Link,

201 N. Hain St., P. O. Box 688, Hasontown, PA 15461: "Be very

interested in any compilers for direct use
(* 77/12/06 *)

John

P.

HcGinitie,

P.O.

Box

655,

on

Berkeley,

a

micro,

preferably

Motorola

6800."

CA 94701: "During my education at U.C.

Berkeley, I had the honor of learning Pascal as well as BaSic,
Fortran t Lispt Ct
Snobol t • •
Having experienced many languages Pascal has impressed me the most."
(* 77/12/17 *)

Uichae1 McKenna, Time Share Corp., Box 683, Hanover, NH 03755: "We are currently using
ESI/OMSI Pascal for the PDP 11. We are planning a distributed network using LSI 11's in
stand alone mode and with RT 11; the host computer is an 11/60 under RSTS/E - all will
be programmed in Pascal." (* 77/12/27 *)
James S. Hiller, Intermetrics Inc., 701 Concord Ave., Cambridge, UA

02138:

"Today

my

interest is in finding a solid Pascal compiler for Data General equipment t Novas and/or

Eclipses." (* 77/11/10 *)

John C. Knight, US 125A, NASA Langley Research Center, Hampton, VA 23665: "Any interest
withing PUG in actively pursuing a PASCAL standard with the National Bureau £f
Standards?" (* 77/10/20 *)
U.

of

Mass.,

Amherst,

UA

OlD02:

"We've

been

with over 50 requests for our prettyprinter and losing money distributing it

in the process, too." (* 77/9/15 *)

produce object code for the Intel 8080 microprocessor. (Either II res ident" or "cross"
compilers would be acceptable implementations for my purposes, although a "resident"
implementation would be preferable.)" (* 77/12/4 *)

Herbert E. Morrison, 1257 2nd St., Hanhattan Beach, CA
"I am interested in
implementing PASCAL on my Poly 88 (8080) computer. Is there someone you know of who has
done this in the Los Angeles area?" (* 77/12/7 *)
G. 0' Schenectady , 144 Lancaster St., Albany, NY 12210: "Most pleased that the most
rational language ive seen has found 1087 adherants. Read of you-all in Hicrocomputer
SCCS Interface, ! id like to be one of you.
"Hy own activity is presently restricted to hardware selection, and i doubt my 8K S-100
system-to-be will support too much of Pascal without additions, but even so it will be
good to be in touch with whats happening." (* 77/9/17 *)
David Peercy, BDH Corp., 2600 Yale Blvd. S.E., Albuquerque, UN 87106: "I was previously
with Texas Instruments, where Pascal is beginning to flourish." (* 77/12/15 *)

Stephen Klein, 188 Judy Farm Rd., Carlisle, UA 01741: "Computer programming has been a
hobby of mine for a few years, mostly in FORTAN and BASIC, but now I'm sure there are
better languages around so I'm also looking into APL and LISP (* besides Pascal *) to
get an idea what type of work each language is best suited for." (* 77/12/27 *)

Darrell

Preble t

Computer

OJ

rn
to
:;0

=

Roderick Montgomery, Statistical Associate, Health Products Research, 3520 U.S. Route
22, Somerville, NJ 08876: "I would also appreciate rece1v1ng information on the
availability of back issues for the Newsletter and on PASCAL implementations that

could

send me on this subject."

Henry Ledgard, Compo and Info. Sci.,

::e::

Peter Linhardt, 1890 Arch St. Berkeley, CA 94709: "I'm interested in PASCAl for use on a
personal system. I understand there is a system that will run on my machine (* TDL Z80
system *)." (* 77/12/9 *)

on what constructs were implemented there. We think we have

found a bug in it. I f so, we'll pass along a bug report." (* 77/11/29 *)

inundated

manufacturer

be

of Turn Key Computer Systems we are currently

engaged in the assessment of a suit:able high level programming language to which we can
standardize our in-house programming. Since we are mainly engaged in real time
applications we are particularly interested in Concurrent Pascal. To this end, we would

allow

can

Center t

Georgia

State Univet University Plaza, Atlanta t GA

30303: "Georgia State University would like to implement Pascal on our Univac 70/7 or
barring that, our Interdata 8/32. If you have a working version of Pascal on either of
these machines please contact me at the above address. We would like to obtain a
working source copy of Pascal for either of these machines." (* 77/11/28 *)
Jerry Pournelle, 12051 Laurel Terrace, Studio City, CA 91604: "A consulting engineering
firm is at the moment putting together my Cromemco Z-80, with which I hope to put
together some word-processing and small-business bookkeeping--as well as play about. I
can see some limits to BASIC, and from years ago when I had my only previous experience
with computers I know there are limits to FORTRAN •• •• " (* 77/12/3 *)

:I:>
:;0

-<

Edward K. Ream, 508 Farley Avenue, Apt. 5, Madison, WI 53705: "I
interested in implementations for the 8080 or Z80." (* 77/11/30 *)

am

particularly

Peter Richetta, Computer Science, Slippery Rock State College, Slippery Rock, PA 16057:
"I have been trying to get Brinch Hansen's Concurrent PASCAL compiler. After
distributing

Mark Riordan, User Services, Computer Laboratory, Michigan State University, East
Lansing, MI 48824: "Here at MSU we are developing (in PASCAL, of course) a word
processing system we call Redact. Our CDC 6500 is becoming badly overloaded, so we are
considering moving Redact to an Ontel Op-1 intelligent terminal, based partly on the
availability of a PASCAL compiler or cross-compiler for an 8080 chip. (We have even
considered modifying the venerable CDC 6000 PASCAL compiler to do the trick.) Any input
from other microprocessor PASCALers would be appreciated." (* 77/10/24 *)
P. Roberts, Kern Instruments, 111 Bowman Ave., Port Chester, NY 10573: "We will soon
be accepting delivery of a Nova 3/12 computer with floppy disk and 32K words of memory.
I wonder if your PASCAL Users Group has a compiler/interpreter suitable for this

T.

An

for

one

of

our

Eric Small, 680 Beach St., San Francisco, CA 94109: "Am using ESI Pascal in process
control type application in broadcasting." (* 77/11/30 *)

hundreds of systems he stopped distribution. Dr. Hartmann, who wrote much

of the compiler, gave me a list of sources to try. Can you help? Any suggestions?
"Our computers are NOVA 3 (soft discs) and 370/135 using DOS/VS. Educational use is all
we want." (* 77/10/26 *)

machine?

developments of the language as well as perhaps finding a compiler
machines (NOVA, PDP-11 , or any microprocessor)." (* 77/12/06 *)

interpreter

alone

is

not of interest to me, but a compiler would be of

interest.
"If you have such programs, please inform me of the price, core required,
comparison of compile times with Data General Fortran." (* 77/09/08 *)

and

rough

Jon A. Solworth, 7 W. 14th St., Apt. 15A, New York, NY 10011: "Please send info on
implementations on ~ minicomputer and addresses if possible (especially Interdata)."
(* 77/09/08 *)
Turney C. Steward, 201 Drake St.,
Pascal compiler running on a CDC
to obtain info on versions for
resident or cross-compilers." (*

San Francisco, CA 94112: "I am at present using a
6600 at Berkeley, Cal., but would be most appreciative
microcomputers, especially 8080 or Z80 systems, either
77/12/14 *)

Jim Stewart, 194B Pleasantview Rd., Piscataway, NJ 08854: "I am interested in the
implementation of a subset of PASCAL on a Z-80 based micro-computer system."
(* 77/11/20 *)
Jyrki Tuomi and Matti Karinen, Room 2113, Computing Center, Tampere University of
Technology, Box 527, 3310 Tampere 10, Finland: "When you wrote to us with info about
PUG, you said that there are 4 members in Finland already.
"Well, now we are doubling that, and more. The coupons
money, too.

are

enclosed

and

here's

the

"We have a PDP 11/70 at our disposal and have sent for a couple Pascal implementations.
What comes out of this, we shall see •• •• " (* 77/10/7 *)

Robert Rogers, 18625 Azalea Drive, Derwood, MD 20855:" •• being in Minneapolis, do
you know of any implementations of PASCAL for a Control Data Corp. 3500? I am aware of
the CYBER implementation, but I have a CDC 3500 available for my use." (* 77/12/01 *)
Herb Rubenstein, 1036 6th St., Golden, CO 80401: "I would like any information on Varian
V75 Pascal--even a Pascal to Fortran preprocessor (translator)." (* 77/12/19 *)

Steven

Vere,

Asst.

Prof.,

Dept.

of

Information

Eng., Univ. of Illinois at Chicago

Circle, Box 4348, Chicago, IL 60680: "In the December 1977 issue of Byte Magazine Carl
Helmers mentioned that a PASCAL compiler exists for the Z80 microprocessor. Do you have
any

direct

information on this compiler, or know where information can be obtained? I

would like to know
1.

the core requirements

2.
3.
4.

cost of obtaining the compiler
if it runs on the Z-80 or is a cross-compiler
where and how it can be obtained." (* 77/12/12 *)

Janne Sahady, Systems Programmer, LAMBDA, Div. of Biol. and Med., Brown Univ.,
Providence, RI 02912: "We have recently implemented a Pascal compiler on a V77-600
Univac minicomputer (formerly Varian Data Machines). This compiler is the sequential
version of P. Brinch Hansen's Concurrent Pascal compiler. Our current emphasis is on
upgrading the I/O interface and we hope to be writing major system utilities (a mag
tape utility to start with) in Pascal in the near future.

Wayne Vyrostek, Tektronix, Inc., MS 74-329, P.O. Box 500, Beaverton, OR 97077: "I am a
Technical Instructor on Microprocessor Development aids for Tektronix, Inc. I would

"Herb Rubenstein, currently working at Autotrol, has referred us to your newsletter and
mentioned that you are maintaining a Pascal software library • . • we would definitely

like to enroll our training department in the Pascal users group and receive back
issues that are available. I would also appreciate information you have about training

be interested in contributing to it as we develop useful routines--most likely in the
areas of graphics, signal processing and I/O utilities." (* 77/09/16 *)
Stephen C. Schwarm, duPont Co., 101 Beech St., Wilmington, DE 19898: "Should have Sweden
PDP-11 compiler self-compiling soon." (* 77/12/6 *)
Ted Shapin, 5110 E. Elsinore Ave., Orange, CA 92669: "I have access to an
Stanford's version." (* 77/12/15 *)

IBM

370

and

Thomas E. Shields, Software Resources, 2715 Bissonnet, Suite 212, Houston, TX 77005: "We
have UCSD Pascal compiler for B6700 - currently a 1 x 1 (1 cpu, 1 I/O processor); soon
to become a 2 x 2)." (* 77/11/04 *)
John Sigle, Computing and Information Sciences, Trinity Univ., 715 Stadium Drive, San
Antonio, TX 78284: "We have two Digital Group systems, a Motorola 6800 and a Z-80, and
I am interested in developing PASCAL compilers and/or interpreters for them."
(* 77/12/7 *)
Jon Singer, 1540 W. Rosemont CE, Chicago, IL 60660: "Do you know of anyone around here
who has a micro running PASCAL? I would like to see such a system." (* 77/12/14 *)
Dave Skinner, Communication Mfg. Co., 3300 E. Spring St., P. O. Box 2708, Long Beach, CA
9080~ust finished reading the article 'Is PASCAL the next BASIC?' in the December
issue of BYTE magazine, where they mention the Pascal User's Group. As a former PASCAL
user (on~e Univ. of Colorado CDC 6400's), I am interested in following the

programmers in the use of
development." (* 77/09/06 *)
Donald

PASCAL;

particularly

for

Microprocessor

software

Warren, 130 W. 81st St., Apt. 7, New York, NY 10024: "I heard about the group in

Creativ~uting. I've been programming in Pascal for the past four years,

first

at

the State Univ. of N.Y. at Buffalo, and currently at N.Y. University, and I'm pleased
to see its use has spread enough to merit this organization." (* 77/09/12 *)
Hellmut Weber, Leibniz-Rechenzentrum, Der Bayerischen Akademie der Wissenschaften, Barer
Strasse----zr:-D-8000 Munchen 2, West Germany: "I am collecting from collegues

some

more

user-oriented points of view. (I feel that simple users who want to write production
programs haven't found enough attention in the PASCAL community)." (* 77/09/12 *)
Terry Weymouth, 4702 Beau Bien Lane East, Lisle, IL 60532: "I'm interested in
on micros with PASCAL (or should that be PASCAL with micros?)" (* 77/12/7 *)
Fulton

any

news

Wright, Jr., Yavapai College, 1100 East Sheldon Street, Prescott, Arizona 86301:

"I'm the educational coordinator for Computer Services a

Yavapai

College.

I've

just

read an editorial in BYTE magazine about PASCAL. I know almost nothing about it, but
the editorial makes it sound like the language of my dreams. The editorial suggested
you as a source of further information. What should I and my DEC 10 do next?"
(* 77/12/7 *)

OJ

»

Mark Zimmer, 1110 2750 Dwight Ave., Berkeley, CA 94704: "PASCAL is supported in U.C.
Berkeley (in which I am a student) for the use of teaching data-structures (and now)
compilers courses. I learned it in our style course
CS 40. I am interested in
implementing PASCAL on the DG ECLIPSE machine. The specification is done (PASCAL has
been modified slightly so that ALGOL code from DG can be a subset) and the code is

BYTE, 77/09, p. 174, two letters to the editor, one from PUG member
suggest Pascal as a high-level language for micro-processors.

George

Cohn.

Both

pouring forth for the compiler. Since PASCAL is a 'oue-pass language,' some readers may

BYTE, 77/10, "C: A Language for Microprocessors?" J. Gregory Madden. Mentions Pascal as
--;;;;- reasonable candidate" for a high level,
machine-independent
language
for
microprocessors, but goes on to tout Bell Labs' language C as the candidate of choice.

be interested in my three-pass approach with special emphasis on the reversability of
the parse-tree into 'source' form." (* 77/09/23 *)

BYTE,

77/11,

"Language

Development. A Proposal," Glen A. Taylor. Mentions Pascal as a

"good structured programming language," but rejects any "large" language lias
choice for a standard home computing language."

***

the

best

BYTE,

77/11, Two letters to the editor suggesting that Pascal be considered as a
language for progrrams and as an execellent high-level language
for
microcomputers. The writers are PUG members Stephen Alpert and David Mundie.

~ndard

Dear Editor.,

Just so this newsletter isn't quite so serious, can I draw your

BYTE,

attention to the evolution of the pug dog that is the heraldic emblem of the
Pascal Users Group? The York Herald of Arms, in visiting Tasmania recently, was
at pains to emphasize that artists Were free to re-interpret heraldic emblems
and that this was a medieval norm.

77/12,

"Is

Pascal the

t'/~t

B ASIC?", editorial by Carl Helmers. "We at BYTE are

interested in giving Pascal a boost," best sums up the author's attitude. The editorial

demolishes, point-by-point, several arguments frequently made in favor of BASIC, and
argues the superiority of Pascal in several areas. Well worth reading, if you are
interested in personal computers.

He said it was regrettable that in this

machine age a sad uniformity had crept in.

Computer Weekly, 77/10/20, "ICL Pascal users expect boost." Report of

As you can see from the samples

group

reproduced here, Pascallers are free from this mechanistic taint, and the

for

exchange

of

software

among

a

Pascal

users'

ICL users: organizer, David Joslin, Univ. of

Sussex, Brighton, England. Pascal users in Britain are dickering with the Numerical
Algorithms Group, which produces scientific routines in other languages, to get a
scientific library translated into Pascal. See David Barron's Help Wanted ad in another

guardian of rational programming has changed significantly over the months,
eVen at one stage being rather pig-like (possibly an unintended pun).

part of "Here and There" for details.

Computer Weekly, 77/10/20, "More support for Pascal.'~ Reports that "the Swedish defence
procurement agency, EMV, has specified a Pascal-based language as its standard for real
time sof tware development."

~
~r

Computing, 77/10/20.
Computer Weekly.

....

"Two

rn
to
::::t:J

pleas

to

Pascal users." Similar to the first article from

=
:x>
:;:0

-<
Computerworld, 77/11/14, '"'Sounds of Computing' a Record for History," Miles
tongue-in-cheek

Benson.

A

description of a new record entitled "Sounds of Computing," the second

movement of which is called "Pascal Time-Sharing Terminal."
1376, U.S.A.

Computing Europe, 77/10/24, pp. 18-19, "Letting the dinosaur know that it's dead," David
Barron. An argument for burying FORTRAN, however great its effect on computing might

1977, Australia

1977, Europe

once have been. Barron argues the need for using compact, conceptually clear languages
that make writing correct programs and specifying data structures easy. Pascal is the

language of choice.
Creative Computing, Sept/Oct 1977, p. ll. "A Plug for Pascal" letter to the eidtor from
PUG member David Mundie. He counters an argument for creating a structured COBOL/BASIC
by showing how clearly a main program can be in Pascal. His example program (5 lines

PASCAL IN THE NEWS

long) is a Pascal version of the one used in the article he criticizes.

(* This

new section will list articles which take note of Pascal, sometimes just in
passing. Most of the entries here don't really belong in a bibliographical section like
"Books and Articles," but they do give some indication of the currency of Pascal. The
references have now become so frequent that they merit being set off in a separate
section of "News. II Several PUG members have mentioned that "Here and There" is visible
proof of interest in Pascal. We hope that this section is useful in the same way.

The three most important articles listed here are Carl Helmers' editorial
David

Barron's

article

in

Computing

Europe,

and

in

Byte

and

the press release (with editorial

comment by Andy) from the US Dept. of Defense. PUG member David Mundie is doing heroic
work, writing letters to the editor in praise (and defense) of Pascal. Three of his
letters are listed here, as are one each by PUG members George Cohn and Stephen Alpert.
More PUG members should do the same. In addition, we'd appreciate copies of references
made to Pascal in publications you read so that we can make this list more complete. *)

Dataline, 77/10/31, "Blazing the trail for Pascal." More reports from the UK
ICL

about

the

user's group, the Swedish defense language contract, and David Barron's commission

to write a Pascal compiler for the ICL 2900 series.
First Computer Faire Proceedings, pp. 245-247, "Computer Languages: the Key to Processor
Power," by Tom Pittman. Discusses the virtues of various high level languages for
personal

computers.

Mentions

Sequential Pascal, and says that Pascal is in many ways

better than FORTRAN or BASIC.
Kilobaud, October 1977, p. 11. Another letter to the editor by PUG member David Mundie.
He says that Pascal is a better language than a structured BASIC discussed in an
earlier article, and gives a sample main program in Pascal which duplicates the program
suggested by the author of the earlier article.

00

MACC Computing News (University

of

Wisconsin

Academic

Computing

Center),

77/11/28.

Mentions plans to distribute a Pascal compiler under a license agreement. Reference
comes in an article about proprietary software.

SCCS Microcomputer Interface, Aug. 1977, p. 52. An announcement about the
PUG and Pascal News.

existance

of

Standford Campus Computing Bulletin, Nov. 1977, p. 24. A user wrote in to ask that
Stanford acquire a good Pascal compiler. The editor's response was that Stanford is
looking into what compiler to acquire.
Twin Cities Technical Hobbyist, (77:9), pp. 01111-10000, "Pascal in Micros," Geoff
Wattles. An article describing Pascal, with a discussion of the syntax of the language
and Pascal's usefulness for hobbyists.

***

Whi Ie different approaches were offered, al I four winning contractors
proposed to start from the computer language PASCAL as a base. They
... i II provide modifications to construct a resulting language to
sati sfy mi I i tary needs as expressed in the "DoD Requirenlents for High
Order Computer Programm i ng Languages (Rev i sed I RONMAN, Ju I y 19771".

The U. S. Department of Defense High Order Language Effort (or "IRONMAN" or "DOD-1")

(* In PUGN8, May, 1977, on page 3, we passed along the summary of a press release by the
U. S. Department of Defense which was distributed by the
March 3, 1977.

British

Computer

Society

on

William A. Whitaker, Lt. Col. USAF, Defense Advanced Research Projects Agency
(DARPA) described in the full version of that press release a three year effort by the
U.S. Defense Department (DoD) to develop specifications for a real-time language called
DOD1--a single common military computer programming language for "embedded systems,"
computer systems on board tanks and ships, on rifles, etc.).

The language would replace FORTRAN, COBOL, JOVIAL, and all the others. A working
group at DARPA was formed in January, 1975. A rigorous language definition was sought,
but as it turned out", 4 different stages of development/evolution have 'transpired: first

STRAWMAN, a set of relatively complete, although tentative requirments. WOODENMAN and
TINMAN followed. With each step, the proposals were widely distributed for comment.
Existing languages were evaluated, and, as we reported in PUGN8, only Pascal, Algol-68,
and PL/1 survived.
At the IRONMAN (4th step), specifications gave way to a language definition. In
July, 1977, IRONMAN was released to vendors for competitive bidding. The report below,
sent to us by William Whitaker, tells the results. The four successful contractors

be narrowed to two in February,
defense-related software per year.

1978.

What

The Defense Supply Service Washington has announced the a~ard of four
contracts to produce competitive prototypes of a common high order
computer programming language for Department of Defense embedded
computer systems. These a~ards came as a result of a request for
proposa I and offers rece i ved from fourteen firms, both U. S. and
fore I gn. The successfu I contractors ~ere Honey~e II (CI t -Honey~e II
Sui I), Intermetrics, Softech, and SRI-International.

is

at

stake

will

is $3 billion spent on

It is truly amazing how a giant operation .such as the HOLWG (Higher Order Language
Working Group) came up with 95% Pascal almost independently in three years working with
committees.

There has been sporadic news coverage of these events
journals.
One, in October 1977 Datamation, reported on

in the computer trade
how a French software

organization's bid got lost in the mail in the original competition. In the December,
1977, SIGPLAN Notices, it is amusing to see the confusion resulting from their just
having learned about IRONMAN and still not realizing that it's going to be based on
Pascal.
- Andy Mickel
*)

The contracts provide for three phases at the discretion of the
government. The first phase is to be six-months and will produce a
preliminary language design.
At the end of the first phase, an
evaluation of the products will result in some of the contractors
be i ng cant i nued through fu II forma I des i gn, rigorous def i nit i on, and
prototype imp I ementat i on.
The one contractor ~hose language is
selected by the government wil I be continued for refinement and
initial maintenance. The language will be ready for initial use in
1979.
This language design is the next step in a Department of Defense
effort to reduce software costs of enlbedded computer systems. Earl ier
act ions inc I uded i ssu i ng 000 0 i rect i ve 501m.29, "Management
of
Computer Resources in Major Defense Systems, which, as one of several
II

~anagement

actions, required the uses of approved high order languages
in futUre Defense systems software. 000 Instruction 5B0B.31, "Interim

List of 000 Approved High Order Programming Languages,"
prol iteration by approving only seven existing languages.

stopped

The technical effort in high order languages has, over the last three
years, brought increasingly refined sets of .requirements, produced an
evaluation of existing languages, and has established the technical
feasibi I i ty
of a single language for these appl ications.
The
successful design of such a language wi I I be followed by testing and
evaluation, compiler and tool generation, and the necessary long- term
language control. This program is presently being directed by the 000
High Order Language Working Group, chaired by Lt Col Wi Iliam A.
Whitaker, Defense Advanced Research Projects Agency, 1400 Wilson
Blvd., Arlington, Va., 22209.

"Tl

fT1
t>::I
;:;0

c::
::>
;:;0

-<
I-'

to
'J
00

BOO KSAN DAR TIC LES
CONFERENCES
APPLICATIONS
German ACM meeting on. Pascal, held 77/10/14-15 in Kaiserslautern.
S.

(* We received a postcard from Hans Wipperman, Albrecht Beidl, Manfred Sommer,
Helmut Schauer, Lutz Christoph, and Thomas Wagner, all of whom attended the conference.
We haven't as yet received a report on the proceedings; therefore we are printing a list
of the papers presented so that you can write for more information if you like. The
address for inquiries is Hans-Wilm Wipperman, Informatik, F13, Univ. of Kaiserslautern,
Pfaffenbergstr. 95, Kaiserslautern D-6750, Germany. The German titles are from the
program; the English ones PUGN's attempt at translation. *)
H. Burkhart (ETH Zuerich), "Ein interaktives System zur Programmierung in PASCAL."
(* "An interactive System for Programming in PASCAL." *)
H. Balzert (Univ. Kaiserslautern), "PASCAL aus didaktisch-methodischer Sicht." (*
"PasCiif"fi=Om the pOint of view of teaching methods." *)
Brunnstein (Univ. Hamburg): "Erste Erfahrungen mit dem Einsatz von PASCAL-E im
Schulversuch. 1I

(* "First

experiences

on

the

introduction

project." *)
H. J. Hoffman (TH Darmstadt): "Uberlegungen zu PASCAL und
(* "Overview of Pascal and Pascal implementations."

of PASCAL-E into a school

zur

PASCAL-Implementierung."

*)

M. Sommer (Siemens Muenchen), "Das PASCAL-BS 2000 Programmiersystem." (* "The Pascal-BS
2000 Programming System." *)
R. T. Kolsch
(Univ.
Kiel),
"Laufzeitbeschleunigung
durch
den
Einsatz
von
Mikroprogramnien." (* "Run-time system through a microprogram." *)

H.

D. Petersen (Univ. Stuttgart), "Uber die Implementierung von PASCAL auf der TR 440."

(* "Implementing Pascal on the TR 440."

H.

~

Verhaltens

*)

(Kernforschungszentrum Karlsruhe), "Hilfsmittel zur
von

PASCAL-Programmen."

(* Aids

to

Weller

(Philips,

Eiserfeld):

des

dynamischen

analysis of the dynamic constructs of

PASCAL programs. *)
G. Peresch and G. Winterstein, "Testdatengenerierung
dat~ation for Pascal programs." *)
Th.

Analyse

fuer

"Concurrent

PASCAL-Programme."

PASCAL

als

(* "Test

Entwurfs-

Implementierungssprache fuer ein kommerziel1es Betriebssystem." (* Concurrent
project and implementation language for a commercial operating system. II *)

und
Pascal

Spiess (Univ. Braunschweig): "Die Implementierung von PASCAL fuer die PRIME 300."
(* "Implementing Pascal on the PRIME 300." *)
W. Metzger (Univ. Karlsruhe), "Entwurf eines dialogorienteirten Programmiersystems fuer
Kleinrechner auf der Basis der Programmiersprache PASCAL." (* A dialogue-oriented
programming system for a mini-computer based on the programming language PASCAL." *)
W. Remmele (Siemens Muenchen), "Ein portables PASCAL-System fur Mikro-rechner {PPS)."
{* "A portable PASCAL system for micro-computers (PP's)." *)
ACM '77, Seattle, held 77/10/27.
(* report from Richard J. Cichelli, loosely transcribed from a phone conversation: *)
"Basically, ACM '77 screwed up the schedule so that the computer chess
tournament and SIGFISH conflicted with the PUG meeting and confused everyone.
Fifteen people came to the Pascal gathering.
"Some

people

quoted

Matwin, M. Missala, "A Simple, Machine Independent Tool for Obtaining Rough Measures

of Pascal Programs," SIGPLAN Notices (11:8), August, 1976, pp. 42-45.

"Description of a Pascal prog~ augment Pascal programs with code to gather
execution time information by procedure entry and exit." (* A listing of the programs

will appear as a software tool in PUGN 12. *)
James L. Peterson, "On the Formatting of Pascal Programs," SIGPLAN Notices (12:12),
December, 1977, pp. 83-86.
"One aspect of programming style which affects the usefulness of programs is their
readability. A program is readable if a programmer can pick up the program and read and
understand it. Many aspects of style affect readability, including variable names,
commenting, modularity, and formatting. It is this last aspect of readability that we
discuss here." (* from the abstract *)

P. Roy, "Linear Flowchart Generator for a
November, 1976, pp. 58-64.
"This article refers to a paper by Nassi
introduced a type of flowchart specially
defined a similar flowchart language for
program

which,

given

a

program

Structured Language," SIGPLAN Notices (11:11),
and Shneiderman published in this review. They
designed for structured programming. We have
the Pascal programming language and designed a

written

in

Pascal,

generates

the

corresponding

flowchart. The article presents a description of the output produced by this
generator." (* from the abstract *)

flowchart

Joachim W. Schmidt, "Some High Level Language Constructs for Data of Type Relation," ACM

Transactions on Database Systems (2:3), September, 1977, pp. 247-261.
"For the extension of high level languages by data types of mode relation, three
language constructs are proposed and discussed: a repetition statement controlled by
relations, predicates as a generalization of Boolean expressions, and a constructor for

relations using predicates. The language constructs are developed step by step starting
with a set of elementary operations on relations. They are designed to fit into Pascal
without introducing too many additional concepts. 1I (* from the abstract *)

D. A. Thomas, B. Phaguvek, R. J. Buhr, "Validation Algorithms for Pointer Values in DBTG
(Data Base Task Group)

Data

Bases,"

ACM

Transactions

on

Database

Systems

(2:4),

December, 1977, pp. 352-369.
"This paper develops algorithms for verifying pointer values in DBTG (Data Base Task
Group) type databases. To validate pointer implemented access paths and set structures,

two algorithms are developed. The first procedure exploits the 'typed pointer'

concept

employed in modern programming languages to diagnose abnormalities in directories and
set instances. The second algorithm completes pointer validation by examining set
instances to ensure that each DBTG set has a unique owner. Sequential processing is

used by both algorithms, allowing a straightforward implementation which is efficient
in both time and space. As presented, the algorithms are independent of implementation
schema and physical structure." (* from the abstract *)

a "Pascal's I/O is no good" rumor. The confusion was in

thinking that textfiles were Pascal's only form of I/O.
"I emphasized that there should be no attempt to add things to Pascal to make
things compatible with COBOL/FORTRAN; Pascal's I/O is fine: textfiles are for

IMPLEMENTATIONS

people, not for programs."

D. Bates, R. Cailliau, "Experience with Pascal

(* Ken Bowles is planning a summer workshop about Pascal. See the

his letter with details. *)

letters

section

for

Notices (12:11), November, 1977, pp. 10-22.
"This paper relates the history of an

Compilers

on

Mini-Computers,"

SIGPLAN

-c

implementation of the language Pascal on a

:J:>

mini-computer. The unnecessary difficulties encountered on the way led the authors to
reflect on the distribution of "portable" compilers in general and suggest some

Gl

guidelines for the future. Their experiences described within show that it should be
possible to implement a P4 Pascal" System on any 16-bit mini-computer in less than two
man months, given an implementor already familiar with the target machine." (* From the
abstract *)

rn

R. D. Tennent, "A Denotational Definition of the Programming Language PASCAL," Technical
Report 77-47, Department of Computing and Information SCience, Queen's University,
Kingston, Ontario, Canada, July 1977.
"This report presents a formal definition of the semantics of the programming language

LANGUAGES

PASCAL,

(* This section
miscellaneous

sub-divided

articles

for

this

issue.

The

first

section

is

a

set

of

in alphabetical order by author. The second is a semi-complete

list of articles on the subject of dynamic arrays in Pascal. The
bibliography on Concurrent Pascal, supplied by Rich Stevens. *)
R.

third

is

a

static

aspects such as scope and type checking, using the concepts

Conradi, "Further Critical Comments on Pascal, Particularly as a Systems Programming

There has recyntly been some controversy between Habermann and Lecarme and Desjardins
on Pascal in' "Acta Informatica." This paper contains some more comments on Pascal from
a systems programmer's point of view. Some undefined points are first treated. Then
Pascal's datatypes are critically reviewed. A few remarks on common Pascal constructs

are also given. Since the author has experience with
comparisons

between

Pascal

and

MARY

will

the
be

programming
made."

language

(* from

the

Not?"

SIGPLAN

proof

rules,

MARY,

M. Yasumura, "Evolution of Loop Statements," SIGPLAN Notices (12 :9), September, 1977,
pp. 124-129.
"This paper is motivated by two papers. One is written by Ledgard and Marcotty and the
other by Ishihata and Hikita. The former paper is a good summary of control structures
but its conclusions are seriously questioned. The latter paper is the report of a new
Pascal computer in which Zahn's "event" construct is implemented. That construct is,
however, shown to be unsuitable to Pascal." (* From the abstract *)

(* A chronological exchange on dynamic arrays in Pascal *)

author's

abstract *)
R. Edwards, "Is Pascal a Logical Subset of ALGOL 68 or
June, 1977, pp. 184-91.

as a standard from which to derive complete informal descriptions, valid
and correct implementations." (* From the abstract *)

short

Language," SIGPLAN Notices (11:10, November, 1976, pp. 8-25.

some

including

and notation of denotational semantics. It is suggested that the definition can be used
is

Notices

(12:6),

"It is often believed that Pascal is

ALGOL 68 in miniature

B. J. MacLennan, "A Note on Dynamic Arrays in Pascal," SIGPLAN Notices (10:9),
September, 1975, pp. 39-40.
"Pascal is frequently criticized for its lack of any variety of dynamic array facility.
This lack is particularly unfortunate for systems programs which must manipulate
activation records and segments whose sizes are not known at compile time." (* From the
abstract. *)

well structured

it will be argued that both beliefs are badly founded." (* from the abstract *)
J. Holden and I. C. Wand, "Experience with the Programming Language MODULA," a paper
presented to the 1977 IFAC/IFIP Real Time Programming Workshop held at Eindhoven,
Netherlands, 77/06/20-22.
"This paper describes a compiler for MODULA, written in the programming language BCPL,
which runs on a PDP-11/40 computer under the RSX-11D operating system. The code
produced by the compiler is run on PDP-11s under a very small executive (less than 150
words). The quality of the code produced compares well with that of compilers for other
high-level languages.
The use of the language is illustrated by the construction of a real-time scheduler
similar to that written by Brinch Hansen in CONCURRENT PASCAL. A brief discussion is
given of experience gained in the use of the language and comments made about
inclusion and exclusion of certain language features." (* From the abstract *)

the

W. H. Kaubisch, R. H. Perrott, and C. A. R. Hoare, "Quasiparallel programming,"
Software: Practice and Experience (6), 1976, 341-356.
"This paper describes SIMONE, and extension of PASCAL, which provides the quasiparallel
programming facility of SIMULA 67, but without classes or references. The language is
intended to be suitable for the design, testing and simulation of operating system
algorithms. It is illustrated by simple examples, suitable as project material in a

N. Wirth, "Comment on A Note on Dynamic Arrays in Pascal," SIGPLAN Notices (11:1),
January, 1976, pp. 37-38.
"A reply to B. J. MacLennan and a suggested alternative." (* From the abstract. *)
J. Steensgaard-Madsen, "More on Dynamic Arrays in Pascal," SIGPLAN Notices (11:5), May,
1976, pp. 63-64.
"A further proposal in reply to Wirth's article." (* From the abstract. *)
C. Jacobi, "Dynamic Array Parameters,tI Pascal User's

Group

Newletter

(5),

September,

1976, pp. 23-25.
"A

proposed

description

of dynamic array parameters is given in the form of a set of

amendmimts to the book, Pascal User Uanual and Report by Jensen and Wirth with syntax
diagrams and examples. The extension was implemented successfully in the Pascal-6000
compiler." (* From the abstract. *)
S.Pokrovsky, "Formal Types and Their Application to Dynamic Arrays in Pascal,"
Notices (11:10), October 1976, pp. 36-42.
"The

formal

~

SIGPLAN

concept is presented as a means to uniformly introduce in the Pascal

language the dynamic array facility (which may be done as a pure extension) and
procedure

formal

specifications (which would require some changes in the standard language)."

(* From the abstract. *)

course on operating systems." (* from the abstract *)

E. N. Kittlitz, "Block Statements and Synonyms for Pascal," SIGPLAN Notices (11:10),
October, 1976, pp. 32-35.
"PYXIS is a language which is the result of (still continuing) modifications to Wirth's
PASCAL 1 system. Many of the language concepts are identical to, or slightly evolved
from PASCAL 1, others are incompatible with Pascal and its apparent design philosophy.
Two new features have been

implemented

in

PYXIS:

block

statements

and

synonyms."

(* From the abstract *)
O. Lecarme, "Is ALGOL 68 a Logical Subset of Pascal or Not?" SIGPLAN Notices (12:12),
December, 1977, pp. 33-35.
"A paper by Roy Edwards uses a comparison of ALGOL 68 and Pascal to make some
disputable assertions. The purpose of the present note is simply to correct the most
serious errors. It follows exactly the structure of Edwards' paper." (* from the
abstract *)

Edward N. Kittlitz, "Another Proposal for Variable
Notices (12:1), January, 1977, pp. 82-86.
"The

syntax,

semantics,

and

some

Size

Arrays

in

Pascal,"

SIGPLAN

implementation details for a flexible array bound

capability in Pascal are discussed. The constructs described are currently implemented
as part of the PYXIS system at the University of Calgary. PYXIS is the result of more
than two years of modifying [ the old Pascal-6000 compiler written by Urs Ammann et.
al.]." (* From the introduction. *)
M. Condict, "The Pascal Dynamic Array Controversy and a Method for Enforcing Global
Assertions," SIGPLAN Notices (12:11), November, 1977, pp. 23-27.
"In a previous article, Wirth commented that allowing

expressions

(rather

than

constants)
as
sub range bounds would produce dynamic array capability
significantly complicating the language. • • • This discussion leads directly
method

for

obtaining

automatic

just

without
into a

enforcement of assertions about variables throughout

their lifetime." (* From the abs tract. *)

--n

rn
t:>:l

=
=

):>

=
-<

Concurrent Pascal Literature:

September 1977

Brinch Hansen, Per., The Programming Language Concurrent Pascal.
on Software Engineering 1, 2 (June 1975), 199.207.

IEEE Trans.

Introduces Concurrent Pascal - an abstract language for concurrent programming.
It extends the sequential programming language Pascal with modules called
processes, monitors, and classes. The language is illustrated by a hierarchical
design of a simple spooling system. The main contribution of Concurrent Pascal
is to extend the monitor concept with an explicit hierarchy of access rights to
shared data structures that can be stated in the program text and checked by a
compiler.
Brinch Hansen, Per., The Solo Operating System.
Experience 6, 2 (April-June 1976), 141-205.

successfully on a PDP 11/45 computer. The book includes the complete text
of these ?rograms and explains how they are structured, programmed, tested,
and descr1bed. It also inclu~es the Concurrent Pascal Report and a description
of the Co~current Pascal Mach1ne. The book suggests promising areas of further
research 1n structured concurrent programming.

Software· Practice

&

Describes the single-user operating system Solo written in Concurrent Pascal.
It supports the development of sequential and concurrent Pascal programs for
the PDP 11/45 computer. Input/output are handled by concurrent processes.
Pascal programs can call one another recursively and pass arbitrary parameters among themselves. This makes it possible to use Pascal as a job
control language. Solo is the first major example of a hierarchical
concurrent program implemented in terms of abstract data types (classes,
monitors, and processes). The paper contains the complete text of the
concurrent program. It is a sequence of nearly independent components
of less than one page of text each.
Brinch Hansen, Per., Experience with Modular Concurrent Programming,
IEEE Trans. on Software Engineering 3, 2 (March 1977), 156.159.

Brinch Hansen, P., Network: A Multiprocessor Program. IEEE Computer Software
Conference, Chicago, Illinois, Nov. 1977.

&Applications

Hartmann, A.C., A Concurrent Pascal Compiler for Minicomputers.
in Computer Science 50, Springer-Verlag, New York, NY, 1977.

Lecture Notes

Describes a seven-pass compiler for Concurrent Pascal. The compiler, written
in sequential Pascal, generates virtual code that can be interpreted on any
l6-bit minicomputer. The function of each pass is described and the intermediate
languages are defined by syntax graphs. Of particular interest is the checking
of access rights to data structures within classes, monitors, and processes.
This is.done exclusively during compilation and is not supported by hardware
protection mechanisms. The compiler has been running on a PDP 11/45 computer
since January 1975.

Brinch Hansen, P .• The Architecture of Concurrent Programs.
Englewood Cliffs, New Jersey, July 1977.

Prentice-Hall,

Presents a method for developing reliable concurrent programs using Concurrent
Pascal. The use of this language is illustrated by three model operating
systems for minicomputers; a single-user operating system, a job-stream
system, and a real-time scheduler. All of them have been running

rn
C/)

TEXTBOOKS
Tony Addyman and 1. R. Wilson,
March-April 1978, 140 pages.
A

short

and

A Practical

Introduction

to

Pascal,

Macl1illan,

concise introduction to Pascal.

S. Alagic and M. A. Aebib, ~ Design ~
Well-structured and ~ Programs, New York: Springer-Verlag, to appear in 1978, 260
pp., $12.80. An undergraduate text. "Using the Pascal language, both the techniques of
top-down

Summarizes the first 2 years of experience with Concurrent Pascal in the design
of three model operating systems. A Concurrent Pascal program consists of
modules (processes, monitors, and classes). The compiler checks that the
data structures of each module are accessed only by the operations defined
in the module. The creative aspect of program construction is the initial
selection of modules and the connection of them into hierarchical structures.
By comparison the detailed implementation of each module is straightforward.
The most important result is that it is possible to build a concurrent program
of one thousand lines out of one-page modules that can be comprehended at a
glance.

:2

Explores the problems of implementing arbitrary forms of process communication
on a mult~pr07essor network. It develops a Concurrent Pascal program that
enables d1str1buted processes to communicate on virtual channels. The
channels cannot deadlock and will deliver all messages within a finite
time. Th7 operation, str~cture, text, and performance of this program
are descr1bed. It was wr1tten, tested and described in 2 weeks and worked
immediately. The program has been running on two PDP 11/45 computers connected
by bus links.

program

design

and

verification of program correctness are presented. Many

examples of program and proof development as well as an explanation of control and data
structures are provided. As a Pascal programming text,
it gives not only advanced
algorithms, which operate on advanced data structures, but also the full axiomatic
definition of Pascal.
"Although an introductory course in programming is presupposed,
no
particular
mathematical background is necessary'. An extensive, carefully chosen sample of
algorighms, including some examples from business data processing, is presented.
Supplementing
this collection is an extensive set of exercises." (* From the

-n

rn
Co

=
=

:>

=
-<

publisher's ad *)

Kenneth L. Bowles, Microcomputer

Problems Solving Using Pascal (* Please note the
title;
it's the first time we've had it right *), New York: Springer-Verlag,
563 p~., $9.80.
Th1s text 1ntroduces problem solving and structured programming using the PASCAL. (sic)

correct

~97?,

language, extended with
built-in
functions
for
graphics.
DeSigned
for
a
one-quarter/semester curriculum at the sophomore/junior level, this book serves a dual
purpose: to teach students an organized approach to solving problems, and to introduce
them to the computer and its applications, which may be of use later in their chosen
professions." (* From the publisher's ad.
See also R. Cichelli's review in this
section. *)

P~ter.Grogono, Programming in~, Addison-Uesley, February, 1978,350 pp., $10.50.
An ~ntroductory book; assumes no prior knowledge of programming linguages or computing
techniques." (* Publisher's ad *)

We hear rumors of more texts to come from the UK: one by Jim Welsh and John Elder
(Dept. of COmPuter Science, Queen's Univ., Belfast, N. Ireland BT7 INN), publisher
unknown; and one by David Watt and Bill Findlay (COmPuting Science Dept., Univ. of
Glasgow, Glasgow, Scotland G12 8QQ) , Pittman Publishers. *)

(*

......
N

NEWS FROM UNIVERSITY OF COLORADO -- PASCAL DISTRIBUTION CENTER
Book Review - (Microcomputer) Problem Solving Using PASCAL
By Kenneth L. Bowles
Springer-Verlag, New York, 1977
ISBN 0-387-90286-4
563 pp. ~9.80

REPORT REQUESTS
The following is a list of reports currently available:

Microcomputer ••• PASCAL, the title sounds like a wish. But it's true.
Professor Bowles of the University of California at San Diego (UCSD)
has full PASCAL (with extensions for graphics, character string
manipulation and direct access files) running on interactive single-user
microcomputer systems - Digital Equipment LSI-ll's, Zilog Z-80's, and
8080 based machines. He expects to soon have Motorola 6800 and MOS
Technology 6502 PASCAL systems as well. Almost all of the software for
these systems is written in machine independent PASCAL.
The text, (Microcomputer) Problem Solving ~ PASCAL, is an integral
part of a revolutionary environment for computing education. As Bowles
says, "PASCAL is clearly the best language now in widespread use for
teaching ••• structured programming at the introductory level". By
using PASCAL Bowles is able to introduce algorithm development and
problem solving as components of top-down, stepwise design. Procedures
are introduced right from the start. Flow of control is presented in
terms of modern programming principles (sequence, selection and iteration).
Recursion is presented as an obvious extension of the procedure mechanism.
Data structures are explained fully and clearly.

$6.50

On Code Generation in a PASCAL Compiler
The PASCAL 
 Compiler: Implementation Notes
An Axiomatic Definition of the Programming
Language Pascal

$4.00
$5.50

Concurrent Pascal Implementation Notes
Sequential Pascal Report

$3.00

Richard J. Cichelli
Research Manager, Computer Applications
American Newspaper Publishers Association/
Research Institute
Easton, PA
~
Department of Mathematics
Lehigh University
Bethlehem, PA

$5.00

~appropriate

North America, there is a $2.50 postage and
Overseas orders will be billed for
postage.

PASCAL SYSTEM REQUESTS
We are receiving a lot of out-of-date order forms. The prices
and options quoted on any form prior to September 1977 are no
longer valid. Most important, please note that tapes will no
longer be accepted from buyers. Please phone for details or
request an up-to-date distribution statement.

-n
rn
tp
;;0

Address requests to:

PASCAL Distribution
University of Colorado
Computing Center
3645 Marine Street
Boulder, CO 80309
U.S.A.

c::
::t:>
;;0

-<
I->
<.D

(303) 492-8131

'"
00

In addition to the compiler/interpreter/editor software, the UCSD system
includes a complete computer aided and managed instruction system. The
CAl lessons parallel the text and permit easy management of very large
introductory classes. The system is s1mple and complete in and of
itself and could also be used effectively by high schools and community
colleges to provide low-cost interactive student computing.

Reviewed by:

$3.00

~For orders from
~handling charge.

Because the text uses graphics and text processing programming examples,
unnecessary numericalization of computer science principles is avoided.
At UCSD students from the arts, humanities and bUSiness disciplines are
able to do just as well writing programs for non-numeric applications as
are more mathematically sophisticated students. (Bowles' UCSD course is
phenomenally successful. More than 650 students from all disciplines
registered for it in the Fall of 1977 before registration had to be
closed. They use more than 20 single-user micro-systems - each costs
about $5,500 and consists of micro computer, diskette storage, keyboard
and graphics display.)

Kenneth Bowles has revolutionized the teaching of introductory computing
at UCSD. The publication of this book and release of the UCSD PASCAL
system will permit other schools to follow his lead.

=

PASCAL-S: A Subset and its Implementation

***
ERRATA TO PASCAL USER MANUAL AND REPORT

(* Note:

second edition

These errata were sent to us by Niklaus Wirth in December. The "whole pages"
referred to in a couple of places were not sent. Niklaus stated that so far
25,000 copies of the book have been sold! *)

0. Key s

p

~

page

1 ~ line

c = code

(11 •• 12 means 11 until 12)

r

replace

i
d

insert
dele te

(after the

line mentioned)

1. Errors (to be corrected mandatorily)

p

1

6

5 •• 6

c

149
154
154
154
158

-15 I"
-19 I"
- 15 I"
-14
r
213 •• 21

" hue" by "hue1"
"1130" by "63 "
"a [ i ,k1 *b[k ,j]" by "A[i ,k1 *8[k,j1"
"c[ i ,j 1 " by "c [ i , j 1 "
I" both lines by
("'")
"Concerning the procedures read, write, readln, writeln, and page'::J>
"see chapter 12."
r
"procedure " by ".l2Iocedures"
-13 I"
z
-8 r
" by"
T re
tag"
-8 i
field values must be listed contiguously and in th<~
order of thei r
decla ra tion
and must no t be changed en
during exec ution ...
::dispose (p)
indicates that storage
occupied
by the variable pT H'l*;
is no longer needed.
If
the second form of new was" ........
used to allocate the variable then
" ........
"dispose(p,tl, . . . . tn) with identical
tag field
values must be"
"
used
to indicate
that
st~rage occupied by this"
va rian t i s no longe I" needed."
-13 i
'+'
no line feed (overprinting)"
-17 •• -16 exchange the two lines
I"
whole page by the correctad one to be found in the enclosure

both lines by
of
"construct.
Enclosure
of
se quence
con struc ts"
a
repetition"158
"by
the
meta
brackets
{ .and
implies
their
158
21
12 I"
whole line by
except"158
"Assignment
is
type,
po ssible
va riable s
to
of any
15 r
35
whole line by
"constant value in the subrange ,where the lower bound must not be"
16 r
"less
than
the" by
35
"greater than the"
513
8
d
whole line
"implementations" by "Implementations"
513
9 r
513
"first operand is a scalar type ," by
-4 I"
"second
operand
is of
a
se t"
165
513
-3 •• -1 I" all the lines by
type,
the
first
of
its associated base type; the' 166
resul t is true
when the first is an
element of the' 167
second, otherwise false ."
59 -11 •• -113 I" both lines by
be'2. Printing Errors (to be corrected optionally)
"NLUlit: The
standard
procedures J:lUl.e..j;
(rewri te) must not
"a ppl ied to the file in put (0 utput) • "
"a
[
i
1
..
by
"a
[
11
"
69
8
I"
p
1
c
"Then ," by "Then:"
86
17 I"
86
18 d
whole line
39
6
r
"eof(f)" by "eof(x) .....
89
12 I"
"multidimentional" by "multidimensional"
613
-7 I"
"printeo" by "printed"
"textfiles." by "files."
913 -8
r
61
-1
r
"5S"
by
"59"
"paramenter" by "parameter"
97
7 I"
64
13 r
" ne" by "one"
H5 25 •• 26 I" bo th 1 1.-n e s by
71
"paramen te r" by "pe rame te r 0'
3 r
"read, readln, write, writeln are discussed in chapter 12."
., f" by "of"
71 -10 I"
" by
-4 r
91
13
r
" and are subsituted" by "and are substituted"
They must
not
be
changed"
96 - 11
"nf" by "of"
r
1135 -4 i
during exec ution •
.......f .. by "ll.f"
17 r
the" 98
"dispose (p)
indicates
that
storage
occupied
by
.. ut" by "out"
99 -5 r
variable pT is no longer needed."
.. by "
1135 -14 r
"procedure ~. by :nrocedu:':"8s"
The"
1135 -1
r
1135 -1
tag field values must be identical to tho se "1~5 -13 I"
i
.. --------by
---------163
"if" by "If"
14 I"
used when allocating the variable."
163 -113 I"
"i f" by "I f"
"~i.w:J..ll" b y "0 oe ra to r.s "
1138
2
I"
"if" by "If"
163 -7
r
1113
12 •• 13 d both lines
116
1 d
"PASCAL"
118
r
whole page by the corrected one to be found in the enclosure
~_~~:~~::_~~:::~~:_:~:::~~:~~:
126 •• 1281"
all three pages by the corrected ones to be found in the enclosure
"three" by "four"
136 -H' I"
p
c
1
"and
procedure
or" by
136 -9 r
proced ure
and"
"p .. by "P;"
32 -16 I"
1413
15 .. 19 r ell the lines by
"The general" by "Its"
I"
the
meaning
of
a"
36
-113
::~,~
this
has in
general
no
effect on
36 -7 r
whole line by
"scalar or subrange
type
(where
types
in tege I"
"program (for a restriction see 9.1 •. 2.);
but i t is a hint to tha"
"index" by "not allowable index"
I"
::compiler that storage should be economized
even at the price of" 36
42
.. field identifier is the smallest" by
I"
Some loss in ef'ficiency of access.,
and
even if this may expand"
"field identifier is the innermost"
"the code
necessary for
expressing access to components of the"
";"
by
-6
I"
"structure."
59
2
I"
142
"test for equali ty." by
fJ6
-4 r
::;" by
.. by ..
"assignment and the"
67 -3 I"
";" bye .....
6
I"
142 -4
"test for equali ty."
69
i
.. ( 6)" by" [ 61 ..
r
145 -113
"operands, i.e.
by
76
I"
"schemas" by "schemes"
"0 pera to rs
and"
89 -1 1 r
18 r
":" by ":"
145 -9 I"
whole line by
1135
by ",
preceded
by an appropriate number of"
"operands, i.e. variables, constants, and functions."
163 -6 r
blanks as specified by m.
146
12
r
"" by ""
163 -6 i
I"

-"

rn

to
;;:0

=

:J>
:;:0

-<

and

real

are

-0

128

127

»
C/)

n

When

a

reference

Appendix A), then
x1

in

this

index

is not a

section name

(e.g.

the reference may be of the following forms:

x 1 .x2

x1.x2.x3

x1 is always the chapter number. x2 may be a capital letter in
which
case
i t may be followed by x3, a number, and refers to a
chapter section. When x2 is a small letter, the reference is a
figure; when x2 is a number, the reference is a program.

alfa (PASCAL 6000-3.4)
13.0.1
array types
6
assignment statement
4.A
binary tree
11.A
block
0
RNF defini tion s
A ppendi x D
Roolean
2.A
case statement
4.0.2
char
2.0
character sets
13.8.3
commen t
1
compile r erro r me ssa!les
14.C .1, Appendix E
compiler options (PASCAL 6000-3.4)
13.8
compound statement
4.8
condi tional statements
4.0
constant declaration part
3.C
control statements (PASCAL 6000-3.4)
14.A
control variable
4.C.3
da ta ty pe s
2
declaration part
3
empty statement
4.8
equivalence
2.A
ex pre s sion
4.A
field list
7
figure s
after (list insertion)
10.c
alternative representation of standard symbols
ASCII character set (with COC's ordering)
13.a
before (list insertion)
10.b
binary tree structure
11.b
block structure
0.b
CDC scientific character set (with 64 elements)
expressions

11 .. 8

iden ti fie r
l.a
linked list
10.a
syntex diagram of program structure
0.a
two sample people
7.a
unsigned number
1.b
file types
9
external files (PASCAL 6000-3.4)
13.8 .1
representation in PASCAL 6000-3.4
13.8.2
segmen ted file s (PASCAL 6000-3.4)
13.A .1

textfiles
9.A
for statement
4.C.3
fo rwa rd refe rence
11.C
functions
11.8
declaration part
3.F
de signa tor
11.8
heading
11.B
predefined (PASCAL 6000- 3.4)
1 3.D .2
standard, table of
Appendix A
global variables
11.A
goto statement
4.E
Appendix C
identifiers, table of standard
if statement
4.0.1
implication
2.A
input
9.8
inte!ler
2.B
I/D
12
label s
case
7.A
declaration part
3.8
goto
3.B, 4.E
11 sts (linked)
10
11.A
local variables
name precedence
11.A
no ta tion
1
numbe rs

13.b

13.a

operator precedence
4.A
operators, summary of Appendix 8
output
9.B
packed structures
6
parameters
11.A
PASCAL 6000-3.4
13, 14
ocinter types
10
proced ure s
11.A
declaration part
3.F
external procedures (PASCAL 6000-3.4)
heading
11.A
predefined (PASCAL 6000-3.4)
13.D.2
procedure statement
1 1.A
standard, table of
Appendix A
prog ram heading
3.A
(PASCAL 6000-3.4)
13.B .1
programs and program parts
begin end
4.1
bi sec t
11.6
complex
7.1
convert
3.1
cosine
4.5
egalfa
13.1
egj"or
4.4
egrepeat
4.3
egwhile
4.2
examples of goto
4.E
exponen tia tion
4.8
expon 2
11.8
fo rwa rd refe rence
11.C
frequency count
9.1

graph 1 4.9
g ra ph 2 6.2
infla tion
0.1
insert
9.2
matrixmul
6.3
merge two files
minmax

»
r

::2

9

6.1

minmax2
11.1
minmax3
11.2
parameters
11.3
10
pointers, construction via
postfix
11.4
primes
8.2
recursivegcd
11.9
roman
4.7
setop
8.1
sideffect
11.7
sum file of real numbers
9
summing
4.6
tree traversal
11.5
read, the standard procedure
12.A
real
2.C
record types
7
relational operator
2.A, 4.A
repeat statemEtnt
4.C.2
repetitive statements
4.C
re se rved wo rd s--see wo rd -cI el imi te rs
restrictions (PASCAL 6000-3.4)
13.C
run -time error messages
14.C.2
scalar types
5.A
schema ta

read a text
9.A
read a text from "input"
9.A
read and write a segmented file
13.A.1
reading a segmented file
13.A.1
13.A.2 reading arbitrary number of numerical
i terns from a textfile
12.A
write a segmented file
13.A.1
wri te a text
9.A
write a text onto "output"
9.A
wri te a te x t x to ,y
9.A
seo pe
0
sepa ra to rs
se top e ra to r s 8
Set types
8
side effec t
11.8
standard identifiers Appendix C
string
1, 6
subrange types
5.B
syntax diagrams Appendix 0
tables
block structure
0
defaul t value for field width
13.B.4
operations on textfiles
9.A
printer control characters
9.8, 13.8.4
special symbols
1
truth val ue s
2.A

rn
::e::
C/)
~

I--'
I--'

-0

:r:>

167

REVIEW OF PASCAL NEWSLETTERS
parameter qroup
painter type
poin ter variable
procedure and function
declaration part

procedure
procedure
procedure
procedure

declaration
heading
identifier
or function declaration

proced ure 5ta temen t
prog ram
proqram headinq
program parameters
record section
record type
reco rd va riab Ie
reco rct va riable 1 is t
mfe ranced va riable
rels tional opera tor
repeat statement
re pe ti ti va sta temen t
resul t type
scalar type
scale factor
set
set type
sign
simple expression
sim pI e s ta temen t
simple type
special symbol
sta tem en t
statement part
string
struc tured sta temen t
structured type
sub ran ge type
tag field
term
type
type defini tion
type definition part
type identifier
~labelled
statement
~packed structured type
unsigned constant
~ signed integer
1.J1 siqned numbe r
unsigned real
teriable
variable decla ra tion
va riable ctecla ra tion part
va riable identifier
\.€I. rian t
variant paTt
\Nh 1.1 e s ta to IT] en t
wi th s ta temen t

10.

6.3
7.3

5, 6, 7,

AND

8

Because issues 5, 6, 7, and 8 are now out of print, we ought to lay them to rest
properly. This will end a lot of curiousity among new PUG members regarding their
contents.

10.
111.
10.

9.1.2
10.

9.1.2
13.
13.
13.

6.2.2
6.2.2
7.2.2
9.2.4
7.3
8.1.4
9.2.3.2
9.2.3
11 •
6. 1. 1

4.
8.
6.2.3
4.
8.
9.1
6.1

3.
9.
10.
4.
9.2
6.2
6.1.3
6.2.2
8.

6.
6.
10.
6.1
9.

6.2
8.

4.
4.
4.
7.
7.
10.
7.1

6.2.2
6.2.2
r;. 2.3.1

9.2.4

en
\)

:r:>
r:2

rn

Issues 5-8 were the first to be produced under PUG auspices - see explanation on
page 11 of Pascal News 9/10, September, 1977. I suggest you contact PUG members near you
and photocopy any issues or parts of issues you really want.
- Andy Mickel

::e::
en

Pascal Newsletter #5, September, 1976.

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

:f:t:

Editor's Contribution: established user group and newsletter policies; recounted the
history of the formation of Pascal User's Group over the previous year; described
Pascal activities at the University of Minnesota; suggested that all was not well
with Pascal because implementations proliferated different features, implementors
and critics disregarded Pascal's language design goals, and finally people not
having realized the importance of simply making the use of Pascal a respectable
activity; acknowledgments to all that helped PUG make a start.
Here and There: 2 conference announcements - a Pascal get-together at ACM '76
in Houston and a preliminary notice of the Pascal Symposium in Southampton in March.
a summary of existing or planned textbooks on Pascal; news from Pascalers; errata
to the second edition of Pascal User Manual and Report.

Articles:
"Designing Data Structures by Step-wise Refinement"
- Richard J. Cichelli
[Dijksta and Wirth have defined the principles of systematic programming. They
illustrated these principles'by designing programs whose control structures
reflected hierarchical abstractions of their logic flow. In this paper, systematic
programming principles are applied to the design of a program's data structures.]
"In Defense of Formatted Input"
- John Eisenberg
[Formatted input can be useful in many cases, and almost necessary in others.
Thre'e examples of "typical" basic computer science problems are presented which
would be inconvenient or next to impossible without the use of formatted input.]
"Overlays: A Proposal"
- James F. Miner
[As the availability of Pascal for serious productions grows wider, it will become
evident that many implementations will need to cater to features commonly
employed in production work which are not currently found in implementations of
Pascal. The need to reduce the amount of storage required for a program's object
code is such a feature and a proposal for overlays is given here as a remedy.]
"'Minor' Problems in Pascal"
- Timothy M. Bonham
[A number of syntactic details in Pascal are criticized - not to prove that Pascal
is a bad language, but on the contrary to perfect a language which is easily one
of the best around, because of its logical clarity, austerity, and the readability
of source programs.]
"Dynamic Array Parameters"
- Chris Jacobi
[A description is given of a proposed extension to Pascal-6000 to implement dynamic
array parameters. This solves a serious problem in the construction of subprogram
libraries written in Pascal. A set of amendments to the User Manual and Report
are given, as well as syntax diagrams and an example program.]

Articles:
Open Forum:

urndexed Files"
- Svend Knudsen

75/11/05 John Eisenberg to Andy Mickel: [Pascal-S, University of Illinois PDP-II Pascal,
the User's Group]
75/11/22 Urs Ammann to Andy Mickel: [Pascal-6000 extensions (dynamic array parameters
value part, constructors); Pascal Day in Switzerland]
75/11/25 Andy Mickel to Niklaus Wirth: [questions about the language Pascal, changes
to the language, and to features in Pascal-6000]
75/12/10 Niklaus Wirth to Andy Mickel: [distinguish clearly between language and
implementation; reply to questions about changes; literature.about Pascal]
75/12/29 Andy Mickel to Niklaus Wirth: [looking at the nature of change - several
versions of the Pascal Report, details on Pascal-6000 changes, conventionalized
extensions; Pascal Newsletter / Pascal User's Group]
76/01/12 Ed Fourt to Andy Mickel: [Lawrence Berkeley Labs and Pascal-6000]
76/01/14 Hellmut Golde to Andy Mickel: [Pascal-6000 at the University of Washington
Pascal-Fortran subprogram linkage]
76/03/08 Wilhelm Burger to Andy Mickel: [Pascal-6000 at the University of Texas, and
implementation changes]
76/03/09 Richard Cichelli to Andy Mickel: [Soma cube paper, Pascal at Lehigh University
DEC PDP 11 Pascal and UNIX]
76/03/15 Andy Mickel to George Richmond: [Where is Pascal Newsletter #4?, our plans
for the User's Group / Newsletter, plans for the transition]
76/04/05 Susan Stallard to Andy Mickel: [IBM 370 Pascal at the University of Southern
California]
76/05/04 Philip Enslow to Andy Mickel: [Pascal-6000 at Georgia Tech, Brinch Hansen
Pascal on the B5700]
76/05/23 Harry M. Murphy to Andy Mickel: [Pascal-6000 at Air Force Weapons Labrrtory
variable dimension array problems]
76/05/26 David Elliot Shaw to Andy Mickel: [PDP-II Pascal employment at Structured
Systems Corporation]
76/05/27 Charles L. Lawson to Andy Mickel: [Pascal and Numerical Software, adjustable
array dimension problems. Pascal on the 1108 at Jet Propulsion Labs]
76/06/18 George Richmond to Andy Mickel: [Pascal Newsletter #4, updates on distribution
information on Pascal-6000 and Pascal-P]
76/06/18 Steve Bellovin to Andy Mickel: [Pascal on the 370 at the University of North
Carolina - Chapel Hill, problems with Pascal-P2]
76/07/01 James Kendall to Andy Mickel: [Pascal on several machines at the Texas State
MHMR Department]
76/07/22 Steven Soule to Andy Mickel: [Pascal at the University of Calgary, Pascal's
inability to subvert Fortran]
76/07/23 Mike Hagerty to Andy Mickel: [Pascal-6000 modifications, Pascal Standards
committee, solicit ACM sponsorship, formatted reads]
76/07/23 George Richmond to Niklaus Wirth: [Explanation of current situation regarding
distribution of compilers, Pascal Newsletter and transfer of duties to other persons]
Implementation Notes: Checklist, Pascal P3 and P4, Pascal Trunk, PascalJ, Pascal-S
Machine Dependent Implementations: B6700, CDC-6000, DEC PDP-II, DECsystem 10,
Honeywell 6000, IBM 360/370, Univac 1100.
Pascal Newsletter #6, November, 1976.
Editor's Contribution: Standards - course to take very confusing; Pascal User's Group
mechanics and finances; feedback from PUGN#5; establishment of a PUG outpost in
the United Kingdom.

[In addition to the possibility of dividing sequential files into segments
(creating a "segmented file"), it is also possible to construct, read, and

modify indexed files. This feature also covers the need for rapid location and
modification of segments.]
liThe Need for Hierarchy and Structure in Language Management"

- G. Michael Schneider
[I find it quite ironic that so much concern is being paid to problems of structure
and organization of statements within the Pascal language but so little to the
structure and organization of the management of the language itself. By this I
mean that there is currently lacking a formal administrative hierarchy for the
handling of questions relating to language standards, specifications, and
ext ens ions]
"Pascal Potpourri"

- Richard J. Cichelli
[A set of (perhaps ill-formed) topics for the Pascal User is presented for debate:
the problem of direct access files, standards and the language Pascal, software

tools for the Pascal user]
"The Case for Extending Pascal's I/O"
- Michael Patrick Hagerty
[With the introduction and subsequent increase in the popularity of Pascal, a number
of papers concerning the language, its features and deficiencies, have appeared

in various journals and newsletters.

Champions of the language have extolled the

virtues of its structure and unambiguous grammar using both example and theory as

justification of its usefulness. Pascal critics on the other hand, have questioned
the claim of the proponents that Pascal will replace FORTRAN, pointing to the
inadequacies of the language in several areas. Wirth (1974) defends the absence of
certain "favorite features" as necessary to avoid inefficient programming solutions

or reliance upon features which are contrary to the aim of clarity and reliability.
When the features being debated refer to the flexible input of large amounts
of data, the critics hold the stronge~ hand, and with much justification.]
"General Thoughts on Pascal Arising out of Correspondence Between Southampton
and Tasmania"

- Arthur Sale
[a set of topics of potential interest to the Pascal community:

Mixed languages,

Portability, Inclusions of Source Text, Files, Standards]
Open Forum:
76/07/28 Rich Cichelli to Andy Mickel: [Ifuat happened to Pascal-6000 Release 2?
Pascal CAl system]
76/07/30 Brian Rowswell to Andy Mickel: [Pascal at the University of Sydney Computing
Centre]
76/08/17 Willett Kempton to Andy Mickel: [Pascal for applications in anthropology, the
case for formatted reads.]
76/08/31 Henry Ledgard to Andy Mickel: [Pascal Prettyprinter at the University of
Massachusetts]
76/09/13 Duke Haiduk to Andy Mickel: [Pascal on DEC-I0 for teaching at West Texas
State University]
76/09/16 Olivier Lecarme to Andy Mickel: [European distribution of Pascal Newsletter,
PUG session at IFIP '77, book by Bill Atwood, news about Pascal in France (activities
and efforts), Pascal language publication notation, comments on Tim Bonham's paper

Here and There: News from Pascalers; empirical study of Pascal programs by John Banning
at Stanford; agenda for the international Pascal Symposium at the University of
Southampton; update on textbooks; update to errata to the Second Edition of Pascal
User Manual and Report; listing of contents of Pascal Newsletters 1, 2, 3, and 4;
PUG roster of 516 members.

news of translation of the book Systematic Programming into French]
76/09/17 Robert Novak to Andy Mickel: [remarks in reply to Eisenberg's article on
formatted input.]
76/09/22 Stephen Young to Andy Hickel: [Impressed with Pascal - should have a Pascal
standards committee]
76/09/29 Tony Addyman to Andy Mickel: [Pascal-6000 details, Pascal standards group
should be formed.]

-n

rn
tr.1
::0

=
:J>
::0

-<
f-'
lD
'-J
00

Open Forum:
76/10/09 Rich Cichelli to Andy Mickel: [Contribution of William Waite's dues to PUG
"Which Language?" article in British Computer Society Bulletin]
76/10/11 Charles Hedrick to Andy Mickel: [Pascal versus SAIL and PL/1 in AI work,
Pascal on the DEC-10 at the University of Illinois]
76/10/15 Niklaus Wirth to Andy Mickel: [disagreement with the policy of printing
private letters and letters to the editor]
76/10/21 Duke Haiduk to Andy Mickel: [liked Pascal Newsletter #5, Brinch Hansen Pascal
on the DEC-10?]
76/10/22 Arthur Sale to Andy Mickel: [series of letters between Southampton and
Tasmania may be of interest; Pascal implementation proliferation; B6700 Pascal]
76/10/04 Judy Mullins to Arthur Sale: [ICL 1900 / 2900 Pascal: I/O, standardization,
compiler options, else in case, syntactic sugar]

76/10/22 Arthur Sale to Judy Mullins:

[standards, character sets, B6700 commenting

conventions, else in case, mixed languages, files, diagnostics, compiler options

sets, bounds checking, B6700s: arrays and off stack storage, pointers speed & space]
76/10/29 Jonathan Sachs to Andy Mickel: [Interest in the Tokyo 370 compiler at
Trans Union Systems Corporation]
76/11/04 Tim Bonham to PUG membership: [Comments on Jacobi's Dynamic Array Parameters
standardization, Pascal on the IBM System 3?, CDC 3200?]

76/11/18 David Barron to Andy Mickel:

[Against the continuation of Fortran "carriage

control character" conventions into Pascal]

76/12/09 Andy Mickel to Niklaus Wirth: [PUG should have your reaction to the issue of
formal standardization of Pascal]
76/12/10 Andy Mickel to Chris Jacobi: [PUG needs the results of the Pascal-P
questionaire and sites using Pascal-P]

77/01/02 Arthur Brown to Andy Mickel: [A Pascal standards committee should be set up standard Pascal should be close to the Revised Report and extensions to standard
Pascal compilers should be written in standard Pascal.]
77/01/03 Jim Miner to Andy Mickel: [Revised Report good in its stated aim; but
production uses of Pascal dictate a need for a standard. Fear that a committee
will decide what the standard will be - current users are vulnerable because we
have an investment in code.]

Implementation Notes: General Information, Checklist, Pascal-P, PascalJ, Software
Writing Tools, B6700/7700, CII Iris 80, 10070, DEC PDP-8, DEC PDP-II, Foxboro Fox-1
IBM 360/370, IBM 1130, Interdata 8/32, Univac 90/70, 1100, Xerox Sigma 6/9,Sigma 7.
Pascal Newsletter 118,May, 1977.

Implementation Notes:

General Information, Checklist, Pascal-P, Concurrent Pascal,

Pascal prettyprinter, Machine Dependent Implementations: B1700, B4700, B6700,7700
CII 10070, Iris 50, Iris 80, CDC-6000, CDC-7600, CRAY-1, DECsystem 10, DEC PDP-II
Foxboro FOX-I, HP-2100, 3000, Honeywell H316, level 66, IBM 360/370, IBM 1130
Interdata 7/16, Motorola 6800, Prime P-400, Siemens 4004-157, Univac 1100,
Varian V73, Xerox Sigma 6, 7, 9.
Pascal Newsletter #7, February, 1977.
Editor's Contribution: Promoting Pascal Usage (experience at the University of
Minnesota); Pascal and Standards - conventionalizing extensions; PUG and Pascal
Newsletter mechanics.
Here and There:

News from Pascalers, a new textbook, roster update.

Editor's Contribution: Renewal reminder, new developments with microprocessor Pascal,
PUG and Pascal Newsletter, Pascal publicity, future, backissues, membership, end

of the year acknowledgements.
Here and There: News from Pascalers, 2 Pascal get togethers planned at IFIP '77, and
at ACM '77, Report on the University of Southampton Pascal Symposium, large Books
and Articles section with new policy announced, first news about DoD-1 (a common
language for U.S. Department of Defense use), a book review, several Pascal
applications reported.
Articles:
"Development of a Pascal Compiler for the C.I.I. Iris 50, A Partial History"
- Olivier Lecarme

[The history which is the subject of the present paper takes place in the University
of Nice, a medium-scale University with about fifteen thousand students.

Articles:
"Life, Liberty, and the Pursuit of Unformatted Input"
- David Barron and Judy Mullins
[In PUGN #5, Eisenberg presents three examples which, he claims, demonstrate
the necessity for formatted input. This note attempts to demolish those claims.
•• • WARNING: FORTRAN CAN IMPAIR YOUR JUDGEMENT.]
"Pascal Printer Plotter"

- Herb Rubenstein
[This printer plotter consists of four Pascal callable procedures. A high speed
line-printer or a 132 column hard copy interactive terminal is used for output.
The plots are X-Y graphs scaled to fit a single sheet of printer paper. Axis
labels and axes are automatically set up. Plots may be overlayed and expansions
can be performed to blow up tiny pieces of a plot.]
"Yet Another Look' at Code Generation for Pascal on CDC 6000 and Cyber Machines"
- Lawrence A. Liddiard
[Pascal 2 is amenable to several different methods of compiler length reduction.
As a fellow compiler writer (although since MNF is written in machine language
it may be compared with the last of the dinosaurs speaking to Homo sapiens),
I would rather see the full language specifications and one standard compiler,
than to see small subsets such as Pascal-So For this reason I think it
essential to improve Pascal 2 and with the reductions discussed in this article
it should be possible to obtain load lengths of approximately 30K octal for the
full language rather than the current 44K octal on a CDC 6000 (i. e. a reduction
by one-third).

The

history of the Pascal Compiler development covers several attempts (illustrated by
"T" diagrams) and finally a description of the nearly completed successful effort.]
"A Further Defence of Formatted Input"
- Brian Meekings
[In PUGN #7, Barron and Mullins attempt to demolish the case for formatted input •
Without wishing to blow up the controversy beyond reasonable proportion, I would
like to add a voice in favour of formatting. The addition of formatted input
to supplement the existing unformatted input facilities, can only enhance an
already versatile language.]
"proposals for Pascal"

- George H. Richmond
[A laundry list of idealized proposals are presented making the case for improvement
in the areas of: the representation of Pascal for computer input, compile options,
internal character set, removal of current restrictions and asymmetries, the
program declaration, variant records, the case statement, boolean expressions,
constants, declarations, and constructors, value initialization and own variables,

procedure and function types for compile time checking, dynamic array parameters,
new basic types and operators, transfer functions, extension of relational operators

to structured types, files and text files, formatted input and output, file
handling, overlays, and preambles and postamble.]
"A Proposal for Increased Security in the Use of Variant Records"
- William Barabash, Charles R. Hill, and Richard B. Kieburtz
[The use of variant records in most Pascal Implementations is dangerous because
most compilers do not emit a check for conformity with the value of the tagfield

when a variant field is referenced. Indeed, the latest version of the Revised
Pascal Report defines a language in which the tagfield may even be absent, making
conformity checks impossible! Even so, when the tagfield is present and the
compiler does emit conformity checks automatically, the programmer still has the
ability to dynamically assign values to the tagfield.]
"Update on UCSD Pascal Activities"
- Ken Bowles
[A potpourri of lively events at the University of California, San Diego is
reported including their microprocessor Pascal system on LSI-ll, Z-80, 8080,
6502, and 6800 based systems. Also reports on LSI-ll hardware, other micro
hardware, a proposal for a manufacturer independent Pascal System, news about
an introductory Pascal textbook, the UCSD B6700 compiler, and a sample graphics
picture from the LSI-ll system are given.]

the case statement, and handling of TEXT variables.]
77/03/07 Richard Kieburtz to Niklaus Wirth: [Comments invited by Wirth on complete
typing of formal procedure parameters, field width specifications in the arguments
of the procedure write.
strings.

Also comments on dynamic arrays, array and record constructors,

default in case lists, and formatted input.]
77/03/29 Andy Mickel to Southampton Symposium: [The Future of Pascal (Extensions and
Standardization). A summary of the present state of affairs around Pascal and
the desire for a standard; desirable goals for Pascal and current problems;
consideration of a standard.]

77/04/07 Tony Addyman to Andy Mickel: [News on BSI / ISO standardization effort.
A three page "attention list" of problems in the Pascal Report.]
77/04/24 Andy Mickel to Tony Addyman: [When in the BSI Working Group, don't forget the
principles:

"Some Comments on Pascal 1/0"

- Chris Bishop
[While admitting that Pascal has I/O specifications involving the concept of files
and the GET and PUT statements that are consistent with the flavour of the
language and with theoretical manipulation of data, I feel that it is lacking
in simple, easy to use I/O and in flexible I/O.]

On suggested extensions - relax the restriction on the

maximum cardinality of set types, typed structured constants, and variable length

"don't confuse the language with the implementation ll and IIsome aspects

are intentionally left undefined in Pascal and must be defined by implementation",
possible meanings for omissions in the Revised Report.]
(* * * End of Special Topic: Standards * * *)
77/01/28 Arthur Sale to Andy Mickel: [Pascal has more to fear from its friends than
its enemies, defense of editorial attack in PUGN6; Pascal Files - are Pascal's
files inadequate?, are files variables?, is the best way to random access through
slow array of ••• ? What relation is there between Pascal files and our operating
system files? Pascal's two greatest dangers are from naive extensions and Pascal

Open Forum:

77/01/14 Nick Solntseff to Andy Mickel: [The nature of standardization efforts on
Pascal and perhaps operating system independence as well]
77/01/12 Michael Condict to Andy Mickel: [Comment that "slow array" more appropriate
than Rich Cichelli' s "long array" in PUGN 116 article]
77/01/04 Larry Landis to G. Michael Schneider: [Ao endorsement of Schneider's standards
proposals in PUGN 116 article]
77/02/14 Robert Fraley to Andy Mickel: [A case for revising Pascal -> 3 ~ndatory
extensions for Pascal so that it can compete with FORTRAN: parametrlc arrays
shared variables in separate compilations, and input formatting.]

77/01/24 Mike Hagerty to Andy Mickel:

[On the standard, mods to the standard, mods to

the implementation, available software, otherwise in case]

Special Topic - Standards

..

.

(* A very important exchange regarding standards and conventl0nallzed extensl0ns

follows. At the Southampton Pascal Symposium, Tony Addyman made the case for
a formal ISO standard without a standards committee through BSI. Votes were
taken which called for standardizing the Revised Report with semantics

tightened.up, adopting a set of conventionalized extensions, and a list of
designated extensions not to be conventionalized. *)
.

77/01/31 Niklaus Wirth to Andy Mickel:

[Regarding standards, extendlng Pascal, Standard

Pascal Recommended set of extensions: dynamic array parameters, array and record
constr~ctors; possibility of unnecessary but convenient extens~ons:. default in
case lists, and formatted input. Other extensions per se for ~ndiv~dual.computer
systems admissable but they have no place in the Standard language. Var~ous

comments on PUGN#6, especially regarding criticism of Pas:al:]
77/02/09 J¢rgen Steensgaard-Madsen to Andy Mickel: [Comments lnvlt~d b~ Wirth on

fanaticism.

The language has defects; it has strengths.

Let's be a bit more

cautious.]

77/02/14 Arthur Sale to ~ndy Mickel: [3 criticisms: 1) Sea mail distribution of PUGN
overseas unacceptable, 2) Editorial sniping, 3) Pascal Support - Bill Waite's
criteria.

Distribution of software; we don't need crusaders yet; despite bits

of rubbish PUGN serves a very useful purpose, publishing Arthur Sale - Judy
Mullins correspondence.]
77/04/26 Andy Mickel to Arthur Sale: [Apologies for editorial sniping, reasons for
seamail distribution of PUGN, Pascal files, CDC bias, PUGN's non-academic membership
Pascal usage at Minnesota.]
77/03/04 Olivier Lecarme to Andy Mickel: [PUG produces PUGNs faster than I can read
them. CII Iris 50 news, Pascal Subgroup formed in AFCET (French counterpart
of ACM), compiler writing system.]
77/03/28 Nick Fiddian to Andy Mickel: [Plea to recognize the value to others of the
software products we originate; invest accordingly in faithful standardization down with backstreet implementors.]
~mplementation

Notes: Checklist, General Information, Microprocessors, Software Writing
Tools, Pascal-P4 corrections, Pascal Trunk Compiler, PascalJ, Medula, Feature

Implementation Notes: Reading and Writing Scalars (Arthur Sale), Pointer Values
(Arthur Sale), Pointer Tests (Andy Mickel). Machine Dependent Implementations:
B3700 / B4700, B6700, Computer Automation LSI-2, CDC Cyber 18, CDC 6000,7000,
Cyber 70,170, Data General Nova, DEC-l0, DEC PDP-ll, HP-2100, Honeywell H66,
IBM 360/370, IBM 1130, ICL 1900 / 2900, Intel 8080, Motorola 6800, Nanodata QM-l,
Norsk Data Nord 10, SEMS T1600/Solar, Siemens 4004, 7000, TI ASC, TI 990/9900,
Univac 90/70, Ull00, Varian V70, Zilog Z-80.

initialization of variables, dynamic arrays, exhaustive specif~cat~on of parameters,

ROSTER INC REM ENT (7 7 /12 /31 )
The names listed below represent people who have renewed, changed address or joined PUG
since the roster was printed in PUGN #9/1~.
01002
01451
01545
01581
01609
01701
01701
01701

HENRY F. LEDGARD/ COMPUTER AND INFO. SCI./ U OF MASSACHUSETTS/. AMHERST MA 01002/ (413) 545-2744/ (413) 545-1332
RALPH S. GOODELL/ HILLCREST DRIVE/ HARVARD MA 01451/ (617) 456~8090
JOHN DE ROSA JR./ 3Z-G BRANDYWINE DRIVE/ SHREWSBURY MA 01545
JOHNNY STOVALL/ 15 TURNPIKE RD./ WESTBORO MA 01581/ (617) 366-8911
STEPHEN R. ALPERT/ COMPo SCI. DEPT./ WORCESTER POLYTECHNIC INSTITUTE/ WORCESTER MA 01609/ (617) 753-1411 X416
MARGARETTA HOMMEL/ 43 ADAMS ROAD/ FRAMINGHAM MA 01701/ (617) 879-6848/ (617) 890-8460 X208 X351
BARRY F. MARGOLIUS/ DEPT. OF COMPUTER SCI./ FRAMINGHAM STATE COLLEGE/ FRAMINGHAM MA 01701/ (617) 872-3501 X224/ (617) 266-6648 (HOME)
ROBERT J. OBERG/ DEPT. OF MATH AND COMPUTER SCIENCE/ FRAMINGHAM STATE COLLEGE/ FRAMINGHAM MA 01701/ (617) 852-3501

-n

rn
t:>:I
:;;0

=

::t:>
;;0

-<

01730
01741
01752
01754
01776
01778
01810
01852
01886
01960
02035
02114
02132
02138
02138
02138
02138
02139
02142
02154
02159
02165
02165
02172
02840
02912
02912
03060
03755
03824
06106
06268
06437
06477
06520
06810
06901
07054
07470
07724
08077
08512
08618
08826
08854
08854
08876
08903
09098
10003
10009
10010
10011
10012
10012
10016
10019
10024
10024
10025
10027
10510
10573
11210
11439
11740

ROGER D. ROLES/ COMPUTERVISION CORP./ 201 BURLINGTON RD/ BEDFORD MA 01730/ (617) 275-1800 X212
STEPHEN KLEIN/ 188 JUDY FARM ROAD/ CARLISLE MA 01741
CARL W. SCHWARCZ/ MR 1-2/E27/ DIGITAL EQUIPMENT CORP./ 200 FOREST STREET/ MARLBORO MA 01752/ (617) 481-9511
ROBERT TROCCHI/·EDUCATIONAL PRODUCTS GROUP/ DIGITAL EQUIPMENT CORP./ PARKER STREET - PK3-1/M40/ MAYNARD MA 01754/ (617) 493-3475
RANDY ENGER/ 28 BRIAR PATCH LANE/ SUDBURY MA 01776
PAUL BARR/ EQUIPMENT DIVISION J9/ RAYTHEON CO./ BOSTON POSTROAD/ WAYLAND MA 01778/ (617) 358-2721 X2825
ROBERT I. DEMROW/ 11 LINDA DRIVE/ ANDOVER MA 01810
EDWARD STEEN/ 119 SHERMAN STREET/ LOWELL MA 01852/ (617) 454-9320
RICHARD KRASIN/ FIRST DATA CORP./ 1 MAIN STREET/ WESTFORD MA 01886
SAM CARPENTER/ 22 PULASKI ST. APT. B-7/ PEABODY MA 01960/ (617) 532-0669
WARREN R. BROWN/ D.330/ THE FOXBORO COMPANY/ 38 NEPONSET AVE./ FOXBORO MA 02035/ (617) 543-8750 X2023
RICHARD PITKIN/ COMPUTER NETWORK/ MASS. STATE COLLEGE/ 150 CAUSEWAY ST./ BOSTON MA 02114/ (617) 727-2530
BILL SOUTHWORTH/ 30 POTOMAC ST./ W. ROXBURY MA 02132/ (617) 323-4537
FRED LUHMANN/ ABT ASSOCIATES INC./ 55 WHEELER ST./ CAMBRIDGE MA 02138/ (617) 492-7100 X424
JAMES S. MILLER/ INTERMETRICS INC./ 701 CONCORD AVE./ CAMBRIDGE ~~ 02138/ (617) 661-1840
DENNIS J. MURPHY/ ABT ASSOCIATES INC./ 55 WHEELER ST/ CAlIBRIDGE MA 02138/ (617) 492-7100
ROBERT E. WELLS/ BOLT BERANEK AND NEWMAN INC./ 50 MOULTON STREET/ CAllBRIDGE MA 02138/ (617) 491-1850 X694
CHARLES L. BROOKS/ ABT ASSOCIATES INC./ 55 WHEELER STREET/ CAMBRIDGE MA 02139/ (617) 492-7100
JAMES STEINBERG/ 23/ DOT/TSC/ KENDALL SQUARE/ CAMBRIDGE MA 02142
BRYAN HOPKINS/ EKS/ 200 TRAPELO ROAD/ WALTHAM MA 02154/ (617) 893-3500 X277
LAWRENCE F. CRAM/ 64 BOWEN STREET/ NEWTON MA 02159
THOMAS M. ATWOOD/ 70 BARNSTABLE RD./ W. NEWTON MA 02165/ (617) 235-8171 X131
JOHN C. MILLER/ 105 CHERRY STREET/ W. NEWTON MA 02165/ (617) 272-7070 X160
FRED ElLEN STEIN/ 68 SPRING STREET/ WATERTOWN MA 02172/ (617) 924-2248
DAVID TAFFS/ 42 THIRD STREET/ NEWPORT RI 02840/ (401) 847-3770
ATTN: L.A.M.B.D.A./ BROWN UNIVERSITY/ BOX G/ PROVIDENCE RI 02912/ (401) 863-3162
READ T. FLEMING/ PROGRAM IN COMPUTER SCIENCE/ BROWN UNlVERSITY/ BOX F/ PROVIDENCE RI 02912/ (401) 863-3088
BETTY BUXTON/ NCA 1-3220/ SANDERS ASSOCIATES INC./ 95 CANAL STREET/ NASHUA NH 03060/ (603) 885-5314
MICHAEL MCKENNA/ TIME SHARE CORP./ BOX 683/ HANOVER NH 03755/ (603) 448-3838
WILLIAM J. VASILIOU JR./ COMPUTER SERVICES/ KINGSBURY HALL/ U OF NEW HAMPSHIRE/ DURHAM NH 03824/ (603) 862-2323
A. E. SAPEGA/ ENGINEERING DEPT./ TRINITY COLLEGE/ HARTFORD CT 06106/ (203) 527-3151 X202
TIM RAND/ P.O. BOX 98/ STORRS CT 06268
PAUL KOHLBRENNER/ 261 DUNK ROCK ROAD/ GUILFORD CT 06437/ (203) 453-9540
MICHAEL BEHAR/ 428 WINDY HILL RD./ ORANGE CT 06477/ (203) 878-7141
DICK OSGOOD/ YALE COMPUTER CENTER/ 175 WHITNEY CENTER/ NEW HAVEN GT 06520/ (203) 432-4080
RONA GURKEWITZ/ 181 WHITE STREET/ DANBURY CT 06810
DOUGLAS M. GRANT/ NATIONAL CSS/ 500 SUMMER STREET/ STAMFORD CT 06901/ (203) 327-9100
ROBERT KAST/ 350 BALDWIN ROAD APT. F4/ PARSIPPANY NJ 07054
HAL PACE/ KEARFOTT DIV. - DEPT. 5760/ SINGER CO./ 150 TOTOWA ROAD/ WAYNE NJ 07470/ (201) 256-4000 X3503
CHRISTOPHER J. HENRICH/ SOFTWARE DEVELOPMENT/ INTERDATA INC./ 106 APPLE STREET/ TINTON FALLS NJ 07724/ (201) 229-4040
FOREST VAN SISE SHAFER/ COMCON INC./ 504 U.S. ROUTE 130 AT HIGHLAND AVE./ CINNAMINSON NJ 08077
WILLIAM G. HUTCHISON JR./ N 191 PRINCETON ARMS/ CRANBURY NJ 08512/ (609) 443-6631
WILLIAM J. K. HARRINGTON/ 70 ~~IN BOULEVARD/ TRENTON NJ 08618
GEORGE B. DIAMOND/ DIAMOND AEROSOL CORP./ RD #1/ GLEN GARDNER NJ 08826
ATTN: CCIS LIBRARY HILL CENTER/ BUSCH CAMPUS/ RUTGERS UNIV./ p.O. BOX 879/ PISCATAWAY NJ 08854/ (201) 932-2296
JIM STEWART/ 195B PLEASANT VIEW ROAD/ PISCATAWAY .NJ 08854
RODERICK MONTGOMERY/ HEALTH PRODUCTS RESEARCH INC./ 3520 U.S. ROUTE 22/ SOMERVILLE NJ 08876/ (201) 534-4148
CHARLES HEDRICK/ COMPUTER SCIENCE DEPT. / RUTGERS UNIV. / HILL C ENTER/ NEW BRUNSWICK NJ 08903
DOUG FORSTER/ P.O. BOX 1027 UNIT AA/ APO NY 09098
WILLIAM HENRY/ 117 E. TENTH ST./ NEW YORK NY 10003/ (212) 673- 6944
NORMAN D. WHALAND/ 430 EAST 9TH STREET - APT. 15/ NEW YORK NY 10009
ROBERTO MINIO/ SPRINGER-VERLAG INC./ 175 FIFTH AVE/ NEW YORK Ny 10010/ (212) 477-8316
JON A. SOLWORTH/ 7 WEST 14TH ST APT 15A/ NEW YORK NY 10011/ (212) 243-2183
EDWARD R. FRIEDMAN/ CIMS/ NEW YORK UNIVERSITY/ 251 MERCER ST./ NEW YORK NY 10012/ (212) 460-7100/ (212) 460-7293
ANDREW P. VALENTI/ COURANT INST. OF MATHEMATICAL SCIENCE/ NEW YORK UNIV./ 251 MERCER ST./ NEW YORK NY 10012/ (212) 641-0274
RAMON TAN/ 305 E. 40TH ST. APT. 12W/ NEW YORK NY 10016/ (212) 682-1013
MARK STAHLMAN/ COMPUTRON INC./ 888 7TH AVENUE - 25TH FLOOR/ NEW YORK NY 10019
PAUL SPRECHER/ 241 WEST 77TH STREET/ NEW YORK NY 10024
DONALD WARREN/ 130 WEST 81ST STREET APT 7/ 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
LARRY ARONSON/ CENTER FOR COMPUTING ACTIVITIES/ COLUMBIA UNIVERSITY/ 612 W 115TH ST./ NEW YORK NY 10027/ (212) 280-2698
JERRY S. SULLIVAN/ PHILIPS LABORATORIES/ 345 SCARBOROUGH ROAD/ BRIARCLIFF MAN NY 10510/ (914) 762-0300
TIMOTHY P. ROBERTS/ KEEN INSTRUMENTS INC./ 111 BOWMAN AVE./ PORT CHESTER NY 10573/ (914) 939-0200
PAUL S. KLARREICH/ 2809 BEDFORD AVE./ BROOKLYN NY 11210/ (212) 859-1408
LYNN S. MARTINI DEPT. OF ENGLISH/ ST. JOHN'S UNIV./ GRAND CENTRAL AND UTOPIA PARKWAYS/ JAMAICA NY 11439/ (212) 969-8000 X387
M. WAITE/ FAZELTINE· CORP./ GREENLAWN NY 11740/ (516) 261-7000 X687

.,
IT1
to
:;:0

=

::t>
:;:0

-<

N
C>

11756
11794
11794
11797
12210
13201
13440
14072
14127
14226
14454
14850
15213
15213
15213
15461
15701
16057
17019
17837
18015
18015
18017
18042
18049
18938
19010
19044
19046
19085
19087
19101
19122
19151
19301
19335
19341
19438
19440
19711
19711
19898
19898
20006
20014
20014
20014
20016
20036
20041
20229
20375
20770
20770
20784
20855
21010
21045
21045
21045
21235
21793
22003
22042
22090

ROBERT SCHUTZ/ 93 MERIDIAN ROAD/ LEVITTOWN NY 11756
RICHARD B KIEBURTZ/ DEPT. OF COMPUTER SCI./ SUNY AT STONY BROOK/ STONY BROOK NY 11794/ (516) 246-5987/ (516) 246-7146
GENE ROLLINGS/ COMPUTER SCIENCE DEPT./ SUNY - STONY BROOK/ STONY BROOK NY 11794/ (516) 246-4383
PAUL ZILBER/ ONTEL CORP./ 250 CROSSWAYS PARK DRIVE/ WOODBURY Ny 11797/ (516) 364-2121
GARYO 0' SCHENECTADY/ 144 LANCASTER ST./ ALBANY NY 12210
J. DANIEL GERSTEN/ COMPUTED IMAGE ENG. - CSP 3-21/ GENERAL ELECTRIC CO./ SYRACUSE NY 13201/ (315) 456-7366
STEPHEN B. WATERS/ ROME SENTINEL COMPANY/ 333 W. DOMINICK STREET/ ROME NY 13440/ (315) 337-4000
LEO CHRZANOWSKI/ 67 WARD PARK ROAD/ GRAND ISLAND NY 14072
F. DOUGLAS ROBINSON/57 TANGLEWOOD WEST/ ORCHARD PARK NY 14127/ (716) 843-7142 (WORK)/ (716) 662-4093 (HOME)
STUART W. ROWLAND/ COMPUTER SCIENCE DEPT./ SUNY - BUFFALO/ 4226 RIDGE LEA ROAD/ AMHERST NY 14226/ (716) 831-1351
ANTHONY E. HOFFMAN/ MATHEMATICS DEPT. / SUNY-CAS/ GENESEO NY 14454/ (716) 243-3833
WILLIAM LYCZKO/ SOFTWARE DEVELOPMENT/ NCR CORPORATION/TERMINAL SYSTEMS/ 950 DANBY ROAD/ ITHACA NY 14850/ (607) 273-5310/ X251 X254
ATTN: EARL L. MOUNTS-COMP. SCI. LIBRARI E & S LIBRARY/ SCIENCE HALL/ CARNEGIE-MELLON UNIVERSITY/ PITTSBURGH PA 15213/ (412) 578-2426
DAVID B. GROUSE/ GRAPHIC ARTS TECHNICAL FOUNDATION/ 4615 FORBES AVE/ PITTSBURGH PA 15213
KEVIN WEILER/ SCHOOL OF URBAN AND PUBLIC AFFAIRS/ INSTITUTE OF PHYSICAL PLANNING/ CARNEGIE MELLON UNIV/ SCHENLEY PARK/ PITTSBURGH PA 15213
(412) 578-2177
RON MAHONI VIDEO LINK/ P.O. BOX 688/ MASONTOWN PA 15461/ (412) 583-7786
HOWARD E. TOMPKINS/ COMPUTER SCIENCE DEPT/ INDIANA UNIVERSITY OF PAl INDIANA PA 15701/ (412) 357-2524
PETER RICH ETTA/ 129A WEST WATER STREET/ SLIPPERY ROCK PA 16057/ (412) 794-3531
E. R. BEAUREGARD/ P.O. BOX 357/ DILlSBURG PA 17019
ATTENTION: MARJORIE HEINE/ FREAS-ROOKE COMPUTER CENTER/ BUCKNELL UNIVERSITY/ LEWISBURG PA 17837/ (717) 524-1436
DAVID B. ANDERSON/ DEPT. OF MATHEMATICS/ 14 CHRISTMAS-SAUCON/ LEHIGH UNIVERSITY/ BETHLEHEM PA 18015/ (215) 683-5086
CRAIG PAYNE/ LEHIGH UNIV./ P.O. BOX 22A/ BETHLEHnl PA 18015/ (215) 867-6367
ROBERT COLE/ 782 BARRYMORE LANE/ BETHLEHEM PA 18017
JOHN A. WEAVER/ ANPA - RESEARCH INSTlTUTE/ P.O. BOX 598/ EASTON PA 18042/ (215) 867-1085
JOHN W. IOBST/ 22 N. KEYSTONE AVE./ EMMAUS PA 18049/ (215) 965- 46 77
BILL CHESWICK/ DARIEN 15B / VILLAGE 2/ NEW HOPE PA 18938/ (215) 866-4491
DONALD B. KLEIN/ 145 LOWRY'S LANE/ ROSEHONT PA 19010
JAMES P. MCILVAINE IV/ BRIDGEPORT-TEXTRON/ 200 PRECISION RD./ HORSHAH PA 19044/ (215) 674-2700
DAN MORTON/ 701 WASHINGTON LANE/ JENKINTOWN PA 190461 (215) 885-2443/ (215) 895-2259
STEPHEN W. CHING/ DEPT OF ELECTRICAL ENGINEERING/ COMPUTER SCIENCE/ VILLANOVA UNIVERSITY/ VILLANOVA PA 19085/ (215) 527-2100 X631
MARK HIPPE/ GEOMETRIC DATA CORP./ 999 WEST VALLEY ROAD/ WAYNE PA 19087/ (215) 687-6550
G. KEVIN DOREN/ P.O. BOX 8191/ PHILADELPHIA PA 191011 (215) 963-0465/ (215) 963-0551
EARL RALEY/ COMPUTER ACTIVITY/ ACADEMIC SERVICES/ TEMPLE UNIV./ PHILADELPHIA PA 19122/ (215) 787-8527
CLIFTON CHANG-CHAO TING/ 879 WYNNEWOOD ROAD - 1ST FLOOR/ PHILADELPHIA PA 19151/ (215) 878-7231
DAVID M. ADAMS/ CSG/T/ BURROUGHS CORPORATION/ P.O. BOX 203/ PAOLI PA 19301/ (215) 648-2000
TOM KELLY/ 58-B MEADOWLAKE DRIVE/ DOWNINGTOWN PA 19335/ (215) 269-3626
JEFFREY D. STROOMER/ 224 HERITAGE LANE/ EXTON PA 19341/ (216) 363-1948
DONALD A. KEFFER/ 252 MANOR ROAD/ HARLEYSVILLE PA 19438
V. LALITA RAO/ HATFIELD VILLAGE APARTMENTS UTl-5/ HATFIELD PA 19440/ (215) 865-6448
JOHN D. EISENBERG/ COMPUTING CENTRE/ SMITH HALL/ U OF DELAWARE/ NEWARK DE 19711/ (302) 738-8441 X57 (OFFICE)/ (302) 453-9059 (HOME)
WILLIAH s. PAGE/ 23 OLD MANOR ROAD/ NEWARK DE 19711/ (302) 731- 5988
C. E. BRIDGE/ ENGINEERING DEVELOPMENT LAB/ E. I. DU PONT DE NE t10URS AND CO./ 101 BEECH STREET/ WIlliINGTON DE 19898/ (302) 774-1731
STEPHEN C. SCHWARM/ E.I. DU PONT DE NEMOURS CO./ 101 BEECH ST./ WIlliINGTON DE 19898/ (302) 774-1669
KENNETH R. JACOBS/ FEDERAL SYSTEMS DIVISION/ ADPNETWORK SERVI CES / 2011 EYE STREET NW/ WASHINGTON DC 20006/ (202) 872-0580
KEITH E. GORLEN/ 2017 BLDG.12A/ NATIONAL INST. OF HEALTH/ BETHESDA MD 20014/ (301) 496-5361
TERRY P. MEDLIN/ SCIENTIFIC RESEARCH UNIT - DPSA/ B23 BLDG 30/ NATIONAL INSTITUTE OF DENTAL HEALTH/ BETHESDA MD 20014/ (301) 496-1621
JOHN M. SHAWl BLDG 36 / ROOM 2A29/ NATIONAL INSTITUTES OF HEALTH/ BETHESDA MD 20014/ (301) 496-3204
JOSEPH P. JOHNSON/ 3520 QUEBEC ST. NWI WASHINGTON DC 20016/ (202) 362-8523
MARGERY AUSTIN/ THE URBAN INSTITUTE/ 2100 M STREET NW/ WASHINGTON DC 20036/ (202) 223-1950 X486
DAVID AULT/ COMPUTER SCIENCE/ VPI AND sui P.O. BOX 17186/ WASHINGTON DC 20041/ (703) 471-4600
STEVE O'KEEFE/ 7328/ U.S. CUSTOMS SERVICE/ 1301 CONSTITUTION AVE. N.W./ WASHINGTON DC 20229/ (202) 566-2974
PETER A. RIGSBEE/ CODE 5494/ NAVAL RESEARCH LABORATORY/ WASHINGTON DC 20375/ (202) 767-3318
LEO DAVIS/ 40 LAKESIDE DRIVE/ GREENBELT MD 20770
CAROL B. HOWELL/ P.O. BOX 326/ GREENBELT MD 20770
EDWARD D. ROTHE/ 7101 VARNUH ST/ LANDOVER HILLS MD 20784
BOB ROGERS/ 18625 AZALEA DRIVE/ DERWOOD MD 20855
PAUL H. BROOME/ BIOPHYSICS BRANCH/ CHn1ICAL SYSTEMS LAB/ RESEARCH DIVISION/ PROVING GROUND/ ABERDEEN lID 21010/ (301) 671-3489
JOHN FRINK/ 5304 THUNDER HILL ROAD/ COLUHBIA MD 21045/ (202) 394-2396
RICHARD LLEWELLYN/ 5355 RED LAKE/ COLillffiIA MD 21045/ (301) 765-4570
RAINER F. MCCOWN/ MCCOWN COMPUTER SERVICES/ 9537 LONG LOOK LANE/ COLUHBIA MD 21045/ (301) 730-0379
LESTER SACHS/ OPERATIONS/ HS 3-0-25/ SOCIAL SECURITY ADMINISTRATION/ 6401 SECURITY BOULEVARD/ BALTIMORE MD 21235
PAUL C. BERGMAN/ DIGITAL SYSTEMS CORP./ P.O. BOX 396/ WALKERSVILLE MD 21793/ (301) 845-4141
ROBERT C. JANKU/ 5112 ALTHEA DRIVE/ ANNANDALE VA 22003/ (703) 978-8384
ROBERT LEE SHARP/ P.O. BOX 2170/ FALLS CHURCH ITA 22042
HENRY DAVIS/ ACUITY SYSTEMS INC./ 11413 ISAAC NEWTON SQUARE/ RESTON VA 22090/ (703) 471-4700 X243

""""0

:I>
C/)

n

,:r>
z

rn
:::E:
C/)

=!:!:
f-'
f-'

-n
rn
t:Ij

;::0

=

:r>

=
-<

22091
22101
22101
22152
22180
22209
22901
22901
22903
23185
23508
23665
23669
27409
27607
27709
30303
30303
30303
30310
30339
32303
32306
32901
32901
32905
32935
33313
33313
35486
35805
37130
37916
40205
40217
43403
43403
43403
44106
44106
44107
44115
44116
44119
44691
45036
45036
46375
46530
47401
47401
47805
47907
47907
47907
48100
48104
48104
48106
48824
48824
48824
48824
49008
50011
52240

JAMES K. MOORE/ 12345 COLERAINE COURT/ RESTON VA 22091/ (703)437-2338
H. F. HESSION/ ADVANCED RECORD SYSTEMS ENGINEERING/ WESTERN UNION/ 7916 WEST PARK DRIVE/ MCLEAN VA 22101
ROBERT L. STEELE 11/ INCO. INC./ 7916 WEST PARK DRIVE/ MCLEAN VA 22101/ (703) 893-4330
MARK S. WATERBURY/ 8358 L DUNHAM CT./ SPRINGFIELD VA 22152/ (703) 451-8255
TRUMAN C. PEWITT/ 8507 COTTAGE STREET/ VIENNA VA 22180/ (703) 821-6321/ (703) 573-3192
WILLIAM A. WHITAKER/ DARPA/ 1400 WILSON BLVD./ ARLINGTON VA 22209/ (202) 694-1139
ROBERT A. GIBSON/ WEST LEIGH/ 2380 KINGSTON RD/ CHARLOTTESVILL VA 22901/ (804) 977-3233
STEPHEN F. MERSHON/ SCHOOL OF ENGINEERING--DAMACS/ AERO-MATH BLDG./ UNIV. OF VIRGINIA/ CHARLOTTESVILL VA 22901/ (804) 924-3917
ATTN: J. F. MCINTYRE - LIBRARIAN/ COMPUTING CENTER/ GILMER HALL/ UNIV OF VIRGINIA/ CHARLOTTESVILL VA 22903/ (804) 924-3731
MICHAEL K. DONEGAN/ DEPT. OF MATH. & COMPo SCIENCE/ COLLEGE OF WILLIAM & MARY/ WILLIAMSBURG VA 23185/ (804) 253-4481
FRANCES L. VAN SCOY/ DEPT. OF MATH AND COMPUTING SCIENCES/ OLP DOMINION UNIV./ NORFOLK VA 23508/ (804) 489-6525
JOHN C. KNIGHT/ LANGLEY RESEARCH CENTER/ M/S 125A/ NASA/ HAMPTON VA 23665/ (804) 827-3875
JOHNCLARSON/ 303 TENDERFOOT COURT/ HAMPTON VA 23669
TOM TYSON/ COMPUTER LABS/ 505 EDWARDIA DRIVE/ GREENSBORO NC 27409/ (919) 292-5427
DONALD L. PARCE/ BUSINESS APPLICATIONS SYSTEMS INC./ 7334 CHAPEL HILL ROAD/ RALEIGH NC 27607/ (919) 851-8512
W. J. MEYERS/ DATA GENERAL CORP./ RESEARCH TRIANGLE PARK/ TRIANGLE PARK NC 27709
ROBERT N. MACDONALD/ INFORMATION SYSTEMS DEPT./ GEORGIA STATE UNIV./ UNIVERSITY PLAZA/ ATLANTA GA 30303/ (404) 658-3880
DARRELL PREBLE/ COMPUTER CENTER USER SERVICES/ GEORGIA STATE UNIVERSITY/ ATLANTA GA 30303
MORRIS W. ROBERTS/ DEPT. OF INFORMATION SYSTEMS/ GEORGIA STATE UNIV./ UNIVERSITY PLAZA/ ATLANTA GA 30303/ (404) 658-3882
JOE CELKO/ P.O. BOX 11023/ ATLANTA GA 30310/ (404) 753-7993
DOUGLAS MANN/ SCIENCE APPLICATIONS INC./ 2028 POWERS FERRY ROAD _ SUITE 260/ ATLANTA GA 30339/ (404) 955-2663
C. EDWARD REID/ RT. 7 BOX 1257/ TALLAHASSEE FL 32303/ (904) 488-2451
JOHN H. BOLSTAD/ DEPT. OF MATHEMATICS/ FLORIDA STATE UNIV./ TALLAHASSEE FL 32306/ (904) 644-2580
GEORGE E. HAYNAM/ SYSTEMS DIVISION/ HARRIS CORP./ P.O. BOX 2080/ MELBOURNE FL 32901/ (904) 378-8118
TOM SPURRIER/ ELECTRONICS SYSTEMS DIVISION/ HARRIS CORP./ P.O. BOX 37/ MELBOURNE FL 32901/ (305) 727-4000
DENIS KERMICLE/ WOODLAKE DRIVE EAST APT. D-130/ PALM BAY FL 32905/ (305) 725-2417
ROBERT L. CHEEZEM JR./ 2192 CHERYL CT./ MELBOURNE FL 32935/ (305) 254-6522
S. HAYES/ DEVELOPMENT ENGR. LIBRARY/ SYSTEMS ENGR. LABS/ 6901 W. SUNRISE BLVD./ FT.LAUDERDALE FL 33313/ (305) 587-2900
STEVE MATUS/ MARKET PLANNING AND RESEARCH/ SYSTEMS ENGINEERING LABS/ 6901 W. SUNRISE BLVD./ FT.LAUDERDALE FL 33313/ (305) 587-2900
DONALD B. CROUCH/ DEPT.OF COMPUTER SCIENCE/ UNIV OF ALABAMA/ p.O. BOX 6316/ UNIVERSITY AL 35486/ (205) 348-6363
MIKE D. PESSONEY/ ANALYSTS INTERNATIONAL CORP./ 2317 BOB WALLACE AVE. SE/ HUNTSVILLE AL 35805/ (205) 533-4220
SAMUEL T. BAKER/ 1310 STONEWALL BLVD./ MURFREESBORO TN 37130/ (615) 896-3362 (HOME)/ (615) 741-3531 (OFFICE)
ATTENTION: CHARLES PFLEEGER/ COMPo SCI. DEPT./ U OF TENNESSEE/ KNOXVILLE TN 37916/ (615) 974-5067
A. CHARLES BUCKLEY/ DATA/INFORMATION SYSTEMS/ URBAN STUDIES CENTER/ ALTA VISTA ROAD - GARDENCOURT/ LOUISVILLE KY 40205/ (502) 588-6626
MICHAEL P. ROBINSON/ AMERICAN DATA MANAGEMENT SYSTEMS/ 2434 CRITTENDEN DRIVE - SUITE 200/ LOUISVILLE KY 40217/ (502) 637-9765
FRANK J. BATES JR./ OFFICE OF COMPUTATIONAL SERVICES/ BOWLING GREEN STATE UNIV./ BOWLING GREEN OH 43403/ (419) 372-2911
JOHN M. HEMPHILL/ DEPT. OF COMPUTER SCI./ BOWLING GREEN STATE UNIV./ BOWLING GREEN OH 43403/ (419) 372-2337
RICHARD T. THOMAS/ DEPT. OF COMPUTER SCIENCE/ BOWLING GREEN STATE UNIV./ BOWLING GREEN OH 43403/ (419) 372-2339
R. B. LAKE/ BIOMETRY/ WEARN BUILDING/ CASE WESTERN UNIV HOSPITALS/ CLEVELAND OH 44106/ (216) 444-3491
TOM NUTE/ SYS. & COMPUTER ENG./ CRAWFORD HALL/ CASE WESTERN RESERVE UNIV./ CLEVELAND OH 44106/ (216) 368-2800
STEVEN B. HALL/ 1599 ORCHARD GROVE/ LAKEWOOD OH 44107/ (216) 521-4178
ARTHUR C. DARTT/ CHEMISTRY DEPT./ CLEVELAND STATE UNIV./ EUCLID AT EAST 24TH STREET/ CLEVELAND OH 44115/ (216) 687-2473
BILL SHANNON/ 21345 HILLIARD/ ROCKY RIVER OH 44116/ (216) 331-8733
DAVID PESEC/ 21030 MILLER/ EUCLID OH 44119/ (216) 486-4716
ANN C. JOHNSTON/ RD 6/ HAPPY VALLEY RD./ WOOSTER OH 44691
ATTN: BETTE BOLLING-LIBRARIAN/ TECHNICAL INFORMATION CTR-ELECTRONICS/ CINCINNATI MILACRON INC./ LEBANON OH 45036/ (513) 494-1200
TOM MORAN/ PROCESS CONTROLS DIVISION/ CINCINNATI MILACRON/ MAS ON RD & RT 1148/ LEBANON OH 45036
PHILIP T. HODGE/ 346 KENNEDY/ SCHERERVILLE IN 46375
JOE TORZEWSKI/ 51625 CHESTNUT ROAD/ GRANGER IN 46530/ (219) 272-4670
ANNA BUCKLEY/ WHUBEL COMPUTING CENTER/ INDIANA UNIV./ BLOOMINGTON IN 47401/ (812) 337-1911
ANTHONY J. SCHAEFFER/ 3510 DUNSTAN DR./ BLOOMINGTON IN 47401/ (812) 337-9137
ROBERT L. ARGUS/ 2603 THOMAS AVE. APT 4/ TERRE HAUTE IN 47805
ALLAN M. SCHWARTZ/ DEPT. OF COMPUTER SCIENCES/ MATH SCIENCES BUILDING/ PURDUE UNIVERSITY/ WEST LAFAYETTE IN 47907/ (317) 743-2473
EDWARD F. GEHRINGER/ DEPT. OF COMPUTER SCIENCE/ MATH SCIENCES BU'ILDING/ PURDUE UNIVERSITY/ W. LAFAYETTE IN 47907
SAUL ROSEN/ COMPUTING CENTER/ PURDUE UNIV./ W. LAFAYETTE IN 47907/ (317) 494-8235
MARK HERSEY/ 1114 MAIDEN LANE COURT APT. 112/ ANN ARBOR MI 48100/ (313) 994-3934/ (517) 355-1764 (OFFICE)
GREG WINTERHALTER/ HORIBA INSTRUMENTS/ 3901 VARSITY DRIVE/ ANN ARBOR MI 48104/ (313) 973-2171
KARL L. ZINN/ CTR. FOR RESEARCH ON LEARNING & TEACHI/ UNIV. OF MICHIGAN/ 109 EAST ~MDISON STREET/ ANN ARBOR MI 48104/ (313) 763-4410/ 763-0158
CHARLES G. MOORE/ ADP NETWORK SERVICES/ 175 JACKSON PLAZA/ ANN ARBOR MI 48106/ (313) 769-6800
JOHN B. EULENBERG/ COMPo SCI. DEPT./ MICHIGAN STATE U/ EAST LANSING MI 48824/ (517) 353-0831
HARRY G. HEDGES/ DEPT. OF COMPo SCI./ 400 COMPUTER CENTER/ MICHIGAN STATE UNIV/ EAST LANSING MI 48824/ (517) 353-6484
STEVEN L. HUYSER/ USER INFO. CENTER/ 313 COMPUTER CENTER/ 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
JACK R. MEAGHER/ COMPUTER SCIENCE AND MATHEMATICS/ WESTERN MICHIGAN UNIV./ KALAMAZOO MI 49008/ (616) 383-0095
AHMED KASSEM/ COMPUTATION CENTER/ 104 COMPUTER SCIENCE/ IOWA STATE UNIV./ AMES IA 50011/ (515) 294-8424
G. STEPHEN HIRST/ 930 FAIRCHILD/ IOWA CITY IA 52240/ (319) 351,-5253 (HOME)/ (319) 353-3935 (WORK)

"fT1
b:I
;:0

=

:J>
;:0

-<
f-'
l.O

"

00

N
N

52242
52302
52402
53149
53201
53219
53705
53706
53719
55057
55057
55066
55105
55108
55112
55112
55112
55165
55337
55343
55343
55391
55404
55404
55413
55414
55414
55418
55420
55427
55427
55429
55435
55436
55437
55455
55455
55455
55455
55455
55455
55455
55455
55455
55455
55455
56267
56301
56569
57069
58201
60148
60181
60201
60439
60532
60652
60657
60660
61801
61801
61801
61820
61820
62704

DONALD L. EPLEY/ DEPT. OF COMPUTER SCIENCE/ UNIV. OF IOWA! IOWA CITY IA 52242/ (319) 353-5605
DENNIS SUTHERLAND/ 2835 25TH AVE./ MARION IA 52302/ (319) 395-4728
JAMES C. COZZIE/ 254 NORTHPOINTE N.E. - APT. 322/ CEDAR RAPIDS IA 52402
MICHAEL A. BEAVER/ ROUTE 3 BOX 271B/ MUKWONAGO WI 53149/ (414) 728-5531 X249
RICHARD E. NEUBAUER/ JOHNSON CONTROLS INC./ P.O. BOX 423/ MILWAUKEE WI 53201/ (414) 276-9200
JOHN G. DOBNICK/ 3171 S. 83 ST./ MILWAUKEE WI 53219/ (414) 963-5727
EDWARD K. REAM/ 508 FARLEY AVE. - APT. 5/ MADISON WI 53705
LARRY E. TRAVIS/ COMPUTER SCIENCE DEPT./ UNIV OF WISCONSIN - MADISON/ 1210 WEST DAYTON STREET/ MADISON WI 53706/ (608) 262-7971/ (608) 262-1204
LEN LINDSAY/ 5150 ANTON DR. #212/ MADISON WI 53719
CARL HENRY/ COMPUTER CENTER/ CARLETON COLLEGE/ NORTHFIELD MN 55057/ (507) 645-4431 XS04
TIMOTHY W. HOEL/ ACADEMIC COMPUTER CENTER/ ST. OLAF COLLEGE/ NORTHFIELD MN 55057/ (507) 663-3097
TERRY MYHRER/ 1324 EAST AVENUE/ RED WING MN 55066
ATTN: COMPUTING SERVICES/ MACALESTER COLLEGE/ 1600 GRAND AVE/ ST. PAUL MN 55105/ (612) 647-6171
JAMES KREILICH/ 1408 ALBANY AVE./ ST. PAUL MN 55108/ (612) 644-1375
ED KATZ/ 3564 N. SNELLING/ ARDEN HILLS MN 55112/ (612) 636-3472
W. B. CHAPIN/ ARB 242/ CONTROL DATA CORP./ 4201 N. LEXINGTON/ ST. PAUL MN 55112/ (612) 483-4673
MARK RUSTAD/ 585 HARRIET AVE #213/ ST. PAUL MN 55112/ (612) 483-0589/ (612) 376-1143 (WORK)
ROBERT A. LAWLER/ MS U2M23/ UNIVAC/ P.O. BOX 3525/ ST. PAUL MN 55165/ (612) 456-3109
LARRY w. SMITH/ 125 RIVER WOODS LN./ BURNSVILLE MN 55337
ROBERT G. LANGE/ MN 11-2120/ HONEYWELL INC./ 600 2ND ST. NE/ HOPKINS MN 55343/ (612) 542-4925
ROSS D. SCHMIDT/ MS MNll-2120/ HONEYWELL INC./ 600 2ND STREET NE/ HOPKINS MN 55343/ (612) 542-6741
GREG KEMNITZ/ 1539 CLARE LANE/ WAYZATA MN 55391/ (612) 473-6123
JON G. KLASEN/ 911 22ND AN. SO. 11375/ MINNEAPOLIS MN 55404/ (612) 339-4170
RICK L. MARCUS/ 1609 11TH AVE. S./ MINNEAPOLIS MN 55404/ (612) 339-1638
BELLE P. SHENOY/ MS MN17-3670/ HONEYWELL INC./ 2600 RIDGEWAY ROAD/ MINNEAPOLIS MN 55413/ (612) 378-5418
ATTN: KHK/ 330 11TH AVE. S.E./ MINNEAPOLIS MN 55414/ (612) 331-2133
WALT PERKO/ 727 15TH AVE. S.E./ MINNEAPOLIS MN 55414/ (612) 331-6984
BOB PETERSON/ 2415 POLK ST. NE/ MINNEAPOLIS MN 55418/ (612) 789-2393
JOHN ALSTRUP/ INTERDATA CORP./ 10800 LYNDALE AVE. SOUTH - SUITE 130/ BLOOMINGTON MN 55420/ (612) 884-1757
HUGO MEISSER/ 3021 WISCONSIN AVE. N./ CRYSTAL MN 55427/ (612) 482-3052
DAVID PERLMAN/ 8309 NORTHWOOD PKWY./ NEW HOPE MN 55427/ (612) 546-2154
DAVID L. PETERSON/ 6301 UNITY AVE. NO./ BROOKLYN CTR MN 55429
DANIEL E. GERMANN/ 6813 BROOK DRIVE/ EDINA MN 55435/ (612) 941-1082
JOHN FITZSIMMONS/ 5025 YVONNE TERRACE/ EDINA MN 55436/ (612) 926-8954
DENNIS NICKOLAI/ MNAOZA/ CONTROL DATA CORPORATION/ 5001 W. 80TH ST./ BLOOMINGTON MN 55437/ (612) 830-6903
ATTENTION: BOB JARVIS/ SCH. OF DENTISTRY/CLINICAL SYS. DIV./ 8-440 HEALTH SCIENCE UNIT A/ U OF MINNESOTA/ EAST BANK/ MINNEAPOLIS MN 55455
(612) 376-4131
KEVIN FJELSTED/ UNIVERSITY COMPUTER CENTER/ 227 EXP ENGR/ U OF MINNESOTA/ EAST BANK/ MINNEAPOLIS MN 55455/ (612) 373-4181
PAULETTE D. GENES/ UNIVERSITY COMPUTER CENTER/ 227 EXP. ENGR./ UNIV. OF MINNESOTA/ EAST BANK/ MINNEAPOLIS MN 55455/ (612) 376-5262
SARA K. GRAFFUNDER/ UNIVERSITY COMPUTER CENTER/ 227 EXP. ENGR./ U OF MINNESOTA/ MINNEAPOLIS MN 55455/ (612) 376-1637
THEA D. HODGE/ UNIVERSITY COMPUTER CENTER/ 227 EXP. ENGR./ UNIV OF MINNESOTA/ EAST BANK/ MINNEAPOLIS MN 55455/ (612) 373-4599
DAN LALIBERTE/ UNIVERSITY COMPUTER CENTER/ 227 EXP. ENGR./ U OF MINNESOTA/ EAST BANK/ MINNEAPOLIS MN 55455/ (612) 373-4181
MICHAEL PRIETULA/ MGMT. SCIENCES DEPT./ 773 BA/ U OF MINNESOTA/ WEST BANK/ MINNEAPOLIS MN 55455/ (612) 376-7506
STEVEN A. REISMAN/ UNIVERSITY COMPUTER CENTER/ 227 EX/ UNIV OF MINNESOTA/ EAST BANK/ MINNEAPOLIS MN 55455/ (612) 376-1762
J. B. ROSEN/ 114 LIND HALL/ U OF MINNESOTA/ EAST BANK/ MINNEAPOLIS MN 55455/ (612) 373-0133
TIMOTHY J SALOl UNIVERSITY COMPUTER CENTER/ LAUDERDALE/ U OF MINNESOTA/ MINNEAPOLIS MN 55455/ (612) 376-5607
G. MICHAEL SCHNEIDER/ C.SCI. DEPT./ 114 LIND HALL/ U OF MINNESOTA/ EAST BANK/ MINNEAPOLIS MN 55455/ (612) 373-7582
ANDY LOPEZ/ COMPUTER CENTER/ U OF ~ITNNESOTA - MORRIS/ MORRIS MN 56267/ (612) 589-1665 X321
R. WARREN JOHNSON/ DEPT. OF MATH AND COMPo SCI./ MS-149/ ST. CLOUD STATE U/ ST. CLOUD MN 56301/ (612) 255-2147
PAUL J. WOZNIAK/ R. R. 1/ OGEMA MN 56569/ (612) 376-1137
JOHN LUSHBOUGH/ COLLEGE OF ARTS & SCIENCES/ UNIV. OF SOUTH DAKOTA/ VERMILLION SD 57069/ (605) 677-5221
CATHLINE S. HILLEY/ COMPUTER CENTER/ UNIV. OF NORTH DAKOTA/ p.O.BOX 8218 UNIVERSITY STATION/ GRAND FORKS ND 58201/ (701) 777-3171
ROBERT E. NOVAK/ 21 W 551 NORTH AVE. APT. 123/ LOMBARD IL 60148/ (312) 629-3512
STEVEN A. VERE/ 1635 S. MICHIGAN AVE. APT. 307/ VILLA PARK IL 60181/ (312) 627-2965
ARNOLD LAU/ COMPUTER SCIENCE DEPT./ NORTHWESTERN UNIV./ EVANSTON IL 60201/ (312) 463-2694
ATTENTION: J. M. KNOCK/ BLDG 203-C110/ ARGONNE NATIONAL LABORATORY/ 9700 SOUTH CASS AVENUE/ ARGONNE IL 60439/ (312) 739-7711
TERRY E. WEYMOUTH/ 4702 BEAU BIEN LANE EAST/ LISLE IL 60532
TONY Ctll1IEL/ 3900 WEST 84TH PLACE/ CHICAGO IL 60652
ROBERT D. GUSTAFSON/ SIMULATION SPECIALISTS INC./ 609 WEST STRATFORD PLACE/ CHICAGO IL 60657
JON SINGER/ 1540 W. ROSEMONT #3E/ CHICAGO IL 60660/ (312) 262-8545
ATTENTION: MIKE WILDE - CONSULTING OFF/ COMPUTING SERVICES OFFICE/ 138 DIGITAL COMPUTER LAB/ U OF ILLINOIS/ URBANA IL 61801/ (217) 333-6133
BOB LIDRAL/ 406 EAST GREEN STREET - APT. 104/ URBANA IL 61801/ (217) 367-5372
M. D. MICKUNAS/ 297 DeL/ U OF ILLINOIS/ URBANA IL 61801/ (217) 333-6351
ATTN: L. LAWRIE/ CERL - SOC/ U.S. ARMY/ P.O. BOX 4005/ CHAMPAIGN IL 61820/ (217) 352-6511
PETER DEWOLF/ 310 W. EUREKA/ CHAMPAIGN IL 61820/ (217) 356-1548 (HOME)/ (217) 333-8252 (WORK)
MIKE HARRIS/ APT. 4/ 309 WEST EDWARDS/ SPRINGFIELD IL 62704/ (217) 789-7669 (HOME)/ (217) 782-0014 (WORK)

.,
IT1
to
;;0

=

:t>
:::0

-<
I-'
lD
""'-J

co

62901
63188
64108
64108
64108
65201
65401
66045
66045
66045
66045
66506
67401
68154
70118
70504
70803
71201
72554
73019
73019
73019
74102
74145
75023
75062
75080
75081
75081
75229
75235
75275
75961
76012
77005
77005
77027
77043
77341
77801
77843
78284
78712
78731
78758
79409
79409
79601
80004
80204
80303
80303
80309
83316
83639
84112
84112
84112
84112
85001
85016
85282
87106
87106
87115

JAMES W. BUTLER/ COMPUTER SERVICES/ WHAM BLDG./ SOUTHERN ILLINOIS UNIV./ CARBONDALE IL 62901/ (618) 453-4361
JOHN K. MCCANDLISS/ ATTN: DRXAL-TF(JOHN K. MCCANDLISS)/ ALMS A/ P.O. BOX 1578/ ST. LOUIS MO 63188/ (314) 268-5361/ (314) 268-5362
LARRY D. LANDIS/ UNITED COMPUTING SYSTEMS/ 2525 WASHINGTON/ KANSAS CITY MO 64108/ (816) 942-6063
JEFFERY M. RAZAFSKY/ UNITED COMPUTING SYSTEMS INC./ 500 W. 26TH STREET/ KANSAS CITY MO 64108/ (816) 221-9700
ROBERT R. TEISBERG/ UNITED COMPUTING SYSTEMS/ 2525 WASHINGTON/ KANSAS CITY MO 64108/ (816) 221-9700 X431
DIANE L. KRAMER/ CAMPUS COMPUTING CENTER/ UNIV. OF MISSOURI-COLUMBIA/ 100 LEFEVRE/ COLUMBIA MO 65201/ (314) 882-6382
HOWARD D. PYRON/ 312 MATH - COMPo SCIENCE/ UNIV OF MISSOURI - ROLLA/ ROLLA MO 65401/ (314) 341-4495
JIM ARNOLD/ COMPUTER SCIENCE DEPT./ 18 STRONG HALL/ KANSAS UNIV./ LAWRENCE KS 66045/ (913) 864-4482
CHARLES J. BANGERT/ ACADEMIC COMPUTER CENTER/ UNIVERSITY OF KANSAS/ P.O. DRAWER 2007/ LAWRENCE KS 66045/ (913) 864-4291
STEVEN S. MUCHNICK/ DEPARTMENT OF COMPUTER SCIENCE/ 18 STRONG HALL/ UNIV OF KANSAS/ LAWRENCE KS 66045/ (913) 864-4482
GREGORY F. WETZEL/ DEPARTMENT OF COMPo SCI./ 18 STRONG HALL/ UNIVERSITY OF KANSAS/ LAWRENCE KS 66045/ (913) 864-4482
ALAN E. SKIDMORE/ COMPUTER SCIENCE DEPT./ KANSAS STATE UNIV./ MANHATTAN KS 66506/ (913) 532-6350
KEARNEY HILL/ 857 NAVAJO/ SALINA KS 67401/ (913) 825-2971
JERRY L. RAY/ 4540 SOUTH 84TH STREET/ OMAHA NE 68154/ (402) 592-3520
DANIEL B. KILLEEN/ COMPUTER LAB/ RICHARDSON BLDG./ TULANE UNIVERSITY/ 6823 ST. CHARLES AVE/ NEW ORLEANS LA 70118/ (504) 865-5631
DAVID LANDSKOV/ UNIV OF SOUTHWESTERN LOUISIANA/ USL BOX 4-4154/ LAFAYETTE LA 70504/ (318) 233-7949
K. P. LEE/ DEPT. OF COMPo SCI./ 102 NICHOLSON/ LOUISIANA STATE UNIVERSITY/ BATON ROUGE LA 70803/ (504) 388-1495
KENNETH R. DUCKWORTH/ FORD BACON AND DAVIS/ 3901 JACKSON STREE T/ MONROE LA 71201
DAN REED/ BOX 22/ MAMMlTH SPRING AR 72554
RICHARD V. ANDREE/ MATH DEPT./ UNIV OF OKLAHOMA/ NORMAN OK 73019/ (405) 325-3410
R. A. MORRIS/ MATH DEPT/ UNIV OF OKLAHOMA/ NORMAN OK 73019/ (405) 325-3391
JAMES D. WHITE/ COMPUTING SERVICES/ UNIV. OF OKLAHOMA/ 1610 NEWTON DRIVE/ NORMAN OK 73019/ (405) 325-1882
KENNETH R. DRIESSEL/ AMOCO RESEARCH/ P.O. BOX 591/ TULSA OK 74102
CONRAD SUECHTING/ DATA GENERAL CORP./ 9726 E. 42ND ST. SUITE 200/ TULSA OK 74145
ROGER R. BATE/ 3428 MISSION RIDGE/ PLANO TX 75023/ (214) 238-3 052
GRANT COLVIN/ MANAGEMENT SHARES INC./ 2121 WEST AIRPORT FREEWAY - SUITE 660/ IRVING TX 75062/ (214) 255-7121
E. J. SAMMONS/ M/S 406-246/ ROCKWELL INTERNATIONAL/ 1200 N. ALMA/ RICHARDSON TX 75080/ (214) 690-5802
FRANK DUNN/ 1912 E. SPRING VALLEY ROAD/ RICHARDSON TX 75081/ (214) 231-3423
GEORGE LIGLER/ 626 GOODWIN DR./ RICHARDSON TX 75081/ (214) 238-5311
DAVID E. BREEDING/ HARRIS DATA COHN DIV/ 11262 INDIAN TRAIL/ DALLAS TX 75229/ (214) 620-4294
W. J. PERVIN/ REGIONAL COMPUTER CENTER/ UNIV. OF TEXAS-DALLAS/ 5601 MEDICAL CENTER DRIVE/ DALLAS TX 75235/ (214) 688-2383
JANET TAYLOR/ USER SERVICES/ COMPUTER CENTER/ SOUTHERN METHODIST UNIVERSITY/ P.O. BOX 262/ DALLAS TX 75275/ (214) 692-2900
JESSE D. MIXON/ DEPT. OF ACCOUNTING/ STEPHEN F. AUSTIN STATE UNIV/ P.O. BOX 3005 SFA STATION/ NACOGDOCHES TX 75961/ (713) 569-3105/ 569-2508
ROSS F. HOUSHOLDER/ 1725 BROOKS DRIVE/ ARLINGTON TX 76012/ (817) 461-1149
JOHNNIE BUZEK JR./ SOFTWARE RESOURCES/ P.O. BOX 25210/ HOUSTON TX 77005/ (713) 521-0366
THOMAS E. SHIELDS/ SOFTWARE RESOURCES/ 2715 BISSONNET _ SUITE 212/ HOUSTON TX 77005/ (713) 521-0366
CHARLES L. HETHCOAT 111/ C/O PIPELINE TECHNOLOGISTS INC./ 5251 WESTHElMER P.O. BOX 22146/ HOUSTON TX 77027/ (713) 622-3456 X334 (WORK)
(713) 626-7737 (HOME)
JOHN EARL CRIDER/ 2918 KEVIN LANE/ HOUSTON TX 77043/ (713) 241- 4501
EASTON BEYMER/ SAM HOUSTON STATE UNIV./ P.O. BOX 2821/ HUNTSVILLE TX 77341
CHARLES MATTAIR/ AGENCY RECORDS CONTROL/ P.O. BOX 1009/ BRYAN TX 77801/ (713) 693-6122 X253
uno POOCH/ INDUSTRIAL ENGINEERING DEPT./ TEXAS A & M UNIV./ COLLEGE ST4TIO TX 77843/ (713) 845-5531
MIKE GREEN/ DATAPOINT CORPORATION/ 9725 DATAPOINT DRIVE/ SAN ANTONIO TX 78284/ (512) 699-7345
TOM KEEL/ COMPUTATION CENTER/ UNIV. OF TEXAS - AUSTIN/ AUSTIN TX 78712/ (512) 471-3242
DAVID W. HOGAN/ 4312 FAR WEST BLVD/ AUSTIN TX 78731/ (512) 258-7837
WILLIAM L. COHAGAN/ SUITE 211/ S/B/P &.C ASSOCIATES/ 8705 SHOAL CREEK BLVD./ AUSTIN TX 78758/ (512) 458-2276
ATTN: COMPUTER CENTER/ TEXAS TECH UNIV./ P.O. BOX 4519/ LUBBOCK TX 79409
LEONARD H. WEINER/ DEPT. OF MATH AND COMPo SCI./ TEXAS TECH. UNIV/ P.O. BOX 4319/ LUBBOCK TX 79409/ (806) 742-2571
JOHN TUCKER/ 628 E. N. 16TH ST. / ABILENE TX 79601/ (915) 698-1 605
RAYNER K. ROSICH/ 7031 PIERSON ST./ ARVADA CO 80004/ (303) 499-1000 X3109 (WORK)/ (303) 421-0425 (HOME)
GERHARDT C. CLEMENTSON/ DEPT. OF COMPo AND MGMT SCIENCE/ METROPOLITAN STATE COLLEGE/ 1006 11TH STREET BOX 13/ DENVER CO 80204/ (303) 629-3009
P. K. GOVIND/ 850 WEST MOORHEAD CIRCLE - APT. 2-L/ BOULDER CO 80303
R. KEITH NICKEY/ 3580 EVERETT DRIVE/ BOULDER CO 80303/ (303) 494-2847
WILLIAM M. WAITE/ ELECTRICAL ENGINEERING DEPT./ SOFTWARE ENGINEERING GROUP/ UNIVERSITY OF COLORADO/ BOULDER CO 80309/ (303) 492-7204
GEORGE W. ANTHONY/ ANTHONY FARMS/ BOX 632/ BURL ID 83316/ (208) 326-5703/ (208) 543-5233
JAY WOODS/ BOX 297/ MARSING ID 83639/ (208) 896-4462
ATTN: COMPUTER SCIENCE DEPARTMENT/ 3160 MEB/ UNIV OF UTAH/ SAL T LAKE CITY UT 84112/ (801) 581-8224
MIKE LEMON/ COMPUTER SCIENCE DEPT./ 3160 MEBI UNIVERSITY OF UTAH/ SALT LAKE CITY UT 84112/ (801) 581-8378
GARY LINDSTROM/ COMPUTER SCIENCE DEPT./ UNIV OF UTAH/ SALT LAKE CITY UT 84112/ (801) 581-8224
ED SHARP/ COMPUTER CENTER/ 3116 M.E.B./ U OF UTAH/ SALT LAKE .CITY UT 84112/ (801) 581-6575
RICHARD M. WILSON/ BIOMEDICAL ELECTRONICS/ ST. JOSEPH'S HOSPITAL/ P.O. BOX 2071/ PHOENIX AZ 85001/ (602) 277-6611 X3257
ROBERT FULKS/ SUITE 253/ OMNICOMP INC./ 5150 N. 16TH ST./ PHOENIX AZ 85016/ (602) 264-2475
KIRK D. THOMPSON/ 2321 EAST LOYOLA DRIVE/ TEMPE AZ 85282/ (602) 965-3716(WORK)
DAVE PEERCY/ BDM CORP./ 2600 YALE BLVD. SEt ALBUQUERQUE NM 87106
BOB WALSH/ 817 LAFAYETTE DR. NE/ ALBUQUERQUE NM 87106/ (505) 268-1654
BRUCE LINK/ DIVISION 1712/ SANDIA LABORATORIES/ ALBUQUERQUE NM 87115/ (505) 264-1281

.,
J'T1

t:rI
:;;0

=

:l>
:;;0

-<

.......
1.0

.........
CO

87115
88003
88047
89154
90007
90007
90020
90036
90066
90250
90266
90274
90278
90278
90278
90278
90402
90403
90405
90406
90501
90733
90801
90803
91101
91101
91104
91126
91203
91307
91330
91342
91360
91367
91405
91601
91604
91711
91775
92014
92093
92093
92110
92127
92152
92324
92335
92507
92626
92627
92634
92634
92644
92646
92669
92680
92680
92704
92704
92705
92713
92713
92714
92714
92714
92714

NANCY RUIZ/ ORG. 5166/ SANDIA LABS/ ALBUQUERQUE NM 87115/ (505) 264-3690
JOSEPH EINWECK/ COMPUTER CENTER/ NEW MEXICO STATE UNIVERSITY/ BOX 3AT/ LAS CRUCES NM 88003/ (505) 646-1443
JOHN TUCKER/ P.o. BOX 2122/ MESILLA PARK NM 88047/ (505) 526-5544 X64
JOHN WERTH/ DEPT. OF MATH/ UNIV OF NEVADA - LAS VEGAS! LAS VEGAS NV 89154/ (702) 739-3567
PER BRINCH HANSENj COMPUTER SCIENCE DEPT.! UNIV. OF SOUTHERN CALIFORNIA! UNIVERSITY PARK! LOS ANGELES CA 90007! (213) 741-5501
JORGEN STAUNSTRUP! COMPUTER SCIENCE DEPT.! UNIV. OF SOUTHERN cALIFORNIA! UNIVERSITY PARK! LOS ANGELES CA 90007/ (213) 741-5501
KENNETH YOUNG! 3311 WEST 3RD ST. APT. 1-319/ LOS ANGELES CA 90020/ (213) 383-9666
WILLIAM MOSKOWITZ! INSTRUCTIONAL SUPPORT GROUP! CALIFORNIA STATE UNIVERSITY! 5670 WILSHIRE BOULEVARD/ LOS ANGELES CA 90036/ (213) 852-5789
LEROY E. NELSON/ 11925 AVON WAY/ LOS ANGELES CA 90066! (213) 397-7390
CHARLES SISKA JR.! TRW DATA SYSTEMS/ 12911 SIMMS AVENUE! HAWTHORNE CA 90250! (213) 535-3777
HERBERT E. MORRISON/ 1257 2ND STREET! MANHATTAN BEAC CA 90266
JIM HIGHTOWER! 4947 BROWNDEER LANE/ RANCHO PALOS V CA 90274! (213) 541-4662
JAMES L. AGIN/ 2178 BLD. 90! TRW-DSSG! ONE SPACE PARK! REDONDO BEACH CA 90278/ (213) 535-0313
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 BEAC H CA 90278/ (2l3) 535-03l3
ROGER A. VOSSLER! BLDG. 90-2178! TRW!DSSG! ONE SPACE PARK! REDONDO BEACH CA 90278! (213) 535-0312
WILLIAM S. COOKE! 503 22ND STREET! SANTA MONICA CA 90402! (223) 451-2615
MICHAEL TEENER! TECHNOLOGY SERVICE CORP.! 2811 WILSHIRE BLVD./ SANTA MONICA CA 90403/ (2l3) 829-7411 X244
TERRY J. LAYMAN/ 2039 4TH ST. #106! SANTA MONICA CA 90405! (213) 357-2121 X279
ATTN: ELAINE DENTON (41-41)! SOFTWARE INFORMATION SERVICES! SY STEM DEVELOPMENT CORP./ 2500 COLORADO AVE./ SANTA MONICA CA 90406
WILLIAM E. FISHER! 2074 SANTA FE AVENUE! TORRANCE CA 90501! (2 13) 328-7193
PAUL RUSSELL/ LOGICON INC.! 255 WEST 5TH ST. P.O. BOX 471/ SAN PEDRO CA 90733/ (213) 831-0611
DAVE SKINNER! COMMUNICATION MFG. COMPANY/ P.O. BOX 2708! LONG BEACH CA 90801! (213) 426-8345
STEVEN L. BRECHER/ 5235 MARINA PACIFICA DR. NORTH KEY 19! LONG BEACH CA 90803
GURUPREM SINGH KHALSA! BYTE SHOP OF PASADENA! 496 SOUTH LAKE A VENUE! PASADENA CA 91101! (213) 684-3311
E. E. SIMMONS/ 455 SOUTH OAKLANU AVE! PASADENA CA 91101/ (213) 687-7047
MILAN KARSPECK! 1149 NORTH MICHIGAN! PASADENA CA 91104
LARRY SEILER/ 1-55 RUDDOCK! CALIFORNIA INST. OF TECHNOLOGY/ PA SADENA CA 91126/ (2l3) 449-9886
RICHARD DIEVENDORFF/ DEPARTMENT 84F! IBM/ 620 NORTH BRAND BLVD .! GLENDALE CA 91203
RHODA P. NOVAK/ 6736 RANDlWOOD LANE/ CANOGA PARK CA 91307! (213) 346-1135
JOHN M. MOTIL/ DEPT. OF COMPUTER SCIENCE/ CALIFORNIA STATE UNI V.! NORTHRIDGE 'CA 91330! (2l3) 885-2193
STERLING WILSON! 1162t, RINCON AVE./ SYLMAR CA 91342
PAULO S. CASTILLO JR.! 385 QUEENSBURY ST.! THOUSAND OAKS CA 91 360! (213) 670-1515 X3100
GEORGE MASSAR/ 6225-102 SHOUP AVE./ WOODLAND HILLS CA 91367! (213) 346-1883! (213) 970-5021 (NORTHROP)
L. F. MELLINGER! 13622 HART ST.! VAN NUYS CA 91405! (213) 354- 2505
LARRY ROBERTSON! 5651 CASE AVE./ N. HOLLYWOOD CA 91601! (213) 762-8068
JERRY POURNELLE/ 12051 LAUREL TERRACE DRIVE! STUDIO CITY CA 91604/ (213) 762-2256
STANLEY E. LUNDE! 890 HOOD DRIVE/ CLAREMONT CA 91711! (714) 626~9977
TOM GREER! 224 N. ALABAMA ST./ SAN GABRIEL CA 91775/ (2l3) 286 -8226
JOEL MCCORMACK/ 507 CAMINO DEL MAR! DEL MAR CA 92014/ (714) 75 5-8135
KEN BOWLES! APIS DEPT./ C-021/ U OF CALIFORNIA - SAN DIEGO! LA JOLLA CA 92093/ (714) 755-7288! 452-4526
BOB HOFKIN/ APIS DEPT. C-014! UNIV. OF CALIFORNIA-SAN DIEGO! LA JOLLA CA 92093
BILL VELMAN/ SCHOOL OF LAW! UNIV. OF SAN DIEGO! ALCALA PARK/ S AN DIEGO CA 92110/ (714) 291-6480
WALT FEESER! MS 401/ BURROUGHS CORP./ 16701 W. BERNARDO DR.! S AN DIEGO CA 92127
MICHAEL S. BALL! CODE 632/ NAVAL OCEAN SYSTEMS CENTER! SAN DIEGO CA 92152! (714) 225-2365
DAVID H. WELCH! P.O. BOX 721! COLTON CA 92324
WALLY SCHNITGER! C/O INSTRUlIENT RESEARCH CO.! P.O. BOX 666! FO NTANA CA 92335/ (714) 546-4474
JOHN DE PILLIS! 2931 WALDORF DRIVE/ RIVERSIDE CA 92507! (714) 686-0534 (HOME)! (714) 787-5002 (WORK)
ATTN: A. S. WILLIAMS - LIBRARIAN! LIBRARY! TECHNOLOGY MARKETING INC.! 3170 RED HILL AVE.! COSTA MESA CA 92626/ (714) 979-1100
TIll LOWERY! 2653 SANTA ANA AVE.! COSTA MESA CA 92627
WALTER R. RYPER/ BLDG 604 M!S E212! HUGHES - GSG! P.O. BOX 3310! FULLERTON CA 92634! (714) 871-3232 X3318
SEYMOUR SINGER/ BLDG 606/M.S. K110! HUGHES AIRCRAFT CO.! P.O. BOX 3310! FULLERTON CA 92634! (714) 871-3232 X1167
lIARK JUNGWIRTH! 13318 NEWLAND ST! GARDEN GROVE CA 92644
BARcLAY R. KNERR! 9061 CHRISTINE DRIVE! HUNTINGTON BCH CA 9264 6
TED SHAPIN! 5110 E. ELSINORE AV.! ORANGE CA 92669! (714) 633-0922
ROBERT W. ANDERSON! 345 W. FIRST APT 38! TUSTIN CA 92680
GARY DUNCAN! P.O. BOX 930! TUSTIN CA 92680
DAVID C. FITZGERALD! CONTROL DATA CORP.! 3519 W. WARNER AVE.! SANTA ANA CA 92704! (714) 754-4244
JIM FONTANA! CONTROL DATA CORPORATION! 3519 W. WARNER AVE.! SANTA ANA CA 92704! (714) 754-4244
lIARK M. SCHNEGG! PERTEC COMPUTER CORP.! 17112 ARMSTRONG AVE./ IRVINE CA 92705! (714) 540-8340
RUDY L. FOLDEN/ OPERATING SYSTEMS DEVELOPMENT! P.O. BOX C-1950 4! 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
ALEX BRADLEY/ STANDARD SOFTWARE SYSTEMS/ 17931 'J' SKY PARK/ IRVINE CA 92714
WILLIAM E. DROBISH/ ADVANCED DEVELOPMENT/ SILICON SYSTEMS INC. / 16692 HALE AVENUE! IRVINE CA 92714! (714) 979-0941
PAUL KELLY/ EDUCATIONAL DATA SYSTEMS/ 1682 LANGLEY AVENUE/ IRV INE CA 92714/ (714) 556-4242
JOHN S. CONERY! PERTEC COMPUTER CORP.! 17112 ARMSTRONG AVE.! SANTA ANA CA 92714! (714) 540-8340

-0

:P
(/)

n
:t:>

r

=
fT1
::;:
en
~

f--'
f--'

-<

~

:>
Gl
[11

N
V1

92715
92803
92807
93017
93105
93111
93407
94010
94022
94025
94035
94086
94086
94086
94086
94088
94109
94112
94301
94303
94304
94304
94306
94404
94521
94546
94550
94563
94611
94701
94701
94702
94704
94707
94708
94709
94720
94720
94801
94804
94901
95005
95014
95014
95014
95030
95030
95035
95050
95050
95051
95051
95064
95120
95131
95133
95153
95404.
95521
97077
97077
97077
97077
97077
97077
97201

WILLIAM J. EM!.L/ 10 BANYAN TREE LANE/ IRVINE CA 92715/ (714) 552-1543
C. L. HORNEY/ MICROELECTRONIC DEVICE DIV./ D/832-RC27/ ROCKWEL L INTERNATIONAL/ P.O. BOX 3669/ ANAHEUI CA 92803
DAN MARCUS/ GTE INFORMATION SYSTEMS/ 5300 E. LA PALMA AVE./ ANAHEIM CA 92807/ (714) 524-3131
BILL DODSON/ BURROUGHS CORP./ 6300 HOLLISTER/ GOLETA GA 93017/ (805) 964-6881
DENNIS R. AU·STIN/ 26 WEST JUNIPERO STREET/ SANTA BARBARA CA 93105/ (805) 962-7320
ANDY HARRINGTON/ 72 SOUTH PATTERSON #207/ SANTA BARBARA CA 93111/ (805) 964-6881 (WORK)/ (805) 967-4235 (HOME)
NEIL W. WEBRE/ DEPT. OF COMPo SCI. AND STAT./ CALIF. POLY. STATE UNIV./ SAN LUIS OBISP CA 93407/ (805) 546-2986
D. B. ANDERSON/ 280 BELLA VISTA DRIVE/ HILLSBOROUGH CA 94010
ATTN: NEWBERRY MICROSYSTEMS/ 24225 SUMMERHILL AVE/ LOS ALTOS CA 94022/ (415) 948-8007
BOB ALBRECHT/ DYMAX/ P.O. BOX 310/ MENLO PARK CA 94025/ (415) 323-6117
CARL S. ROSENBERG/ AMES RESEARCH CENTER/ MAIL STOP 239-19/ MOFFETT FIELD CA 94035/ (415) 965-6436 (WORK)/ (415) 967-7000 (HOME)
GEORGE LEWIS/ R & D/ BASIC TIMESHARING INC./ 870 WEST MAUDE AV ENUE/ SUNNYVALE CA 94086/ (408) 733-1122
FLEMING M. OLIVER/ 213 WEDDELL - APT. 12/ SUNNYVALE CA 94086/ (408) 734-8771
GERALD STEINBACK/ SYSTEMS PROGRAMMING/ SIGNETICS CORP./ 811 EA ST ARQUES AVE./ SUNNYVALE CA 94086/ (408) 739-7700 X2055
ANDREW HARRIS ZI~lliRMAN/ 550 NORTH FAIR OAKS AVE. APT. 14/ SUNNYVALE CA 94086/ (408) 732-8109
ROY E. BOLLINGER/ DEPT. 1965/ BLD 529/ LOCKHEED/ P.O. BOX 504/ SUNNYVALE CA 94088/ (408) 742-3182
ERIC SMALL/ ERIC SMALL AND ASSOCIATES/ 680 BEACH STREET/ SAN FRANCISCO CA 94109/ (415) 441-0666
TURNEY C. STEWARD/ 201 DRAKE ST./ SAN FRANCISCO CA 94112
JAN DEDEK/ 505 LOWELL AVE./ PALO ALTO CA 94301/ (415) 321-9298
C. E. DUNCAN/ 865 THORNWOOD DRIVE/ PALO ALTO CA 94303
LINDA E. CROLEY/ BNR INC./ 3174 PORTER DR./ PALO ALTO CA 94304/ (415) 494-3942 X40 OR 61
ROBERT A. FRALEY/ HEWLETT PACKARD LABS/ 3500 DEER CREEK RD./ pALO ALTO CA 94304/ (415) 494-1444
DAVID ELLIOT SHAWl SUITE 605/ STRUCTURED SYSTEMS CORPORATION/ 2600 EL CAMINO REAL/ PALO ALTO CA 94306/ (415) 321-8111
BRUCE BARRETT/930 LIDO LANE/ FOSTER CITY CA 94404/ (415) 349- 8724
PAUL GODFREY/ 5545 MARYLAND DR./ CONCORD CA 94521
DAVID F. FRICK/ 5964 HIGHWOOD RD./ CASTRO VALLEY CA 94546/ (415) 537-9536
S. T. HEIDELBERG/ DIVISION 8323/ SANDIA LABORATORIES/ LIVERMOR E CA 94550/ (415) 455-2179
DAVID CLINGERMAN/ 63 LOST VALLEY DRIVE/ ORINDA CA 94563/ (415) 834-3030
ROBERT C. NICKERSON/ 6966 COLTON BLVD/ OAKLAND CA 94611
JOSEPH N. JOHNSON/ P.O. BOX 92/ BERKELEY CA 94701
JOHN P. MCGINITIE/ P.O. BOX 655/ BERKELEY CA 94701
TIMOTHY DAVID MCCREERY/ P.O. BOX 2423/ BERKELEY CA 94702/ (415) 527-2774
MARK ZIMMER/ #10 2750 DWIGHT AVE/ BERKELEY CA 94704
DAVE BAASCH/lOll FOUNTAIN WALK/ BERKELEY CA94707/ (415) 525- 3458
MAURICE MCEVOY/ 1212 QUEEN'S ROAD/ BERKELEY CA 94708/ (415) 843-8260
PETER LINHARDT/ 1890 ARCH STREET - APT. 202/ BERKELEY CA 94709/ (415) 841-6917
ATTN: LIBRARY/ LAWRENCE BERKELEY LAB/ 134 BLDG 50/ UNIV OF CAL IFORNIA/ BERKELEY CA 94720
WILLETT KEMPTON/ LANGUAGE BEHAVIOR RESEARCH LAB/ UNIVERSITY OF CALIFORNIA/ 2220 PIEDMONT AVE./ BERKELEY CA 94720
HARRY R. CHESLEY/ 400 WEST RICHMOND/ POINT RICHMOND CA 94801/ (415) 233-8220
CARROLL E. BUTTERFIELD/ ELECTRONICS DIVISION/ BADGER METER INC./ 150 EAST STANDARD AVENDE/ RICHMOND CA 94804/ (415) 233-8220
ERNEST w. JONES/59 BILLOU STREET/ SAN RAFAEL CA 94901
WARREN VAN CAMP/ 485 PARK DR./ BEN LOMOND CA 95005/ (408) 336- 5654
ATTN: ENGINEERING LIBRARY/ FOUR-PHASE SYSTEMS INC./ 10700 NORTH DE ANZA BLVD./ CUPERTINO CA 95014/ (408) 255-0900 X2694
ARDON R. CORDI DATREX CORP./ 21050 MCCLELLAN ROAD - SUITE 1/ CUPERTINO CA 95014/ (408) 996-2551
BOB PUETTE/ DATA SYSTEMS DIVISION/ HEWLETT-PACKARD CO. / 11000 WOLFE ROAD/ CUPERTINO CA 95014/ (408) 257-7000
STAN HEAD/ 19270 RAINERI LANE/ LOS GATOS CA 95030/ (408) 353-3055
TERRY THOMAS/ 24740 MILLER HILL RD./ LOS GATOS CA 95030/ (415) 965-6436
ROB MEANS/ 1421 YELLOWSTONE/ MILPITAS CA 95035/ (408) 262-0420
JOHN DENNIS COUCH/ GSD/ HEWLETT-PACKARD/ 5303 STEVENS CREEK BLVD./ SANTA CLARA CA 95050/ (408) 249-7020 X2949
E. HAROLD WILLIAMS/ SYSCOM/ 3058-B SCOTT BLVD./ SANTA CLARA CA 95050/ (408) 246-2437
JOHN DOERR/ INTEL CORPORATION MCD/ 3065 BOWERS AVENUE/ SANTA CLARA CA 95051/ (408) 987-7351
R. STEVEN GLANVILLE/ 100 BUCKINGHAM DR. APT 238/ SANTA CLARA CA 95051/ (408) 241-6294
MICHAEL FAY/ INFORMATION SCI. DEPT./ UNIV. OF CALIFORNIA - SANTA CRUZ/ SANTA CRUZ CA 95064/ (408) 429-4043
THOMAS A. ROLANDER/ 21950 MCKEAN ROAD/ SAN JOSE CA 95120/ (408) 378-2014
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) 734-7145
TOM PITTMAN/ ITTY BITTY COMPUTERS/ P.O. BOX 23189/ SAN JOSE CA 95153
GARY LOWELL/ 2625 HIDDEN VALLEY/ SANTA ROSA CA 95404/ (707) 544-6373
ATTN: DIRECTOR / INST. RESEARCH/ ADP/ HUMBOLDT STATE UNIVERSITY/ ARCATA CA 95521
, ATTN: MANUFACTURING COMPUTER GROUP/ DS 60-171/ TEKTRONIX INC./ P.O. BOX 500/ BEAVERTON OR 97077/ (503) 638-3411 X2710
TERRY HAMM/ M.S. 60-456/ TEKTRONIX INC./ P.O. BOX 500/ BEAVERTON OR 97077/ (503) 638-3411 X2579
RANDY HODNETT/ MS 39-007/ TEKTRONIX INC./ P.O. BOX 500/ BEAVERTON OR 97077/ (503) 644-0161
GREG JOHNS/ MS 39-007/ TEKTRONIX INC./ P.O. BOX 500/ BEAVERTON OR 97077/ (503) 644-0161
LYNN SAUNDERS/ MS 39-135/ TEKTRONIX INC./ P.O. BOX 500/ BEAVERTON OR 97077/ (503) 644-0161 X6640
WAYNE VYROSTEK/ MS 74-329/ TEKTRONIX INC./ P.O. BOX 500/ BEAVERTON OR 97077/ (503) 644-0161
ROBERT D. PERRY JR./ 255 SW HARRISON ST. APT. 5-D/ PORTLAND OR 97201/ (503) 222-6654

-0

::I>
(/)

n

,

:>

z
fT1
~
(/)
~

I-'
i--'

=

f~

CO
'J

c:o

N

en

97213
97221
97229
97330
97330
97401
97440
98008
98033
98040
98043
98109
98195
98225
98401
98632
98926
99210
99258
2006
2006
2006
2308
2308
2308
2600
3000

AUSTRALIA
AUSTRAL IA
AUSTRALIA
AUSTRALIA
AUSTRALIA
AUSTRALIA
AUSTRALIA
AUSTRALIA

3052
3052
3072
3165
4001
4067
5001
5063
5098
6102
7001
A-1040
A-1150
B-1050
B-1170
B-1180
H3C 3J7
H3S lJ6,
K1S 5B6
K2A 1T2
L4W ITO
L5N 1KT
L5N 1KT
L5N 1K7
M4B 2E5
M4N 1M
M4Y 1P9
M5P 2C3
M5S 1A4
M9W 5R8
N2J 4H2
N2L 3G1
N2L 3G1
N6A 4N5
QUEBEC

AUSTRALIA
AUSTRALIA
AUSTRALIA
AUSTRALIA
AUSTRALIA
AUSTRALIA
AUSTRAL IA
AUSTRALIA
AUSTRALIA
AUSTRALIA
AUSTRALIA
AUSTRIA
AUSTRIA
BELGIUM
BELGIUM
BELGIUM
CANADA
CANADA
CANADA
CANADA
CANADA
CANADA
CANADA
CANADA
CANADA
CANADA
CANADA
CANADA
CANADA
CANADA
CANADA
CANADA
CANADA
CANADA
CANADA

, V6T 1W5 CANADA
V6X 2Z9 CANADA

BRIAN HANSEN! 2426 N.E. 57TH AVE. APT #3! PORTLAND OR 97213! ( 503) 284-3537
ATTN: OREGON MINI-COMPUTER SOFTWARE IN! 4015 SW CANYON ROAD! PORTLAND OR 97221! (S03) 226-7760
DAVID ROWLAND! ELECTRO SCIENTIFIC INDUSTRIES! 13900 N.W. SCIEN CE PARK DRIVE! PORTLAND OR 97229! (503) 641-4141
DAVID F. CAUTLEY! DEPT. OF COMPUTER SCIENCE! GENERAL INFORMATION SYSTEMS INC.! 983 N.W. SPRUCE ST.! CORVALLIS OR 97330! (503) 754-1171
GARY OLIVER! P.O. BOX 826! CORVALLIS OR 97330! (503) 753-1770
H. MARC LEWIS! REGIONAL INFORMATION SYSTEMS! 125 E 8TH! EUGENE OR 97401! (503) 687-4559
KENT LOOBEY! FARWEST STEEL CORP.! P.O. BOX 889! EUGENE OR 9744 O! (503) 686-2000
KEITH MITCHELL! 16213 SE 28 PL! BELLEVUE WA 98008
KENNETH E. CHARLTON! 12929 1 11TH PLACE N.E.! KIRKLAND WA 98033! (206) 822-9348
DONNAFAYE FINGER! 4108 78TH AVE SE! MERCER ISLAND WA 98040! (2 06) 232-2428
GARY S. ANDERSON! JOHN FLUKE MFG. CO. INC.! P.O. BOX 43210 - M.S. 29! MOUNTLAKE TERR WA 98043! (206) 774-2296
PETER A. ARMSTRONG! DIGITAL DATA SYSTEMS! 1113 DEXTER AVE. N.! SEATTLE WA 98109! (206) 282-2323
HELLMUT GOLDE! DEPT. OF COMPo SCI.! FR-35! U OF WASHINGTON! SEATTLE WA 98195! (206) 543-9264
ROBERT B. FINCH! 910 N. LAKE SAMISH DR.-APT. 30! BELLINGHAM WA 98225! (206) 734-0781
ATTN: ENGINEERING LIBRARY! PT 1-14! WEYERHAUSER CO.! TACOMA WA 98401! (206) 572-9000 X495
BUZZ HILL! EYEDENTIFY INC.! P.O. BOX 2006! LONGVIEW WA 98632! (206) 423-3281
F. STANLEY! COMPUTER SERVICES! CENTRAL WASHINGTON UNIV.! ELLENBURG WA 98926
FRED J. MILLER! BUSINESS COMPUTER SYSTEMS! DATACOMP! P.O. BOX 1087! SPOKANE WA 99210! (509) 456-6908
HOUSTON P. LOWRY! GONZAGA UNIVERSITY! STDDENT BOX 816! SPOKANE WA 99258
TONY J. GERBER! BASSER DEPT. OF COMPUTER SCIENCE! UNIVERSITY OF SYDNEY! SYDNEY N.S.W. 2006! AUSTRALIA! 6923216
CARROLL MORGAN! BASSER DEPT. OF COMPUTER SCIENCE! UNIV. OF SYDNEY! SYDNEY N.S.W. 2006! AUSTRALIA! 692 3216
BRIAN G. ROWSWELL! UNIVERSITY COMPUTING CENTRE H08! UNIVERSITY OF SYDNEY! SYDNEY N.S.W. 2006! AUSTRALIA! (02) 692-3491
ATTN: SERIALS DEPARTMENT! AUCHMUTY LIBRARY! UNIVERSITY OF NEWC ASTLE! NEWCASTLE N.S.W. 2308! AUSTRALIA! 685391
J. A. CAMPBELL! MATHEMATICS DEPT.! UNIVERSITY OF NEWCASTLE! NEWCASTLE N.S.W. 2308! AUSTRALIA! 685 657
P. SIMON! DEPT OF MATHEMATICS! UNIV. OF NEWCASTLE! NEWCASTLE N .S.W. 2308! AUSTRALIA
N. D. H. HAMMOND! FLEET MAINTENANCE! NAVY OFFICE OF UNDERWATER WEAPONS! CANBERRA A.C.T. 2600! AUSTRALIA
Q. VAN ABBE! COMPUTER CENTRE! ROYAL MELBOURNE INSTITDTE OF TEC HNOLOG! 124 LATROBE STREET! MELBOURNE VICTORIA 3000! AUSTRALIA! (03) 341-2467
(03) 341-2292
ATTN: LIBRARIAN! SCHOOL OF MATHEMATICAL SCIENCES! RICHARD BERRy BUILDING! UNIVERSITY OF MELBOURNE! PARKVILLE VICTORIA 3052! AUSTRALIA
PETER RICHARDSON! COMPUTER SCIENCE DEPT.! UNIV. OF MELBOURNE! PARKVILLE VICTORIA 3052! AUSTRALIA! (03) 3415225
M. RAHILLY! 2 RITA STREET! EAST PRESTON VICTORIA 3072! AUSTRAL IA
GEOFFREY A. CLEAVE! 18 NEIL COURT! E. BENTLEIGH VICTORIA 3165! AUSTRALIA
W. J. G. FISHER! QUEENSLAND INST. OF TECHNOLOGY! G.P.O. BOX 2434! BRISBANE QUEENSLAND 4001! AUSTRALIA! 221-2411 X423
D. B. JOHNSTON! DEPT. OF COMPUTER SCIENCE! UNIV. OF QUEENSLAND! ST. LUCIA QUEENSLAND 4067! AUSTRALIA! 07!3706930
B. KIDMAN! DEPT OF COMPUTER SCIENCE! UNIVERSITY OF ADELAIDE! GPO BOX 498! ADELAIDE S.A. 5001! AUSTRALIA! 223 4333
I. N. BLAVINS! 40 WOODFIELD AVENUE! FULLARTON S.A. 5063! AUSTRALIA
CHRIS A. RUSBRIDGE! SAENET! SOUTH AUSTRALIA INSTITDTE OF TECHNOLOG! P.O. BOX I! INGLE FARM S.A. 5098! AUSTRALIA! AUSTRALIA 08-260-2055
D. P. HODGSON! DEPT. OF MATHEMATICS AND COMPUTER STUD! WESTERN AUSTRALIAN INSTITDTE OF TECHNO! HAYMAN ROAD! SOUTH BENTLEY W.A. 6102! AUSTRALIA
A. H. J. SALE! DEPT. OF INFORMATION SCIENCE! UNIVERSITY OF TASMANIA! BOX 252C! HOBART TASMANIA 7001! AUSTRALIA! (002) 23 0561
ATTN: INST. FUER INFORMATIONSSYSTEME! TECHNISCHE UNIVERSITAT WlEN! WIEN A-1040! AUSTRIA
KONRAD MAYER! REICHSAPFELG 13!8! VIENNAA-1150! AUSTRIA! (02254) 201 781
o. BEAUFAYS! MATHEMATIQUES APPLIQUEES! C P I 165! UNIVERSITE L IBRE DE BRUXELLES! AVENUE F.-D. ROOSEVELT 50! BRUXELLES B-10S0! BELGIUM
ALAIN PIROTTE! MBLE!RESEARCH LABORATORY! AVENUE EM. VAN BECELAERE 2! BRUSSELS B-1170! BELGIUM! 673.41.90! 673.41.99
MARTINE DE GERLACHE! CENTRE DE CALUL! INSTITDTE ROYAL METEOROLOGIQUE! 3 AVENUE CIRCULAIRE! BRUXELLES B-1180! BELGIUM
PATRICK WARD! CENTRE DE CALCULI UNIVERSITE DE MONTREAL! C.P. 6 128! MONTREAL QUEBEC H3C 3J7! CANADA! (514) 343-6866
FRANCOIS PINARD! 2780 BARCLAY - APPARTEMENT I! MONTREAL QUEBEC H3S lJ6! CANADA! (514) 342-3450
DAVID A. THOMAS! COMPUTING SERVICES! 401 ADMIN. BLDG.! CARLETON UNIV.! OTTAWA ONTARIO K1S 5B6! CANADA! (613) 231-6770
F. S. WINTERSPRING! P.O. BOX 6115 STATION J! OTTAWA ONTARIO K2A 1T2! CANADA
CARLO LOCICERO! 3501 GLEN ERIN DRIVE #401! HISSISSAUGA ONTARIO L4W ITO! CANADA! (416) 826-8640
PETER HAYNES! CONTROL DATA CANADA LTD.! 1855 MINNESOTA COURT-STREETSVILLE! MISSISSAUGA ONTARIO L5N 1KT! CANADA! (416) 826-8640 X238
DAVID JONES! CONTROL DATA CANADA LTD.! 1855 MINNESOTA COURT-STREETSVILLE! MISSISSAUGA ONTARIO LSN 1KT! CANADA! (416) 826-8640 X262
HENRY MCGILTON! CONTROL DATA CANADA! 1855 MINNESOTA COURT! MIS SISSAUGA ONTARIO L5N 1K7! CANADA! (416) 826-8640 X295
MARK GREEN! #1001 - 390 DAWES ROAD! TORONTO ONTARIO M4B 2E5! CANADA! (416) 755-8607
NORMAN A. JULL! 56A BLYTHWOOD ROAD! TORONTO ONTARIO M4N 1M! CANADA
RON BAECKER! HUMAN COMPUTING RESOURCES! 10 ST. MARY STREET SUITE 401! TORONTO ONTARIO M4Y 1P9! CANADA! (416) 922-1937
ROBERIO DIAS! 134 COLIN AVE.! TORONTO ONTARIO MSP 2C3! CANADA
LEONARD VANEK! ,COMPUTER SYSTEMS RESEARCH GROUP! SANFORD FLEMIN G BLDG! UNIV. OF TORONTO! TORONTO ONTARIO M5S 1M! CANADA! (416) 978-6219
RON MCKERRON/ COMSHf~E LTD.! 230 GALAXY ROAD! REXDALE ONTARIO M9W SR8! CANADA
CHARLES H. FORSYTH! APT. 2-304! 300 REGINA ST. N.! WATERLOO ONTARIO N2J 4H2! CANADA! (519) 884-7531! (519) 885-1211 X3055
JOHN C. BEATTY! DEPT. OF COMPo SCIENCE! UNIV OF WATERLOO! WATERLOO ONTARIO N2L 3G1! CANADA! (519) 885-1211 X2241
W. MORVEN GENTLEMAN! MATHEMATICS COMPUTING FACILITY! UNIVERSITy OF WATERLOO! WATERLOO ONTARIO N2L 3G1! CANADA! (519) 578-8866! (519) 885-1211
R. A. ALLAN! DIESEL DIVISION! GENERAL MOTORS OF CANADA LTD.! P.O. BOX 5160! LONDON ONTARIO N6A 4N5! CANADA
DANIEL THALMANN! DEPARTEMENT D'INFORMATIQUE ET RECHERCH! UNlVE RSITE DE MONTREAL! CASE POSTALE 6128 - SUCC A! MONTREAL H3C 3J7 QUEBEC! CANADA
(514) 343-7477
BARY W. POLLACK! DEPT OF COMPo SCI.! UNIV. OF BRITISH COLUMBIA! 2075 WESBROOK PLACE! VANCOUVER B.C. V6T 1WS! CANADA! (604) 228-6794
I. GANAPATHY! NOOTKA BUILDING! MACDONALD DETTWILER & ASSOCIATES! 10280 SHELLBRIDGE WAY! RICHMOND B.C. V6X 2Z9! CANADA! (604) 278-3411 X32

-n

rn
t:O
:;;0

=

;I>
:;;0

-<

DK-1051
DK-2200
DK-2650
DK-2800
DK-9220
SF-00100
SF-20500
SF-33101
SF-33101
SF-33101
SF-33200
SF-33340
SF-33410
SF-33720
F-310n

DENMARK
DENMARK
DENHARK
DENHARK
DEmlARK
FINLAND
FINLAND
FINLAND
FINLAND
FINLAND
FINLAND
FINLAND
FINLAND
FINLAND
FRANCE
F-310n FRANCE
F-34075 FRANCE

F-38000
F- 54042
F-75230
D-lOOO
D-2000
D-2000
D-2000
D-3000
D-3000
D-4400
D-5000
D-6236
D-6300
D-6750
D-7000
D-7408
D-7500

FRANCE
FRANCE
FRANCE
GERHANY
GERHANY
GERHANY
GERHANY
GERHANY
GERHANY
GERHANY
GERHANY
GERHANY
GERHANY
GERHANY
GERl1ANY
GERHANY
GERHANY

D-7500 GERHANY
D-7500 GERHANY
D-7900
D-8000
D-8000
D-8000
D-8000
D-8012
D-8031
500762
2

1-40033
1-40122
1-40122
113
151
182
560
0001
14
34

GERHANY
GERHANY
GERHANY
GERHANY
GERHANY
GERHANY
GERHANY
INDIA
IRELAND
IRELAND
IRELAND
ISRAEL
ISRAEL
ISRAEL
ITALY
ITALY
ITALY
JAPAN
JAPA.'1
JAPAN
JAPAN
JAPAN
NEW ZEALAND
NORWAY
SOUTH AFRICA
SPAIN
SPAIN

110GENS LINDHARD/ NYHAVN 20/ KOBENHAVN K DK-1051/ DENHARK/ (01) 11 12 04
ATTN: BIBLIOTEKET/ DATALOGISK INSTlTUT./ KOBENHAVN UNIVERSITET/ SIGURDSGADE 41/ KOBENHAVN N DK-2200/ DENMARK
NIELS WINTHER/ REBAEK SOPARK 5-544/ HVIDOVRE DK-2650/ DENHARK
GUNNAR JOHANSEN/ DEPT. OF CHENISTRY AND CHEN. ENG./ DANISH ENGINEERING ACADEHY/ BYGNING 375/ LYNGBY DK-2800/ DENHARK
UFFE MOLLER/ DATANOMUDDANNELSEN/ LANGAGERVEJ 16/ AAIBORG OST DK-9220/ DENMARK/ (08) 15 81 00
ATTN: DEPT. OF COMPUTER SCIENCE/ UNIVERSITY OF HELSINKI/ TOOLONKATU 11/ HELSINKI 10 SF-00100/ FINLAND
MARKKU SUNIl COMPUTER CENTRE/ UNIVERSITY OF TURKU/ TURKU 50 SF-20500/ FINLAND/ 921-335599 X280
MATTI KARINEN/ COMPUTING CENTRE/LPR-PROJECT/ TAMP ERE UNIV. OF TECHNOLOGY/ PL 527/ TAMPERE 10 SF-33101/ FINLAND/ 931-652802(HOME)/ 931-162125 (WORK)
JUKKA KESO/ COMPUTING CENTRE/LPR-PROJECT/ TAMPERE UNIV. OF TECHNOLOGY/ PL 527/ TAMPERE 10 SF-33101/ FINLAND/ 931-33727 (HOME)/ 931-162125 (WORK)
JYRKI TUOMI/ COMPUTING CENTRE/LPR-PROJECT/ TAMPERE UNIV. OF TECHNOLOGY/ PL 527/ TAMPERE 10 SF-33101/ FINLAND/ 931-50000/570 (HOME)/ 931-162125 (WORK)
JORMA SINNAMO/ PYYNIKINT. 3/ TAMPERE 20 SF-33200/ FINLAND
VEIKKO VISALA/ KUOKKIJANTIE 10/ TAMPERE 34 SF-33340/ FINLAND/ 917-712338
TIMO HAMMAR/ JANISLAHDENKATU 3 A 7/ TAMPERE 41 SF-33410/ FINLAND
ERKKI LEHTlMAKI/ OPISKELIJANK. 4A 20/ TAMPERE 72 SF-33720/ FINLAND/ 963-37141 (HOME)
MICHEL GALINIER/ INFORMATIQUE/ UNIVERSITE P. SABATIER/ 118 ROUTE DE NARBONNE/ TOULOUSE CEDEX F-31077/ FRANCE/ 16-61-53 11 20
PIERRE MAURICE/ INFORMATIQUE/ UNIVERSITE PAUL SABATIER/ 118 ROUTE DE NARBONNE/ TOULOUSE CEDEX F-31077/ FRANCE/ (61) 53 11 20 X300
ATTN: CENTRE DE RECHERCHE/ INFORMATIQUE ET GESTRON/ UNIV. DES SCIENCES ET TECH. DU LANCUED/ AVENUE D'OCCIREINE/ MONTPELLIER CEDEX F-34075/ FRANCE
633886
ATTN: A. D. R./ CHAMBRE DE COMMERCE ET D'INDUSTRIE/ 6 BOULEVARD GAMBETTA/ GRENOBLE F-38000/ FRANCE
ALAIN TISSERANT/ DEPARTENENT INFORMATIQUE/ ECOLE DES MINES/ PARC DE SAURUPT/ NANCY CEDEX F-54042/ FRANCE/ (28) 51 42 32
JACQUES FARRE/ INSTlTUT DE PROGRAMMATION/ T 55.65/ UNIVERSITE P. ET H. CURIE/ 4 PLACE JUSSlEU/ PARIS CEDEX 05 F-75230/ FRANCE/ 336 25 25 X58 77
ATTN: NIXDORF COMPUTER GMBH/ BEREICH ENTWICKLUNG/ ABT DOKUMENTATION/ KAISERIN-AUGUSTA-ALLEE 21/ BERLIN 21 D-1000/ GERMANY
H.-H. NAGEL/ INSTlTUT FUER INFORMATIK/ UNIVERSITAT HAMBURG/ SCHLUTERSTRASSE 66-72/ HAMBURG 13 D-2000/ GERMANY/ 040-4123-4151
BERNHARD NEBEL/ CLASINGSTRASSE 8/ HAMBURG 19 D-2000/ GERMANY/ 040/4913613
ATTN: INSTITUT FUER INFORMATIK/ UNIVERSITAT HAMBURG/ SCHLUETERSTRASSE 13/ HAMBURG 70 D-2000/ GERHANY
ROLF SONNTAG/ RICHARD WAGNER STR. 27/ HANNOVER 1 D-3000/ GERMANY
G. MARQUARDT/ REGIONALES RECHENZENTRUM/ WUNSTORFER STR. 14/ HANNOVER 91 D-3000/ GERMANY
HORST STENZEL/ RECHENZENTRUM/ UNIVERSITAT MUNSTER/ ROXELER STRASSE 60/ MUNSTER D-4400/ GERHANY
HENK JANSEN/ DIGITAL EQUIPMENT GMBH/ STOBERGER STR. 90/ KOLN 41 D-5000/ GERMANY/ (0221) 5486-1
GERHARD BLANKE/ POSTBOX 5107/ ESCHBORN D-6236/ GERMANY/ (06196) 403267
A. GEUBE/ ABTEILUNG BIOMATHEMATIK/ UNIVERSITAT GIESSEN/ FRANKFURTER STRASSE 100/ GIESSEN D-6300/ GERMANY/ 06 41-702/4855/56/57
ruu,S-WILM WIPPERMANN/ INFORMATIK/ F13/ UNIV. OF KAISERSLAUTERN/ PFAFFENBERGSTR. 95/ KAISERSLAUTERN D-6750/ GERHANY/ (0631) 8542635
KLAUS LAGALLY/ INSTITUT FUR INFORMATIK/ UNIVERSITAT STUTTGART/ AZENBERGSTRASSE 12/ STUTTGART 1 D-7000/ GERMANY/ (0711) 2078-373/329
ASHOK N. ULLAL/ GOETHESTR. 10/ KUSTERDINGEN D-7408/ GERMANY/ 07121/271446
KARLHEINZ KAPP/ ANGEW. INFORMATIK/ UNIVERSITAET KARLSRUHE/ TRANSPORT-U. VERKEHRSSYSTEME/ KARLSRUHE D-7500/ GERMANY/ (0721) 608-3170/3898
(07247) 823 928
GERHARD T. GOOS/ INSTITUT FUER INFORMATIK II/ UNIVERSITAT KARLSRUHE/ POSTFACH 6380/ KARLSRUHE 1 D-7500/ GERMANY/ (0721) 751-176
ULRICH KULISCH/ INSTITUT FUR ANGEWANDTE MATHEMATIK/ UNIVERSITAT KARLSRUHE (TH)/ KAISERSTR. 12 - POSTFACH 6380/ KARLSRUHE 1 D-7500/ GERMANY
(0721) 608-2680
AXEL T. SCHREINER/ SEKTION INFORMATIK/ UNIVERSITAET ULLU/ ULLU D-7900/ GER}1ANY/ 0711/176 2523
ATTN: BIBLIOTHEK/ LEIBNIZ - RECHENZENTRUM/ BARERSTRASSE 21/ MUENCHEN 2 D-8000/ GERHANY/ (089) 2105-8489
MANFRED LUCKMANN/ ALEMANNENSTR. 24/ MUENCHEN 90 D-8000/ GERMANY/ (089) 2105-8276
PETER RAUSCHMAYER/ HERZOG-GARIBALD-STRASSE 15/ MUENCHEN 90 D-8000/ GERMANY/ 647504
JAN WITT/ ZFE FL SAR/ SIEMENS AG/ POSTFACH 832729/ MUNCHEN 83 D-8000/ GERHANY/ (089) 722-22651
BERNHARD H. BEITINGER/ INDUSTRIEANLAGEN-BETRIEBSGESELLSCHAFT/ EINSTEINSTRASSE/ OTTOBRUN D-8012/ GERHANY/ 089/60082363
RAINER R. LATKA/ AN DER GRUNDBREITE 1/ WESSLING D-8031/ GERHANY/ 08153-1063
ATTENTION: N. V. KOTESWARA RAO/ COMPUTER TRG. UNIT/ ELECTRONICS CORPORATION OF INDIA/ HYDERABAD (AP) 500762/ INDIA/ 71611
DIARMUID MCCARTHY/ KILMACUD/ 7 ST. KEVIN'S PARK/ BLACKROCK CO. DUBLIN/ IRELAND
JOHN W. FINNEGAN/ SCHOOL OF ENGINEERING/ UNIVERSITY COLLEGE/ G ALWAY/ IRELAND
DAVID M. ABRAHAMSON/ DEPT. OF COMPUTER SCIENCE/ TRINITY COLLEGE/ 200 PEARSE ST./ DUBLIN 2/ IRELAND/ 772941 X1716 X1765
ATTN: THE LIBRARY/ MINISTRY OF DEFENCE/ P.O.BOX 962/ HAIFA/ ISRAEL
ATTN: PERIODICALS DEPT./ JEWISH NATIONAL AND UNIV. LIBRARY/ P.O. BOX 503/ JERUSALEN/ ISRAEL
GIDEON YUVAL/ COMPUTER SCIENCE/ THE HEBREW UNIVERSITY/ JERUSAL EN/ ISRAEL
M. E. RONCHI/ CENTRO DI CALCOLO/INTERUNIVERSITARIO/ VIA MAGNANELLI 6/3/ LECCHIO DIRENO BOLOGNA 1-40033/ ITALY/ 576541/ 576542
MAURO MONTESI/ TEMA S.P.A./ VIA MARCONI 29/1/ BOLOGNA 1-40122/ ITALY/ 051-267285
GUISEPPE SELVA/ TEMA S.P.A./ VIA MARCONI 29/1/ BOLOGNA 1-40122/ ITALY/ 051-267285
NOBUO WAKABAYASHI/ DEPT. OF MANAGEMENT SCIENCE/ OTARU UNIVERSITY OF COMMERCE/ 3-5-21 MIDORI/ OTARU HOKKAIDO/ JAPAN/ 0134-33-7227 (HOME)
HARUHISA ISHIDA/ COMPUTER CENTRE/ UNIVERSITY OF TOKYO/ 2-11-16 Yf.YOI/ BUNKYOKU TOKYO 113/ JAPAN/ 03-812-2111 X28ll
KOHEI NOSHITA/ 1-52-4 YOYOGI/ KHIBUYA-KU TOKYO 151/ JAPAN/ 03-370-8031
MASATO TAKEICHI/ DEPT. OF COMPUTER SCIENCE/ THE UNIV. OF ELECTRO-COMMUNICATIONS/ 1-5-1 CHOFUGAOKA/ CHOFU-SHI TOKYO 182/ JAPAN/ JAPAN 0424-83-2161 X525
NOBUKI TOKURA/ DEPT. OF INFORMATION AND COMPo SCIENCE/ OSAKA UNIV./ '1-1 MACHIKANEYAMA/ TOYONAKA 560/ JAPAN/ 06 (856) 1151 X3245
G. A. VIGNAUX/ DEPARTMENT OF INFORMATION SCIENCE/ VICTORIA UNIVERSITY OF WELLINGTON/ PRIVATE BAG/ WELLINGTON/ NEW ZEALAND/ 721-000
HARALD EIDE/ NORSK DATA A.S./ LORENVN. 57/ OSLO 5/ NORWAY/ 47 2 21 73 71/ 47 2 22 80 90
ATTENTION: E. N. VAN DEVENTER/ COMPUTING CENTRE/ NATIONAL RESEARCH INST FOR MATH SCIENC/ POBOX 395/ PRETORIA 0001/ SOUTH AFRICA/ 74-9111
MARTIN VERGES TRIAS/ CENTRO DE CALCULO UPB/ AV. DR. GREGORIO MARANON S/N/ BARCELONA 14/ SPAIN/ (93) 334.35.00
LUIS A. GARCIA-RAMOS/ E.S.A.D.E./ AV. VICTORIA 60/ BARCELONA 34/ SPAIN/ (93) 203 7800

N

00

$-000 00
5-100 44
oS-100 44
S-161 54
S-175 62
5-220 07
$-402 20
S-431 39
S-461 01
5-752 23
5-901 87
$-951 45
S-951 87
5-951 87
CH-1200
CH-8005
CH-8008
CH-8092
CH-9470

SWEDEN
SWEDEN
SWEDEN
SWEDEN
SWEDEN
SWEDEN
SWEDEN
SWEDEN
SWEDEN
SWEDEN
SWEDEN
SWEDEN
SWEDEN
SWEDEN
SWITZERLAND
SWITZERLAND
SWITZERLAND
SWITZERLAND
SWITZERLAND
THE NETHERLANDS
THE NETHERLANDS
THE NETHERLANDS
THE NETHERLANDS
THE NETHERLANDS
THE NETHERLANDS
UNITED KINGDOM
UNITED KINGDOM
UNITED KINGDOM
UNITED KINGDOM
AB9 2UB UNITED KINGDOM

AL10
BB7
BNl
BN1
BT7
eM17
CV4
eH10
EH5
EX4
E14
HA4
LA1
LA1
LA1
LA1
L69

9AB
4DZ
2GJ
9QT
INN
9NA
7AL
6NH
2XT
4Q6
6JG
9DP
1BA
4YN
4YW
4YX
3BX

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

M13 9PL UNITED KINGDOM
M60 1QD UNITED KINGDOM
M60 1QD UNITED KINGDOM
NW3 UNITED KINGDOM
SG2 9UT UNITED KINGDOM
S09 5NH UNITED KINGDOM
S09 5NH UNITED KINGDOM
SW7 2AZ UNITED KINGDOM
SW7
WC1H
Y01
630

2AZ
OPY
5DD
090

UNITED KINGDOM
UNITED KINGDOM
UNITED KINGDOM
USSR
~U-61000 YUGOSLAVIA
61001 YUGOSLAVIA

JOHN TIMOTHY FRANKLIN/ KRUKMAKERGATTAN 1/6/ STOCKHOLM S-OOO 00/ SWEDEN
STAFFAN ROMBERGER/ COMPUTER SCIENCE/ ROYAL INSTITUTE OF TECHNO LOGY/ STOCKHOLM S-100 44/ SWEDEN/ 08-787 7194
LARS-ERIK THORELLI/ DEPT. OF COMPUTER SYSTEMS/ THE ROYAL INSTI TUTE OF TECHNOLOGY/ STOCKHOLM 70 S-100 44/ SWEDEN/ SWEDEN-08-236520
CLAES RICKEBY/ HEDEBYVAGEN 5/ BROMMA S-161 54/ SWEDEN/ 08/37 65 37
NEIL T. KEANE/ 'SYSTEM DEVELOPMENT/ STANSAAB ELEKTRONIK AB/ VEDDESTAVAAGEN 13/ JAARFAALLA S-175 62/ SWEDEN/ 08/36 28 00
LENNERT BENSRYD/ LUNDS DATACENTRAL/ LUND UNIVERSITY/ BOX 783/ LUND S-220 07/ SWEDEN/ 046/12 46 20
AKE WIKSTROM/ DEPT. OF COMPUTER SCIENCES/ CHALMERS UNIV. OF TECHNOLOGY/ FACK/ GOTHENBURG 5 S-402 20/ SWEDEN
KURT FREDRIKSSON/ RINGLEKEN 7/ MOLNDAL S-431 39/'SWEDEN/ 4631- 41-04-15 (HOME)/ 4631-27 50 00-491 (OFFICE)
LARS G. MOSSBERG/ VOLVO FLYGMOTOR AB/ BOX 136/ TROLLHATTAN S-461 01/ SWEDEN/ (0520) 30900-287
OLLE OLSSON/ DEPT. OF COMPUTER SCIENCE:ADP/ UPPSALA UNIVERSITY / STUREGATAN 4B 1 TR/ UPPSALA S-752 23/ SWEDEN/ 018-138650
HANS WALLBERG/ UMDAL/ UMEA S-901 87/ SWEDEN/ 46-90 12 56 00
LARS LYSEN/ HAVSORINGSGRAND 11/ LULEA S-951 45/ SWEDEN/ (0920) 65515
JOHNNY WIDEN/ UNIV. OF LULEA/ FACK/ LULEA S-951 87/ SWEDEN/ (0920) 98000
HANS-KURT JOHANSEN/ UNIV. OF LULEAA/ LULEAA S-951 87/ SWEDEN/ (0920) 98000 X386
DAVID BATES/ 12 CHEMIN DE TAVERNAY/ 1218 GRAND SACONNEX/ GENEV A CH-1200/ SWITZERLAND/ 98-55-44/ 41-98-11
RAFAEL E. EGLOFF/ HONEYWELL BULL/SCHWEIZ AG/ HARDTURMSTRASSE 2 53/ ZURICH CH-8005/ SWITZERLAND/ (01) 44 49 40
URS R WYSS/ BLEULERSTRASSE 2/ ZURICH CH-8008/ SWITZERLAND/ 0041-22-28.79.61
NIKLAUS WIRTH/ INSTITUT FUER INFORMATIK/ ETH - ZENTRUM/ ZUERICH CH-8092/ SWITZERLAND
HELMUT SANDMAYR/ NEU-TECHNIKUM BUCHS/ BUCHS CH-9470/ SWITZERLAND/ CH-085/6 45 24
D. GOSMAN/ ZEEMAN LABORATORIUM/ UNIVERSITEIT VAN AMSTERDAM/ PLANTAGE MUIDERGRACHT 4/ AMSTERDAM/ THE NETHERLANDS/ 020-5222177
H. S. M. KRUYER/ DEPT. MSE/ KONINKLYKE/SHELL-LABORATORIUM/ BAD HUiSWEG 3/ AMSTERDAM/ THE NETHERLANDS
ATTN: I.W.I.S.-TNO/ POSTBUS 297/ KON. MARIALAAN 21/ DEN HAAG/ THE NETHERLANDS
ATTN: DSM/ CENTRAL BIBLIOTHEEK 4213.001/ CENTRAL LABORATORIUM/ P.O. BOX 18/ GELEEN/ THE NETHERLANDS
H. PAAS/ DEPT. OF SPACE RESEARCH/ UNIV. OF GRONINGEN/ P.O. BOX 800/ GRONINGEN/ THE NETHERLANDS/ 050-116662
J. D. ALANEN/ FREDERIK HENDRIKSTRAAT 112/ UTRECHT/ THE NETHERLANDS/ 030 + 520548
MAURICE O'FLAHERTY/ ANTRIM/ 444 MEVILLE GARDEN VILLAGE/ N,EWTOWNABBEY N. IRELAND/ UNITED KINGDOM
B. L. MARKS/ U.K. LABORATORIES/ IBM/ HURSLEY/ N.WINCHESTER ENGLAND/ UNITED KINGDOM
STEPHEN L. BREIBART/ EASTCOTE/ 12 ELM AVENUE/ PINNER MIDDLESEX/ UNITED KINGDOM
PETER J. BURNS DE BONO/ NEWFOUNDLAND HOUSE/ HUGH PUSHMAN COMPILERS/ THE QUAY/ POOLE ENGLAND/ UNITED KINGDOM/ (02013) 70510
DENIS M. WILSON/ DEPARTMENT OF COMPUTING SCIENCE/ UNIVERSITY 0 F ABERDEEN/ KING'S COLLEGE/ OLD ABERDEEN SCOTLAND AB9 2UB/ UNITED KINGDOM
0224 40241 X6418
JOHN w. LEWIS/ SCHOOL OF INFORMATION SCIENCES/ HATFIELD POLYTECHNIC/ P.O. BOX 109/ HATFIELD HERTS AL10 9AB/ UNITED KINGDOM/ 68100 X237
J. N. HARRISON/ MOSNA COTTAGE/ NEWEY - RIMINGTON/ N. CLITHEROE LANCS BB7 4DZ/ UNITED KINGDOM/ GISBURN 329
STEVEN PEMBERTON/ DEPT. OF COMPUTING AND CYBERNETICS! BRIGHTON POLYTECHNIC/ MOULSECOOMB/ BRIGHTON ENGLAND BN1 2GJ/ UNITED KINGDOM/ 693655 X2273
J. R. W. HUNTER/ SCHOOL OF ENGR. AND APPL. SCI./ UNIV. OF SUSSEX/ BRIGHTON SUSSEX BN1 9QT/ UNITED KINGDOM/ (0273) 66755 X146
JIM WELSH/ DEPARTMENT OF COMPUTER SCIENCE! QUEEN'S UNIVERSITY/ BELFAST N.IRELAND BT7 1NN/ UNITED KINGDOM/ (0232) 45133 X3221
DAVID FLOOD PAGE/ STANDARD TELECOMMUNICATIONS LABORATORI/ LONDON ROAD! HARLOW ESSEX CM17 9NA/ UNITED KINGDOM/,0279 29531 X345
RUTH RAYMOND! COMPUTER UNIT/ UNIV. OF WARWICK! COVENTRY ENGLAN D CV4 7AL/ UNITED KINGDOM
DAVID A. COOPER! FAIRMILEHEAD/ 52 SWAN SPRING AVENUE/ EDINBURGH SCOTLAND ER10 6NH/ UNITED KINGDOM
T. M. SPENCE/ SYSTEMSHARE LTD/ PILTON DRIVE/ EDINBURGH SCOTLAND EHS 2XT/ UNITED KINGDOM
D. R. ALLUU/ DEPT. OF PHYSICS/ UNIVERSITY OF EXETER/ EXETER ROAD/ EXETER ENGLAND EX4 4Q6/ UNITED KINGDOM
ISAMU HASEGAWA/ LUKE HOUSE/ 7 CANTON STREET/ LONDON ENGLAND E14 6JG/ UNITED KINGDOM/ 01/987-4612
ROBERT KIRKBY/ RUISLIP MANOR/ 44 WHITBY ROAD/ MIDDLESEX ENGLAND HA4 9DP/ UNITED KINGDOM
CHI-KEUNG YIP/ DEPT. OF COMPUTER STUDIES/ GILLOW HOUSE/ UNIVERSITY OF LANCASTER/ LANCASTER ENGLAND LA1 1BA/ UNITED KINGDOM/ (0524) 65201 EXT.4123
BOB E. BERRY! DEPT. OF COMPUTER STUDIES/ UNIVERSITY OF LANCAST ER! BAILRIGG/ LANCASTER ENGLAND LA1 4YN/ UNITED KINGDOU/ (0524) 65201 X4134
ATTN: USER SERVICES MANAGER/ COMPUTER SERVICES/ UNIV OF LANCAS TER/ LANCASTER ENGLAND LA1 4YW/ UNITED KINGDOM
BRIAN A. E. 11EEKINGS! DEPT. OF COMPUTER STUDIES/ UNIVERSITY OF LANCASTER/ BAILRIGG/ LANCASTER ENGLAND LA1 4YX/ UNITED KINGDOM/ (0524) 65201
K. C. MANDER/ DEPT. OF COMPo AND STAT. SCIENCE/ VICTORIA BUILD ING/ UNIV. OF LIVERPOOL/ BROWNLOW HILL/ LIVERPOOL ENGLAND L69 3BX/ UNITED KINGDOU
051-709-6022 X2022
SRISAK WATHANASIN! DEPT. OF COMPUTER SCIENCE/ THE UNIVERSITY/ }~CHESTER ENGLAND M13 9PL/ UNITED KINGDOM
ATTN: THE LIBRARIAN/ DEPT. OF COl~UTATION! UMIST/ P.O. BOX 88/ MANCHESTER ENGLAND M60 1QD/ UNITED KINGDOU/ 061-2363311 X2178
DEREK COLEMAN/ DEPT. OF COMPUTATION/ UNIV. OF MANCH. INST. OF SCI. & TECH/ P.O. BOX 88! MANCHESTER ENGLAND U60 1QD! UNITED KINGDOM/ 061-236-3311 X2341
H. J. ZELL! 14 KEMPLAY ROAD/ LONDON ENGLAND NW3/ UNITED KINGDOM/ (01) 435-9396
G. J. FREEMAN/ 125 WIGRAM WAY/ STEVENAGE HERTS SG2 9UT/ UNITED KINGDOM/ (0442) 42291 X330
J. E. AHERN/ MATHS DEPT/ THE UNIVERSITY! SOUTHAMPTON ENGLAND S09 5NH/ UNITED KINGDOM
M. EL-NAHAS/ MATHS. DEPT! UNIV. OF SOUTHAMPTON/ SOUTHAMPTON ENGLAND S09 5NH/ UNITED KINGDOM
ATTN: COMPUTING AND CONTROL COLLECTION/ LYON PLAYFAIR LIBRARY/ IMPERIAL COLLEGE/ 180 QUEENSGATE/ LONDON ENGLAND SW7 2AZ/ UNITED KINGDOM
(01) 589-5111 X2115
DAVID SLATER/ DEPT OF COMPUTING AND CONTROL/ IMPERIAL COLLEGE/ 180 QUEENSGATE/ LONDON ENGLAND SW7 2AZ/ UNITED KINGDOM/ 589-5111 X2722
I. D. GRAHAM/ INSTITUTE OF ARCHAEOLOGY/ 31-34 GUROON SQUARE/ LONDON ENGLAND WC1H OPY/ UNITED KINGDOM
D. G. BURNETT-HALL/ DEPARTMENT OF COMPUTER SCIENCE/ UNIVERSITY' OF YORK/ HESLINGTON/ YORK ENGLAND Y01 5DD/ UNITED KINGDOM/ ('0904) 59861 EXT.5641
S. POKROVSKY/ COMPUTING CENTRE/ USSR ACADEMY OF SCIENCES/ NOVOSIBIRSK 630 090/ USSR
BOSTJAN VILFAN/ FAKULTETA ZA ELEKTROTEHNIKO/ UNIVERZA V LJUBLJANI/ TRZASKA 25/ LJUBLJANA YU-61000/ YUGOSLAVIA
ROBERT REINHARDT/ INSTITUT JOZEF STEFAN/ UNIV. V LJUBLJANI/ JAMOVA 39! LJUBLJANA 61001/ YUGOSLAVIA/ 63-261

I-'
lD
'-J
00

N
lD

DAVID M. ABRAHAMSON
DAVID M. ADAMS
JAMES L. AGIN
J. E. AHERN
J. D. ALANEN
BOB ALBRECHT
R. A. ALLAN
D. R. ALLUM
STEPHEN R. ALPERT
JOHN ALSTRUP
DAVID B. ANDERSON
D. B. ANDERSON
GARY S. ANDERSON
ROBERT W. ANDERSON
RICHARD V. ANDREE
GEORGE W. ANTHONY
ROBERT L. ARGUS
PETER A. ARMSTRONG
JIM ARNOLD
LARRY ARONSON
ATTENTION: BOB JARVIS
ATTENTION: CHARLES PFLEEGER
ATTENTION: E. N. VAN DEVENTER
ATTENTION: J. M. KNOCK
ATTENTION: MARJORIE HEINE
ATTENTION: MIKE WILDE - CONSULTING OFF.
ATTENTION: N. V. KOTESWARA RAG
ATTN: A. D. R.
ATTN: A. S. WILLIAMS - LIBRARIAN
ATTN: BETTE BOLLING-LIBRARIAN
ATTN: BIBLIOTEKET
ATTN: BIBLIOTHEK
ATTN: CCIS LIBRARY HILL CENTER
ATTN: CENTRE DE RECHERCHE
ATTN: COMPUTER CENTER
ATTN: COMPUTER SCIENCE DEPARTMENT
ATTN: COMPUTING AND CONTROL COLLECTION
ATTN: COMPUTING SERVICES
ATTN: DEPT. OF COMPUTER SCIENCE
ATTN: DIRECTOR / INST. RESEARCH
ATTN: DSM
jlT1N: EARL L. MOUNTS-COMP. SCI. LIBRARIAN
ATTN: ELAINE DENTON (41-41)
ATTN: ENGINEERING LIBRARY
ATTN: ENGINEERING LIBRARY
ATTN: INSTlTUT FUER INFORMATIK
ATTN: INST. FUER INFORMATIONSSYSTEME
ATTN: I.W.I.S.-TNO
ATTN: J. F. MCINTYRE - LIBRARIAN
ATTN: KHK
ATTN: LIBRARIAN
ATTN: LIBRARY
ATTN: L. LAWRIE
ATTN: L.A.M.B.D.A.
ATTN: MANUFACTURING COMPUTER GROUP
ATTN: NEWBERRY MICRO SYSTEMS
ATTN: NIXDORF COMPUTER GMBH
(frTN : OREGON MINI-COMPUTER SOFTWARE INC.
ATTN: PERIODICALS DEPT.
ATTN: SERIALS DEPARTMENT
ATTN: THE LIBRARIAN
ATTN: THE LIBRARY
ATTN: USER SERVICES MANAGER
THOMAS M. ATWOOD
DAVID AULT
DENNIS R. AUSTIN

2 IRELAND
19301
90278
S09 5NH UNITED KINGDOM
THE NETHERLANDS
94025
N6A 4N5 CANADA
EX4 4Q6 UNITED KINGDOM
01609
55420
18015
94010
98043
92680
73019
83316
47805
98109
66045
10027
55455
37916
0001 SOUTH AFRICA
60439
17837
61801
500762 INDIA
F-38000 FRANCE
92626
45036
DK-2200 DENMARK
D-8000 GERMANY
08854
F-34075 FRANCE
79409
84112
SW7 2AZ UNITED KINGDOM
55105
SF-00100 FINLAND
95521
THE NETHERLANDS
15213
90406
98401
95014
D-2000 GERMANY
A-1040 AUSTRIA
THE NETHERLANDS
22903
55414
3052 AUSTRALIA
94720
61820
02912
97077
94022
D-1000 GERMANY
97221
ISRAEL
2308 AUSTRALIA
M60 1QD UNITED KINGDOM
ISRAEL
LA1 4YW UNITED KINGDOM
02165
20041
93105

MARGERY AUSTIN
20036
DAVE BAASCH
94707
RON BAECKER M4Y IP9 CANADA
SAMUEL T. BAKER
37130
MICHAEL S. BALL
92152
CHARLES J. BANGERT
66045
PAUL BARR
01778
BRUCE BARRETT
94404
ROGER R. BATE
75023
DAVID BATES CH-1200 SWITZERLAND
FRANK J. BATES JR.
43403
JOHN C. BEATTY N2L 3Gl CANADA
o. BEAUFAYS
B-1050 BELGIUM
E. R. BEAUREGARD
17019
MICHAEL A. BEAVER
53149
MICHAEL BEHAR
06477
BERNHARD H. BEITINGER
D-8012 GERMANY
LENNERT BENSRYD S-220 07 SWEDEN
PAUL C. BERGI1AN
21793
BOB E. BERRY LAI 4YN UNITED KINGDOM
EASTON BEYMER
77341
GERHARD BLANKE
D-6236 GERMANY
I. N. BLAVINS
5063 AUSTRALIA
ROY E. BOLLINGER
94088
JOHN H. BOLSTAD
32306
KEN BOWLES
92093
ALEX BRADLEY
92714
STEVEN L. BRECHER
90803
DAVID E. BREEDING
75229
STEPHEN L. BREI BART
UNITED KINGDOM
C. E. BRIDGE
19898
PER BRINeH HANSEN
90007
CHARLES L. BROOKS
02139
PAUL H. BROOME
21010
WARREN R. BROWN
02035
ANNA BUCKLEY
47401
A. CHARLES BUCKLEY
40205
D. G. BURNETT-HALL Y01 5DD UNITED KINGDOM
PETER J. BURNS DE BONO
UNITED KINGDOM
JAMES W. BUTLER
62901
CARROLL E. BUTTERFIELD
94804
BETTY BUXTON
03060
JOHNNIE BUZEK JR.
77005
J. A. CAMPBELL
2308 AUSTRALIA
SAM CARPENTER
01960
PAULO S. CASTILLO JR.
91360
DAVID F. CAUTLEY
97330
JOE CELKO
30310
W. B. CHAPIN
55112
KENNETH E. CHARLTON
98033
ROBERT L. CHEEZEM JR.
32935
HARRY R. CHESLEY
94801
BILL CHESWICK
18938
STEPHEN W. CHING
19085
TONY CHMIEL
60652
LEO CHRZANOWSKI
14072
JOHN CLARSON
23669
GEOFFREY A.• CLEAVE
3165 AUSTRALIA
GERHARDT C. CLEMENTSON
80204
DAVID CLINGERMAN
94563
WILLIAM L. COHAGAN
78758
ROBERT COLE
18017
DEREK COLEMAN M60 1QD UNITED KINGDOM
GRANT COLVIN
75062
JOHN S. CONERY
92714
WILLIAM S. COOKE
90402

DAVID A. COOPER EHI0 6NH UNITED KINGDOM
ARDON R. CORD
95014
JOHN DENNIS COUCH
95050
JAMES C. COZZIE
52402
LAWRENCE F. CRAM
02159
JOHN EARL CRIDER
77043
LINDA E. CROLEY
94304
DONALD B. CROUCH
35486
ARTHOR C. DARTT
44115
HENRY DAVIS
22090
LEO DAVIS
20770
ITINE DE GERLACHE
B-ll80 BELGIll1
JOHN DE PILLIS
92507
JOHN DE ROSA JR.
01545
JOHN R. DEALY
90278
JAN DEDEK
94301
ROBERT I. DEMROW
01810
PETER DEWOLF
61820
GEORGE B. DIAMOND
08826
ROBERIO DIAS M5P 2C3 CANADA
RICHARD DIEVENDORFF
91203
JOHN G. DOBNICK
53219
BILL DODSON
93017
JOHN DOERR
95051
HICHAEL K. DONEGAN
23185
G. KEVIN DOREN
19101
KENNETH R. DRIESSEL
74102
WILLIAM E. DROBISH
92714
KENNETH R. DUCKWORTH
71201
C. E. DUNCAN
94303
GARY DUNCAN
92680
FRANK DUNN
75081
WILLIAM J. EARL
92715
RAFAEL E. EGLOFF CH-8005 SWITZERLAND
HARALD EIDE
NORWAY
FRED EILENSTEIN
02172
JOSEPH EINWECK
88003
JOHN D. EISENBERG
19711
M. EL-NAHAS S09 5NH UNITED KINGDOM
RANDY ENGER
01776
DONALD L. EPLEY
52242
HOWARD D. ESKIN
10025
JOHN B. EULENBERG
48824
JACQUES FARRE F-75230 FRANCE
MICHAEL FAY
95064
WALT FEESER
92127
ROBERT B. FINCH
98225
DONNAFAYE FINGER
98040
JOHN W. FINNEGAN
IRELAND
WILLIAM E. FISHER
90501
W. J. G. FISHER
4001 AUSTRALIA
DAVID C. FITZGERALD
92704
JOHN FITZSIMMONS
55436
KEVIN FJELSTED
55455
READ T. FLEMING
02912
RUDY L. FOLDEN
92713
JIM FONTANA
92704
DOUG FORSTER
09098
CHARLES H. FORSYTH N2J 4H2 CANADA
ROBERT A. FRALEY
94304
JOHN TIMOTHY FRANKLIN S-OOO 00 SWEDEN
KURT FREDRIKSSON S-431 39 SWEDEN
G. J. FREEMAN SG2 9UT UNITED KINGDOM
DAVID F. FRICK
94546
EDWARD R. FRIEDMAN
10012
JOHN FRINK
21045

"

::t:>
C/)

n
::t:>

r
Z

rtl

:e:
C/)

""'"

i--'

......

-n
rtl

to
:::0

=

:l>

=

-<

i--'
LO

'-I

0.')

-0

:l>
G'l

rtl

V\l
0

85016
ROBERT FULKS
MICHEL GALINIER F-31077 FRANCE
I. GANAPATHY V6X 2Z9 CANADA
34 SPAIN
LUIS A. GARCIA-RAMOS
EDWARO F. GEHRINGER
47907
PAULETTE D. GENES
55455
W. MORVEN GENTLEMAN N2L 3G1 CANADA
TONY J. GERBER
2006 AUSTRALIA
DANIEL E. GERMANN
55435
13201
J. DANIEL GERSTEN
A. GEUBE
D-6300 GERMANY
ROBERT A. GIBSON
22901
R. STEVEN GLANVILLE
95051
94521
PAUL GODFREY
98195
HELLMUT GOLDE
RALPH S. GOODELL
01451
D-7500 GERMANY
GERHARD T. GOOS
KEITH E. GORLEN
20014
THE NETHERLANDS
D. GOSMAN
P. K. GOVIND
80303
SARA K. GRAFFUNDER
55455
I. D. GRAHAM WC1H OPY UNITED KINGDOM
DOUGLAS M. GRANT
06901
MARK GREEN M4B 2E5 CANADA
MIKE GREEN
78284
TOM GREER
91775
WILEY GREINER
90278
DAVID B. GROUSE
15213
RONA GURKEWITZ
06810
ROBERT D. GUSTAFSON
60657
STEVEN B. HALL
44107
TERRY HAMM
97077
TIMO HAMMAR SF-33410 FINLAND
2600 AUSTRALIA
N. D. H. HAMMOND
BRIAN HANSEN
97213
ANDY HARRINGTON
931ll
WILLIAM J. K. HARRINGTON
08618
MIKE HARRIS
62704
J. N. HARRISON BB7 4DZ UNITED KINGDOM
ISAMU HASEGAWA E14 6JG UNITED KINGDOM
S. HAYES
33313
GEORGE E. HAYNAM
32901
PETER HAYNES L5N 1KT CANADA
STAN HEAD
95030
HARRY G. HEDGES
48824
CHARLES HEDRICK
08903
S. T. HEIDELBERG
94550
JOHN M. HEMPHILL
43403
CHRISTOPHER J. HENRICH
07724
CARL HENRY
55057
WILLIAM HENRY
10003
MARK HERSEY
48100
H. F. HESSION
22101
CHARLES L. HETHCOAT I I I
77027
J Il1 HIGHTOWER
90274
BUZZ HILL
98632
KEARNEY HILL
67401
CATHLINE S. HILLEY
58201
MARK HIPPE
19087
G. STEPHEN HIRST
52240
PHILIP T. HODGE
46375
THEA D. HOpGE
55455
D. P. HODGSON
6102 AUSTRALIA
RANDY HODNETT
97077
TIMOTHY W. HOEL
55057
14454
ANTHONY E. HOFFMAN

BOB HOFKIN
DAVID W. HOGAN
MARGARETTA HOMMEL
BRYAN HOPKINS
C. L. HORNEY
ROSS F. HOUSHOLDER
CAROL B. HOWELL
J. R. W. HUNTER
BOB HUTCHINS
WILLIAM G. HUTCHISON JR.
STEVEN L. HUYSER
JOHN W. IOBST
HARUHISA ISHIDA
KENNETH R. JACOBS
ROBERT C. JANKU
HENK JANSEN
GUNNAR JOHANSEN
HANS-KURT JOHANSEN
GREG JOHNS
JOSEPH N. JOHNSON
JOSEPH P. JOHNSON
R. WARREN JOHNSON
ANN C. JOHNSTON
D. B. JOHNSTON
DAVID JONES
ERNEST W. JONES
NORMAN A. JULL
MARK JUNGWIRTH
KARL HEINZ KAPP
MATTI KARINEN
MILAN KARSPECK
ARMED KASSEM
ROBERT KAST
ED KATZ
NEIL T. KEANE
TOM KEEL
DONALD A. KEFFER
PAUL KELLY
TOM KELLY
GREG KEMNITZ
WILLETT KEMPTON
DENIS KERMICLE
JUKKA KESO
GURUPREM SINGH KHALSA
B. KIDMAN
RICHARD B KIEBURTZ
DANIEL B. KILLEEN
ROBERT KIRKBY
PAUL S. KLARREICH
JON G. KLASEN
DONALD B. KLEIN
STEPHEN KLEIN
BARCLAY R. KNERR
JOHN C. KNIGHT
PAUL KOHL BRENNER
DIANE L. KRAMER
RICHARD KRASIN
JAMES KREILICH
H. S. M. KRUYER
ULRICH KULISCH
KLAUS LAGALLY
R. B. LAKE
DAN LALIBERTE
LARRY D. LAND IS
DAVID LANDSKOV
ROBERT G. LANGE

92093
78731
01701
02154
92803
76012
20770
BN1 9QT UNITED KINGDOM
92713
08512
48824
18049
113 JAPAN
20006
22003
D-5000 GERMANY
DK-2800 DENMARK
S-951 87 SWEDEN
97077
94701
20016
56301
44691
4067 AUSTRALIA
L5N 1KT CANADA
94901
M4N 1A4 CANADA
92644
D-7500 GERMANY
SF-33101 FINLAND
91104
50011
07054
55112
S-17562 SWEDEN
78712
19438
92714
19335
55391
94720
32905
SF-33101 FINLAND
91101
5001 AUSTRALIA
11794
70118
HA4 9DP UNITED KINGDOM
11210
55404
19010
01741
92646
23665
06437
65201
01886
55108
THE NETHERLANDS
D- 7 500 GERMANY
D-7000 GERMANY
44106
55455
64108
70504
55343

D-8031 GERMANY
RAINER R. LATKA
60201
ARNOLD LAU
ROBERT A. LAWLER
55165
TERRY J. LAYMAN
90405
HENRY F. LEDGARO
01002
K. P. LEE
70803
SF-33720
FINLAND
ERKKI LEHTIMAKI
MIKE LEMON
84112
GEORGE LEWIS
94086
H. MARC LEWIS
97401
JOHN W. LEWIS AL10 9AB UNITED KINGDOM
BOB LIDRAL
61801
GEORGE LIGLER
75081
MOGENS LINDHARO DK-1051 DENMARK
LEN LINDSAY
53719
GARY LINDSTROM
84112
PETER LINHARDT
94709
BRUCE LINK
87115
RICHARD LLEWELLYN
21045
CARLO LOCICERO L4W 1TO CANADA
KENT LOOBEY
97440
ANDY LOPEZ
56267
GARY LOWELL
95404
TIM LOWERY
92627
HOUSTON P. LOWRY
99258
D~8000 GERMANY
MANFRED LUCKMANN
FRED LUHMANN
02138
STANLEY E. LUNDE
91711
JOHN LUSHBOUGH
57069
WILLIAM LYCZKO
14850
LARS LYSEN S-951 45 SWEDEN
ROBERT N. MACDONALD
30303
RON MARON
15461
K. C. MANDER L69 3BX UNITED KINGDOM
DOUGLAS MANN
30339
DAN MARCUS
92807
RICK L. MARCUS
55404
BARRY F. MARGOLIUS
01701
B. L. MARKS
UNITED KINGDOM
G. MARQUAROT
D-3000 GERMANY
LYNN S. MARTIN
11439
GEORGE MASSAR
91367
CHARLES MATTAIR
77801
STEVE MATUS
33313
PIERRE MAURICE F-31077 FRANCE
KONRAD MAYER
A-1l50 AUSTRIA
JOHN K. MCCANDLISS
63188
DlARMUlD MCCARTHY
IRELAND
JOEL MCCORMACK
92014
RAINER F. MCCOWN
21045
TIMOTHY DAVID MCCREERY
94702
MAURICE MCEVOY
94708
HENRY MCGILTON L5N 1K7 CANADA
JOHN P. MCGINITIE
94701
JAMES P. MCILVAINE IV
19044
MICHAEL MCKENNA
03755
RON MCKERRON M9W 5R8 CANADA
JACK R. MEAGHER
49008
ROB MEANS
95035
TERRY P. MEDLIN
20014
BRIAN A. E. MEEKINGS LA1 4YX UNITED KINGDOM
HUGO MEISSER
55427
L. F. MELLINGER
91405
STEPHEN F. MERSHON
22901
W. J. MEYERS
27709
M. D. MICKUNAS
61801

-C

:l>

c.n
n
:l>

r
z
rr1

::::
c.n

""*'

I--'
I--'

""Tl

rr1
t:t:J

:::c

=

):>

?C

-<
I--'
LO
'-I

00

-c
:l>

'"
rr1
\.N
I--'

FRED J. MILLER
JAMES S. MILLER
JOHN C. MILLER
ROBERTO MINIO
KEITH MITCHELL
JESSE D. MIXON
UFFE MOLLER
MAURO MONTESI
RODERICK MONTGOMERY
CHARLES G. MOORE
JAMES K. MOORE
TOM MORAN
CARROLL MORGAN
R. A. MORRIS
HERBERT E. MORRISON
DAN MORTON
WILLIAM MOSKOWITZ
LARS G. I~SSBERG
JOHN M. MOTIL
STEVEN S. MUCHNICK
DENNIS J. MURPHY
TERRY MYHRER
H.-H. NAGEL
BERNHARD NEBEL
LEROY E. NELSON
RICHARD E. NEUBAUER
ROBERT C. NICKERSON
R. KEITH NICKEY
DENNIS NICKOLAI
KOHEI NOSHITA
RHODA P. NOVAK
ROBERT E. NOVAK
TOM NUTE
ROBERT J. OBERG
FLEMING M. OLIVER
GARY OLIVER
OLLE OLSSON
DICK OSGOOD
MAURICE O'FLAHERTY
STEVE O'KEEFE
GARYO 0' SCHENECTADY
H. PAAS
HAL PACE
DAVID FLOOD PAGE
WILLlAU S. PAGE
DONALD L. PARCE
CRAIG PAYNE
DAVE PEERCY
STEVEN PEMBERTON
WALT PERKO
DAVID PERLMAN
ROBERT D. PERRY JR.
W. J. PERVIN
DAVID PESEC
MIKE D. PESSONEY
BOB PETERSON
DAVID L. PETERSON
TRUMAN C. PEWITT
FRANCOIS PINARD
ALAIN PIROTTE
RICHARD PITKIN
TOM PITTMAN
S. POKROVSKY
BARY W. POLLACK
UDO POOCH
JERRY POURNELLE

DARRELL PREBLE
30303
99210
BILL SHANNON
44116
MICHAEL PRIETULA
55455
02138
TED SHAPIN
92669
BOB PUETTE
95014
02165
ED SHARP
84112
HOWARD D. PYRON
65401
10010
ROBERT LEE SHARP
22042
3072 AUSTRALIA
27409
M. RAHILLY
TOM TYSON
98008
DAVID ELLIOT SHAW
94306
D-7408 GERMANY
ASHOK N. ULLAL
EARL RALEY
19122
75961
JOHN M. SHAW
20014
TIM RAND
06268
10012
ANDREW P. VALENTI
DK-9220 DENMARK
BELLE P. SHENOY
55413
3000 AUSTRALIA
V. LALITA RAO
19440
Q. VAN ABBE
1-40122 ITALY
THOMAS E. SHIELDS
77005
PETER RAUSCHMAYER
D-8000 GERMANY
WARREN VAN CAMP
95005
08876
E. E. SIMMONS
91101
68154
JERRY L. RAY
23508
FRANCES L. VAN SCOY
48106
P. SIMON
2308 AUSTRALIA
LEONARD VANEK MSS lA4 CANADA
RUTH RAYMOND CV4 7AL UNITED KINGDOM
22091
JON SINGER
60660
WILLIAM J. VASILIOU JR.
03824
JEFFERY
M.
RAZAFSKY
64108
45036
SEYMOUR SINGER
92634
BILL VELMAN
92110
EDWARD K. REAU
53705
2006 AUSTRALIA
JORMA SINNAMO SF-33200 FINLAND
STEVEN A. VERE
60181
DAN
REED
72554
73019
CHARLES SISKA JR.
90250
G. A. VIGNAUX
NEW ZEALAND
C. EDWARD REID
32303
90266
ALAN E. SKIDMORE
66506
BOSTJAN VILFAN YU-61000 YUGOSLAVIA
61001 YUGOSLAVIA
ROBERT REINHARDT
19046
DAVE SKINNER
90801
VEIKKO VISALA SF-33340 FINLAND
STEVEN A. REISMAN
55455
90036
DAVID SLATER SW7 2AZ UNITED KINGDOM
ROGER A. VOSSLER
90278
3052 AUSTRALIA
PETER RICHARDSON
S-461 01 SWEDEN
ERIC SMALL
94109
WAYNE VYROSTEK
97077
16057
PETER RICHETTA
91330
LARRY W. SMI TH
55337
M.
WAITE
11740
CLAES RICKEBY S-161 54 SWEDEN
66045
JON A. SOLWORTH
10011
WILLlAU
M.
WAITE
80309
20375
PETER A. RIGSBEE
02138
ROLF SONNTAG
D-3000 GERMANY
NOBUO WAKABAYASHI
JAPAN
48824
MARK RIORDAN
55066
BILL SOUTHWORTH
02132
HAN S WALLBERG S-901 87 SWEDEN
30303
MORRIS W. ROBERTS
D-2000 GERMANY
JOHN H. SPANTON
95133
BOB WALSH
87106
10573
D-2000 GERMANY
TIMOTHY P. ROBERTS
T. M. SPENCE EH5 2XT UNITED KINGDOM
PATRICK WARD H3C 3J7 CANADA
91601
90066
LARRY ROBERTSON
PAUL SPRECHER
10024
DONALD WARREN
10024
14127
D. H. SPRINGER
53201
F. DOUGLAS ROBINSON
95131
MARK S. WATERBURY
22152
40217
TOM SPURRIER
32901
94611
MICHAEL P. ROBINSON
STEPHEN B. WATERS
13440
20855
MARK STAHLMAN
BOB ROGERS
10019
80303
SRISAK WATHANASIN M13 9PL UNITED KINGDOM
95120
F. STANLEY
98926
THOMAS A. ROLANDER
55437
JOHN A. WEAVER
18042
01730
JORGEN STAUNSTRUP
ROGER D. ROLES
90007
151 JAPAN
NEIL W. WEBRE
93407
11794
GENE ROLLINGS
ROBERT L. STEELE I I
22101
91307
KEVIN WEILER
15213
STAFFAN ROMBERGER S-100 44 SWEDEN
EDWARD STEEN
01852
60148
LEONARD H. WEINER
79409
M. E. RONCHI 1-40033 ITALY
GERALD STEINBACK
44106
94086
DAVID H. WELCH
92324
55455
J. B. ROSEN
JAMES STEINBERG
02142
01701
ROBERT
E.
WELLS
02138
47907
SAUL ROSEN
HORST STENZEL
94086
D-4400 GERMANY
JIM WELSH BT7 INN UNITED KINGDOM
94035
TURNEY C. STEWARD
CARL S. ROSENBERG
97330
94112
JOHN WERTH
89154
80004
RAYNER K. ROSICH
JIM STEWART
S-752 23 SWEDEN
08854
GREGORY F. WETZEL
66045
20784
EDWARD D. ROTHE
JOHNNY STOVALL
06520
01581
TERRY
E.
WEYMOUTH
60532
97229
UNITED KINGDOM
DAVID ROWLAND
JEFFREY D. STROOMER
19341
NORMAN
D.
WHALAND
10009
14226
STUART W. ROWLAND
CONRAD SUECHTING
20229
74145
WILLIAM A. WHITAKER
22209
2006 AUSTRALIA
BRIAN G. ROWSWELL
JERRY S. SULLIVAN
12210
10510
JAMES D. WHITE
73019
87115
NANCY RUIZ
MARKKU SUNI SF-20500 FINLAND
THE NETHERLANDS
JOHNNY WIDEN S-951 87 SWEDEN
5098 AUSTRALIA
DENNIS SUTHERLAND
CHRIS A. RUSBRIDGE
52302
07470
AKE WIKSTROM S-402 20 SWEDEN
90733
PAUL RUSSELL
DAVID TAFFS
02840
CM17 9NA UNITED KINGDOM
E. HAROLD WILLIAMS
95050
55112
MARK RUSTAD
MASATO TAKEICHI
182 JAPAN
19711
DENIS M. WILSON AB9 2UB UNITED KINGDOM
92634
WALTER R. RYPER
RAUON TAN
10016
27607
RICHARD M. WILSON
85001
21235
LESTER SACHS
JANET TAYLOR
75275
18015
STERLING WILSON
91342
7001 AUSTRALIA
MICHAEL TEENER
87106
A. H. J. SALE
90403
GREG WINTERHALTER
48104
ROBERT R. TEISBERG
BN1 2GJ UNITED KINGDOM
55455
64108
TIMOTHY J SALO
F. S. WINTERSPRING K2A IT2 CANADA
DANIEL THALMANN
55414
75080
QUEBEC CANADA
E. J. SAMM:lNS
NIELS WINTHER DK-2650 DENMARK
55427
DAVID A. THOMAS K1S 5B6 CANADA
HELMUT SANDMAYR CH-9470 SWITZERLAND
HANS-WILM WIPPERMANN
D-6750 GERMANY
97201
06106
RICHARD T. THOMAS
43403
A. E. SAPEGA
NIKLAUS WIRTH CH-8092 SWITZERLAND
75235
TERRY THOMAS
97077
95030
LYNN SAUNDERS
JAN
WITT
D-8000 GERMANY
44119
KIRK D. THOMPSON
85282
47401
ANTHONY J. SCHAEFFER
JAY WOODS
83639
35805
LARS-ERIK THORELLI S-100 44 SWEDEN
55343
ROSS D. SCHMIDT
PAUL J. OOZNIAK
56569
55418
CLIFTON CHANG-CHAO TING
19151
92705
MARK M'. S CHNEGG
URS R WYSS CH-8008 SWITZERLAND
55429
ALAIN TISSERANT F-54042 FRANCE
55455
G. MICHAEL SCHNEIDER
CHI-KEUNG YIP LA1 1BA UNITED KINGDOM
NOBUKI TOKURA
22180
560 JAPAN
92335
WALLY SCHNITGER
KENNETH YOUNG
90020
HOWARD E. TOMPKINS
H3S 1J6 CANADA
15701
D-7900 GERMANY
AXEL T. SCHREINER
GIDEON YUVAL
ISRAEL
B-1170 BELGIUM
JOE TORZEWSKI
46530
11756
ROBERT SCHUTZ
H. J. ZELL
NW3 UNITED KINGDOM
02114
LARRY E. TRAVIS
017.52
53706
CARL W. SCHWARCZ
PAUL ZILBER
11797
95153
19898
MARTIN VERGES TRIAS
14 SPAIN
STEPHEN C. SCHWARM
MARK ZIMMER
94704
47907
ROBERT TROCCHI
630 090 USSR
01754
ALLAN M. SCHWARTZ
ANDREW HARRIS ZIMMERl1AN
94086
V6T 1 W5 CANADA
91126
JOHN TUCKER
79601
LARRY SEILER
KARL 1. ZINN
48104
JOHN TUCKER
77843
88047
GUISEPPE SELVA 1-40122 ITALY
91604
JYRKI TUOMI SF-33101 FINLAND
08077
FOREST VAN SISE SHAFER

V
):>

en

n
):>

r
Z

rn
:r:
en
=!;:;

f-'
f-'

"rn
t:t:1

;::c

=

):>

::>::l

-<
........
LO

'.J
00

-0
):>

'"
rn
vI
N

TYPE COMPATIBILITY CHECKING IN PASCAL COMPILERS

Tne conditions that satisfy SRTCCO have already been stated 4 : two variables
are considered as belonging to (being of) the same type if and only if they
are declared using the same named type,

Introduction

Val!

It is imperative we clearly set down the semantics of type compatibility for structured variables in the programming language Pascal. The
matter in urgent since the lack of an explicit set of rules in that sense has already given rise to some incompatibilities resulting from the
use of different Pascal compilers.

Or, the basis of how a compiler implements type compatibility checking,
we can currently distinguish two majo:r classes of Pascal compilers,
represento.tives of which will react differently t::> :>articulo.r cases involving operations on structured variables. It is of course clear that
such a conflict must not be allowed to continue, and in that sense I will
try to explain how the two classes of compilers came into being and also

present the reader with a few examples to display the consequences.

a.: IU:tjpeA-d;

b: IU:tjpeA-d

or their associated identifiers both appear in the same list.
VM

a., fl:

MJUtL{

[1..10] £i ,:,ometype

On tile other hand, what Vie know of SRTCCI Kas picked up in the source text
of t"e compiler itself since we could not find such information elsewhere.
In general, the conditions that sa::isfy SRTCCI are based on the principle
that: !>10 variables are considered as belonging to the same type if and
only if the data structure(s) implementing their respective type are
"identical". To know what "identical'! really means, one has to refer to

the source text of the compiler (as we did) and understand how the Boolean
function COMPTYPES works.
We purposely omitted to display the source text of that function here for
two reasons: I autOJ!'.atically inhericed a new set
of rules (lets call this one SRTCCl).
The whole happening went by almost unnoticed because no one had mentioned
the change in policy. Even in the recent Pascal User's Manua1 3 , I:ill react differently if they enforce different
sets of rules for type compatibility checking. A compiler u~:ng SP.TCCO will
reject the st3.tement on a type-check error, while ariother e;lforcing SRTCCI
let it go by ~'lhitout utt.ering a lztter, sinc~ both named types are implemented usi.llg the same data structvre: a 1te.c..OfT..d structure ha.vtng two fields of

\'-7il~

The problem now, is that in the area of type compatibility checking,
representatives of both classes of compilers are not fully compatible. That
means that in particular situations, a compiler enforcing SRTeCO will reject
a statement on a type-check error while another compiler enforcing SRTCCI
\~ill

accept it..

Articles

t)'"]Je real.
CUT second example shows hO\'1 enforcin.g SRTCCI can sometimes lead to 5 ide
effects \.,rhich can be disastrous. Even if the examnle below is 92..sed on the

particular behavior of a given compiler, it should be easy for 1:he readcl· to
imagine th~ various related pitfalls ~ can accidentally stumble _cnto., Consider the following declarations:

ttl
:;:0

=
:t>
:;:0

-<

Articles

It was our intention to make every "pas caler" aware of the importance that

lies in precisely stating tli.e semantics of type compatibility for structured
variables. It is our hope that other opinions make themseh'es be heard.

,..J • lLec.olUi

In any event, bear the following thought in mind: making a programming language a better tool to work with, can sometimes be acheived by lowering its
level of permissiveness.

---x;tj: 1le.a:1.
end;

1l2 .. Ilecolu:l
---x:.:te.a:1.;

y: Ileal.

end;
VaIL

REFERENCES

b: 112

1.1.: 1t1;

Pascal 6000, distribution version: IS. Feb. 1972.

In the lattest release of the Pascal compiler for CDC machines, memory cells
corresponding to record fields declared in the same list, are allocated in
the reverse order of appearance of the field identifiers. Whether i t be an
involuntary omission or a voluntary simplif~cation of compiler code, the
underlying assumption that a user does not care about how the memory cells
are allocated to his record components, is certainly debatable. All of this
however should have no ill-effects on program execution; but because of the
fact that the considered compiler enforces SRTCCl, things do not come out
that way. To start with, the assignment statement "a.:: b" is accepted as
legal. Furthermore, because of the peculiar allocation scheme described
above, the execution of the assignment statement turns out to correspond
to the following assignments "a.. x:: b.y;
a..y:: b. x"!

Pascal 2 (i.e. Pascal 6000-3.4), distribution version: May 1974.
Jensen K., Wirth N., uPascal User Manual and Report", Lecture Notes in
Computer Science, No. 18, SpringeT-Verlag, 1974.
"Restrictions of Pascal 6000", distribution document, IS Feb. 1972.

..,.,

As a starting point for our last example, we quote from Wirth &Jensen's
Pascal user manual: "Semantically, a subrange type is an appropriate substitutio~or the associated scal~r type in.all definit~o~s. Furthermore, it
is the associated scalar type l~hlCh determInes the vahdIty of all operatIons
involving valUeS of subrange types."

it is our

intentio~

to e;-::amine some

of the conseqto.ences ~f the first pCi.rt of the quo!:.c, in rel(i.tion tv the type
compatibility of structured variables.
ValL

-

11

rn

Pierre Desjardins
Departement d'Informatique et de
Recherche Operationnelle
Universite de Montreal
Quebec

n

ttl
;;0

=

):>

;;0

-<

(* Received 77/10/18 *)

hroup
a.: a/limy (1 .. 10]
ln1:egeJl;
b: MIlay [1 .. 10J a 0 .. 511;
c.: MIlay [1 .. 10] 0
0 •• 255;

***

{group 2}
d: pa.c.~e:~ MMy (J . . 5J £i 0 .. 511;
e:.: ~c. e MMy [J .. 5J £i O•• 255;
6: ~ MMy [1 .. 5] £i -128 .. 127
According to SRTCCO, all the variables declared above are pairwis~ t~e incompatible. Under SRTCCI however, variables of group 1 are all paIrwIse compatible while in group 2, only the pair
is compatible (as obtained when
compiled by a CDC ·Pascal 2 compiler). The incompatibilities in group :2 stern
only from differing sizes in storage occupancy (which in turn ~epends on the
packing strategy employed). It shculd not be necessary to complle.a pro?ram
in order to find out if a given pair of variables are t}Te compatIble; Language semantics should take care of that.

A Novel Approach to Compiler Design
By James Q. Arnold

e-n

For the sake of discussion, let us suppose that the Pascal language
implemented on a computer providing instructions for efficie~t byte
The implementor might choose to compile some arrays (those WIth the
priate type of element) as implicit byte (packed) arTays. In.s~c~ a
pairs a-Co and b-c. would no longer be compatible. Type compatIbIlIty
not be implementation dependent.

is to be
access.
approcase, the
should

Computer Science Department

Kansas University

The ideas presented in this paper reflect those of the author, and
no support for them was either requested or received from HoneywelL the
University of Kansas Computer Center, the Department of Computer Science
at KU, or the University of Waterloo.

USing

During the last several months, we have had the extreme pleasure of
a Pascal compiler produced at the University of Waterloo. The

compiler's five versions have given us new insights

compiler

design,

and

into

the

area

of

we would like to highlight a few of them in this

paper.
In the interest of brevity, we shall not delve
into all
areas
p oss ibl e, but we hope the mention of some importa nt items will s t imul a te
the interested reader to reflect upon the further application
of
these
ideas.
Our discussion will center upon the followin9 topics:
1.
Program Portabil ity
2..
Program Correctness
3.
User Interface.
Although each of the areas interacts to sOlne degree with the others,
we
feel
these
are
the
natural
categories exemplified by the Waterloo
compiler..
Thus we shall str ive to pres ent them ina rna nner comme nsurate
with
the
clarity
and elegance in which they present themselves to the
user.

A..
"Use machine instructions in the
differ fro;n processor to processor .. II

conpiler

support

package

which

Both KU and Waterloo have Honeywell
66/60
computers;
KU
has
a
processor
A,
and tv-ateriao
has
a
processor
B.
\"lhen implementing a
p royram des igned for portabil i ty I it is
af
the
u tmos t
import ance
to
utilize
instt"uctions
which behave diffe.rently from machine to machine ..
The Waterloo compiler does just that; but they have taken this principle
to
it s
logical
conclusion.
Not
only should programs
behave
differently, but it .is even more desirable if one
can
arrange
for
an
operation fault as well.
One very important consequence is providing the iraplementation team
with
the
chance
to
practice
patchin0
core-image load modules (the
compiler is only provided in load module form).
This is becoming a lost
art.
and
the
necessary
steps
are being taken by \'aterloo to keep it
alive.
We certainly applaud theln for this.

B.

"Change the language definition."

Hany
Pascal
implementations
provide extensions;
Waterloo
has
transcended
the
lowly extension and
introduced the new concept of
outri9ht nodification.
'This extraordinary achievement was
surprisingly
easy
to make.
convert the
!?'£Q.9.~,C!'-~ heading into ".Ero£~,2,~~~ main;
Notice how mnemonic i.t is now, and how the first line immediately
tells
t he reader what the program was written for.
Notice "lso that the messy
parameters have been eliminated.
This will obviously prevent any confus ion
about the meaning of the
undeclared variables in the J2££9.E~
heading.
AdditiQnally,
the
"curious"
period
terminator
has
been
dropped.
It amazes us even now how such Sili1ple modifications
could
add
so
much
to the clarity and portability of programs.
I'e wonder why Niklaus
liiirth didn't think of these things
himsel f.
Naturally,
the
compiler
rejects Standard Pascal, but this is a blessing in disguise.
As soon as
we have reached the sar.1e level of insight as the desiqners at VJaterloo,
we shall certainly let the reader know what the blessing is.
.11

A.

"Distribut~~

compile

("5

which are not debugged."

Once ayain, the compiler is used as
an educational
tool.
Since
pro,]rammers can not be assumed to know Pascal, any compiler for the
language should encourage the user to study the user manual.
This
can
be
done
in
several
ways, but some of' the techniques llsed by t'1aterloo
s truck us as being particularly noteworthy.

One example follows which aborts the compiler:
iY~ sex: (female, male) ; { : should be = }.
We relayed our
initial
reaction
of conCern to Waterloo,
but
they
reassured
uS with
an explanation [Pascal Release Bullet1n, September,
1977], "The compiler is based on an LALR parser, and
LALR
parsers
are
famous for this behaviour."
Naturally, we were grateful
to receive this lesson. in parsi,:"
theory.
It also illuminated a new attitude which should be 1nst1~ led 1n
all compiler writers of the future.
If there are syntax errors
1n
the
program,
the
programmer must not know the langua~e in the first pla~e.
Encourage him to read the manual; furthermore, don t waste comp~ter t~me
by
looking
at the rest of the program if the error was one wh1ch could
only have been made by
a
complete dolt.
A compiler
abort is
the
quickest and cheapest way to quit scanning.
(i i)
"The
c ()nstructs. II

compiler

should

abort

on

some

syntactically

correct

We believe this
is
a
truly
ingenious device to educate
the
experienced
programmer..
While aborts on syntactic e~ror~ ar,e ~irected
at people who still make mistakes, this kind of abort 1S a1med r1ght at
the knowledgeable
one.
Furthermore,
this will
help the programmer
expand his Pascal vocabulary by forCing him to use different language
features
than
the
ones
he
really wants
to use.
Surely no further
explanation of the power of this device is needed.
(iii) "The
executes. II

compiler

should

generate

incorrect

code,

which

still

Thi s mus t be considered the suc cessor of both (i) and
(i i) •
On ce
t he
program has
sifted
through the
compiler,
and a load module is
obtained, it will surely help the
progranmer
understand
the
program
better
if
it runs incorrectly.
Hand traces are illuminating, and they
are essential in the development process of
a
program.
Waterloo has
extended
their
application even further to include post-runtime.
Once
again, we are amazed at the insight and
courage needed to make this
intellectual leap.

At this point it should be noted that these principles
combine
to
help unify the user community.
At KU a "bug list" has been compiled (by
hand), and all users are invited to contribute.
It is a marvelous
tool
for
bringing people together.
Furthermore, we have actually discovered
t hat some of those people prefer entomology to computer science.
They
a re indebted to \,aterloo for providing the initial motivation to explore
t he field.
The compiler seems
to
serve as
a
limited,
occupational
counselor.
B.

uGive brief error messages without referring to program text."

This will
obviously
make
the user study the whole line
(or
procedure,
or
program).
Our favorite message of this kind is "Syntax
error
near
"'identifier"'. II
The
runner-up
is
"Syntax
error
near
'program'."
It
should be
apparent how exemplary the latter is, especially for beginning programmers who are trying to write their
first
Pascal
program using Wirth's definition.
(The second message actually
refers to a use of the defunct keyword, Erogram, which is not allowed to
b e us ed a t a l L )

most

(i)

"The cCl11piler should abort on

sorne simple syntax errors."

A.

One

"Make the compiler

opt ions a

dynamic set.

II

All programmers like to feel they are in control of their machine.
way
to
foster
this
feeling
is
to
provide an interface to the

\.N
V1

This .i5 superbly executed by
language processor whi~t) keeps changing.
To allow the use of
the
time shar ing command scanne r. for the compiler.

UNIVERSITY OF CALIFORNIA, SAN DIEGO

upper
Cfise
keywords,
we
huve
used
"-dualcase,"
II-uppercase,"
and
"-singlecase"
with
different
ve~sions of the cOJnpiler.
Inexplicably,
t hey neglected to r.ecognize those options only when typed in lower case,

BERXELEY • DAVIS • IRVINE • LOS ANGELES • RIVERSIDE • SAN DIEGO • SAN FRANCISCO

to

completely rule out the use of an upper case terminal.

will

Perhaps that

be provided in a future version.

INSTITUTE FOR INFORMATION SYSTEMS

In addition, it is also advisable to maintain
a
dynamic
set
of
requireH1f:'nts
foe
the
placement
of the options on the command-line in
relation to the filenafi1es.
Particularly useful here
is
requiring
one
option
to
follow
the
natne
of the BOUrCe fil e, whil e all others must
precede it.
As new versions evolve, howe\~er, this
restriction may be
loosened..
Once
again,
Waterloo
seems
to
have missed the chance to
change .!th.1.ft!. option must follow the filenames.
B.

"Do not

implement

all

of the options documented at

The reason for
this
is
to prevent
confusion
providi!1g too many thint]s at one time which all work.

CO'
files

"Create files for the user,
already in existence."

I'e must admit that this

is

without

the

checking

best

in

the

feature

compiler performs with char.-acteristic aplomb.

one

of

time,,"

by

the

user

names

of

the

and

the

all,

We were also delighted to

discover that the filenames used depend upon the options

given

in

the

command-line..
This
is
necessary
to
prevent standardization.
One
exalople wi] 1 open the door for future implementations to follow.
If the
user
simply
wants
to
compile
the
program and get d

relocatable
a ppending

II

object
.0"

deck,

the

compiler

creates

to the name of the source file

a

file

(it can not

for that by
be

specified

by the user, a nice extra). The Honeywell time sharin'J fi Ie system
limits filenames to eight characters; what should the compiler do if the
name of the source file

a lready guessed.

is eight characters long? Perhaps the

reader

The only logical thin'} to do is write the object

has

deck

r i9ht
over the source..
Nothing could be more clever"
Source files are
useless when one has the object deck.
Why \vaste file space
maintaining

both?!
This will also prevent the user from making wasteful and costly
listings of the program. vie are contin°~"lly impressed by the resourcefulness displayed with this unique feature. An important thing in it's
irnplementation is the requisite lack of system documentation. The best
system features ilre .
:::0

-<

The software system is currently executed in a pseudo machine
interpreter, which emulates a hypothetical real machine designed to
handle PASCAL constructs efficiently. Our pseudo machine is similar in
concept to the P-machine distributed by Wirth's group at Zurich, but we
have made extensive changes to compress the PASCAL object code into a
much smaller space than possible with the Zurich interpreter. The
interpreter, and run-time support routines, currently occupy about 8K
bytes of main memory. The interpreter is in the native machine
language of the host machine, and thus far has been coded by hand using
the host's assembly language. All other code in the system is written
in extended PASCAL.
While the interpreted object code runs roughly five times slower than
native code for the host machine, several factors allow our large
system programs to run substantially faster than this would indicate.
The strategy of code compression makes it possible to run relatively
large programs without time consuming overlays. For example, the
complete compiler occupies 20K bytes in a single overlay. Since the
system is designed for frequent compile/go cycles associated with
instruction, we have added several built-in procedures and functions to
handle low level operations needed frequently by the compiler. ·As a
result, the compiler translates PASCAL source code at about 650 lines

-0

::t:>
G"l

rn

per minute on an LSI-11 with its clock set to 2.2 MHz.
the compile speed will be slightly faster than this.

On a 4 MHz Z80,

Interpreter based versions of our system are now running on 5 distinct
processors, and two others are close to completion. Those operating
include DEC PDP-11's ranging from the LSI-11 to the 11/45, using either
floppy disks or RK05 disks for secondary storage. Versions for the
8080 and Z80 are operating in our laboratory, but more of that later.
Sperry Univac Minicomputer Operations at Irvine is using the system on
the V-15 and related machines. Another group at UCSD has the system
running on the Nanodata QM-1. With support fro~ General A~tomation, a
version is close to completed on the GA-440 fam~ly of mach~nes.
National Semiconductor has an implementation nearly completed on the
PACE microcomputer.
The principal modules of the system as it will be distributed in the
1.4 release include the following:
PASCAL compiler
File manager (capabilities similar to DEC's PIP)
Screen oriented editor (cursor positioning, immediate updates)
Line oriented editor (similar to DEC's RT-11 Editor)
Debugger (single line execution, reference to variable contents)
SETUP program (adapt system. to most ASCII terminals)
BASIC compiler (ANSI standard plus strings)
Operating System and user command interpreter
PASCAL pseudo machine interpreter
Linker program (for linking independently compiled program segments)
Desk Calculator utility program
Users of the Terak 8510A may, on request, also receive copies of the
CAl package, and automated quizzes for the introductory textbook, as
well as the bookkeeping package.
Documents describing all of the above are available, and part of the
release but not all documents ca~ be considered complete at this time.
We dist;ibute source and object code files on separate floppy disks
formatted to be compatible with the IBM 3140 standard, with 512 byte
blocks laid out in alternate 128 byte sectors according to DEC's
standard. We haveoccastonally sent copies recorded directly pn disk
packs for the RK05 drives. All other media are painful or impossible
for us to handle, and no promises are made to use them. Those who
order the full $200 release package will be sent both the documents,
and printed listings of the source programs. Copies of the descriptive
documents amounting to approximately 150 pages, may be ordered at $10
each (che~ks payable to the "Regents of the University of California")
to cover printing and handling costs.
3. Minimum Configuration
In order to use the compiler, you need a total of at least 48K bytes of
main memory, including the 8K bytes assigned to the interpreter. We
use 56K bytes. Ideally, the interpreter should be completed re-entrant
and thus it should be possible to operate the interpreter from Read
Only Memory. To date, the ideal has not quite been achieved, as none
of our sponsors has yet insisted on that feature.
At present, the system we use with students contains several built-in
functions not needed for system development. The aggregate size of
these functions is large enough to prevent compiling the compiler
itself, or the operating system, even on a 56K byte system.
Accordingly, we currently have two versions of the system, one for
students, and one for system development. Within the next few months,
we plan to add a means of configuring general purpose libraries for the

system, and by that means expect to be able to return to a single
version for all purposes. That single version should be practical to
use in less than 48K bytes for some purposes.
If you intend to compile on one microcomputer, and to executed object
routines on others, the others can get by with as little as 16K bytes
of main memory if the operating system is not used. The resident
portion of the operating system occupies about 8K bytes itself. This
will undoubtedly be reduced as part of the libraries project.

=

The system is designed to be used with standard IBM compatible floppy
disks. Clearly it can be used with other varieties of floppy disks, or
with other secondary storage media, with appropriate I/O drivers. The
I/O drivers have proven to be one of our principal bottlenecks, and we
make no promises in advance about supporting other devices. For DEC
PDP-11 machines, the floppy disk drivers are assumed to be compatible
with the RX-11, or with the Terak 8510A drives. Hard disks are assumed
to be compatible with the RK05.
The system is normally supplied with the assumption that the user has a
simple line-oriented ASCII terminal. The SETUP program can be used to
configure control codes for more appropriate use of most CRT terminals.
Copies of the system supplied to users of the Terak 8510A make fairly
extensive use of the special graphics and character generator
facilities of that machine.
4. 8080 and Z80 versions
The Z80 version is now running on the Tektronix 8002 Microprocessor
Development Aid system, for which Tektronix has supplied substantial
support to the project. The 8080 version uses virtually the same
source code as is used on the Z80, with conditional assembly altering
certain passages in the source to substitute for a few of the extended
Z80 instructions that proved useful.

"Tl

rn
tt:J
;;0

=

»

:::0

-<
Release of the 8080/Z80 version of the system for other machines has
been held up primarily because of the awkwardness of handling I/O. We
currently have a Zilog Development System, a Processor Technology SOL
system, and a Computer Power and Light COMP~L-80 system. The floppy
disk provisions for each of these machines ~s non-standard. As a
result, we have been forced to down-load programs via serial interfaces
to get from the LSI-11 host machines used for development over to the
new 8080 or Z80 based host. This has proven to be a very time
consuming process, and a serious bottleneck in our work. Moreover, we
are somewhat amazed to find that the Assembly of large programs on
these machines runs almost a factor of ten slower than compilation of
PASCAL programs that carry out similar tasks! Clearly, something has to
give if we are to reach the objective of distributing PASCAL systems
for more than a few 8080 and Z80 based machines.
The solution to this problem that we now plan to use is based on the
extensive market penetration of an operating system called CP/M, which
is a product of Digital Research Inc. We have talked with many OEM and
hobbyist users of the 8080 and Z80 who wanted to know when we would
have the PASCAL system operating under CP/M. We then learned that CP/M
is distributed in a package which assumes that most users will write
their own 110 drivers. In effect, CP/M establishes a quasi standard
for the interface between an 8080/Z80 operating system and its I/O
drivers. With thousands of copies working in the field, CP/M seems to
be far ahead of the field in this area. Accordingly, we have decided
to release the UCSD PASCAL System for 8080 and Z80 users in a form that
will work with I/O drivers and bootstrap loaders developed for use with
CP/M. This does not mean that our package will run under CP/M.
However, if CP/M runs on your machine it should be relatively easy to

install the PASCAL system on that machine. We have been in contact
with Digital Research on this concept, and they have offered to
cooperate. ,If you do not have CPIM for your machine, the
implementation package may be obtained from Digital Research Inc., Box
579, Pacific Grove, CA 93950 for $70. Since CPIM has been implemented
on a very wide variety of 8080 and'Z80 based machines, there is a high
probability that CPIM 110 drivers are already available from Digital
Research or someone else for your machine.
Alteration of our present interpreter to match the CP/M I/O calling
conventions has proven to be very simple, at least on paper. We expect
that some implementors of CPIM will have installed standard console
input routines which automatically echo to the standard console printer
or display device. This will necessitate a change, since our system
uses both echoing and non-echoing console input. At this writing, the
exact method to be used is under discussion. Barring some unforeseen
calamity, copies of our system designed to run with CPIM 110 drivers
should be ready for distribution by early January, 1978. The
distribution medium will be IBM compatible floppy disks formatted in a
manner yet to be finally speQified. We will undertake to transform the
system for other media and other formats, in general, only if a copy of
the necessary hardware is available in our laboratory, and only if
funds are available to pay for the extra conversion work.
For many of the 80S0 based machines we have seen, the most practical
way to install our system will be to use 4SK bytes of RAM augmented
with 8K bytes of ROM for the interpreter. Any additional RAM or ROM
required by the host processor system will also be needed.
5. PASCAL Extensions and Alterations
We have attempted to implement faithfully as much as possible of PASCAL
as defined in Jensen & Wirth's User Manual and Report. The principal
extensions to PASCAL embodied in our system are related to STRING
variables, Turtle Graphics, handling of disk files, Segment (overlay)
Procedures, and several functions for support of the system itself.
Alterations include a prohibition against passing procedure or function
identifiers as parameters, restriction against GOTO out of a procedure,
the addition of EXIT«procedurename» to effect a normal exit from the
procedure named in the parameter, and a change in READ applying to the
interactive INPUT and KEYBOARD files. Further details than given in
this s~ction are given in our system release documents.
Type STRING is a pre-declared record containing a character count
fOllowed by a packed array of characters. Built-in procedures and
functions include LENGTH, POS(ition), INSERT, DELETE, COpy (i.e.
extract), CONCATenate, SCAN, FILLCHAR, MOVERIGHT, and MOVELEFT. The
last four of these also operate on conventional packed arrays of
characters.
Turtle Graphics describes a technique originated by Seymour Papert of
MIT in which one can either MOVE a cursor (called the "turtle") an
arbitrary number of screen units in the current pointing direction, or
TURN an arbitrary number of degrees at the current position. A
PENCOLOR procedure allows the line drawn by a 'MOVE to be either WHITE,
BLACK, or NONE.
The disk file extensions allow working with fixed length logical
records corresponding to any legal , which might typically be a
RECORD data structure. GET and PUT operate normally through a window
variable of the same . OPENNEW creates a new file, OPENOLD opens
a pre-existing file, and CLOSE allows saving or purging a file. SEEK
(which will be distributed with the 1.4 system for the first time)
allows random access to logical records within a file.

SEGMENT Procedures are separately compiled and then linked into the
host program using the LINKER. A Segment procedure is only loaded into
~ain memory when it is entered for the first time, and its memory space
lS deallocated upon exit from the first invocation.
R~AD(INPUT,X) is defined by Wirth as X:=INPUTf; GET(INPUT); which we
flnd to be extremely awkward for interactive use. Our solution is to
place the implied GET before the implied aSSignment in the case of
interactive files of type TEXT. READ operates as defined in Wirth's
Report for other TEXT files.
en

PACKED records on our system which fit within 16 bit fields are
automatically packed and unpacked without explicit action by the
programmer.
6. Introductory PASCAL Course and Textbook
Man~ of those inquiring about our system have heard about it through
havlng seen the textbook "Microcomputer Problem Solving Using PASCAL"
by the author of this note, published this fall by Springer Verlag. If
you haven't seen a copy, they may be obtained from Springer at 175
Fifth Ave., New York City, NY 10010.

The book is the basis for teaching the large attendance iritroductory
computer science course at UCSD. This course Gomes close to matching
the specifications for course CSl in the recently published curriculum
recommendations from ACM's SIGCSE. The approach is non-numerical as
f~r a~ practical, as a tactic to reach the many students who come to us
wlth,lnadequate prep~ration in high school mathematics. The problem
solvlng and programmlng approach taught is the same as we would teach
even if all the problem sets were mathematics oriented. Because many
problem examples and illustrations use our string and graphics
e~tensions to PASCAL, the textbook currently assumes that the student
wlll,have access to a computer which runs under the UCSD PASCAL system.
We wlll be glad to discuss the possibility of conversion to other
softwar~ systems, but have very limited resources to apply to such
conve:slons. There ~r~ several stand-alone microcomputers now being
sold ln,large quantltles on which our system would run, given a small
converSlon effort, and we would welcome support funds to pay ,for such
converSlons.
Software in the form of automated quizzes is available with our system
release for those who may wish to teach using the textbook
Each
chapter in the book has a list of study goals for the stud;nts to
ach~eve.
Wherever,appropriate, the quizzes test for mastery of the
tOP1CS enumera~ed ln the goals lists. The quiz programs have been
lmplemented uSlng a set of CAl primitive routines patterned after the
w~ll known DIALOG CAl system developed at U.C.lrvine by Alfred Bork and
hlS colleagues.
The introductory course is taught using Keller's Personalized System of
Instruction (PSI). PSI has been found to be a more successful method
of instruction than any other method commonly USed in universities and
colleges. This success is achieved, almost completely without
conventional lectures, by using experienced students as Learning
Assistants called "proctors". The characteristics of this method make
us believe that it is possible to offer this course, or others
construc~ed along the same lines, on a packaged basis for use at other
lnstltutlons. A separate paper describing this possibility in detail
called "Microcomputer Based Mass Education" is available from the
writer of this status report.

-n
f'T1
t:I:I
;:0

=

:t>
;:0

-<

7, Tele-Mail User Support Facility
We have reached the point where it will be possible for us to begin
operating a dial-in computer "mailbox" by early in the winter quarter.
We have been using the Terak 8510A machines occasionally as intelligent
terminals for exchanging messages via the large B6700 computer operated
by the campus computer center. Our own Tele-Mail facility will use its
own single telephone number reachable directly from the national dialed
telephone network, or internally via the California state government
telephone network. Paid subscribers to our software release will be
notified when this mailbox facility is ready to be used.
The mailbox will be operated primarily to serve users of our software
system. It will provide notices of recent bug corrections,
down-loading of program files (either source or object) where
appropriate, notices on new additions to the software and new machines
on which implementations have been completed, and other useful
information from us to the users. It will also serve as a means for us
to collect messages from specific users, and to answer them
expeditiously, without the hassle of both parties having to be at their
telephones at the same time.
Through the use of block transfer software, the mailbox will make
relatively efficient use of the dialed telephone network. We would
like to begin immediately by offering a dial-in port at 1200 bits per
second. However, the present state of confusion in the industry at that
speed (which is the fastest one can use with acoustic couplers) leads
us to move cautiously. We can and will install a port at 300 bits per
second using the standard Bell 103A equivalent conventions. The system
will answer an incoming call from an ordinary terminal by providing a
brief summary of recent developments. It will otherwise expect a
"handshake" from a special file transfer program that we will provide
to users of our software package. This program will be the means of
interchange based on efficient transfer of messages in the form of
complete files. If ycu wish to send an ordinary text message to us,
you will prepare the message using either of the editors built into the
system. Only after the message is complete will you need to make the
telephone connection.
8, Forthcoming Improvements
As mentioned earlier, our next significant improvement in the software
will be a more flexible system allowing libraries of programs. One of
the main reasons for doing this will be to allow the software to be
configured to make efficient use of main memory in cases where the user
does not need all of the built-in facilities. For example, we have no
need for turtle graphics when compiling large system programs.
One of the long awaited features of the new library system will be an
arrangement allowing mixture of PASCAL procedures with Assembly
language routines and/or procedures compiled directly to the native
code of the host machine. The necessary assemblers and code generation
will come somewhat after the library system is operational. If all
goes well, the library system should be ready to distribute during the
winter quarter of 1978. The assemblers and native code ve'rsions of the
compiler will come somewhat later as time for the necessary work
permits,
Many people have asked whether we have in mind extensions to support
Concurrent PASCAL, or similar facilities to allow independent processes
running concurrently, This is something we would like to do
eventually, but our current resources do not allow making definite
plans in this area.
(* Received 78/01/03 *)

UNIVERSITY OF CALIFORNIA, BERKELEY
BERKELEY' DAVIS' mVINE • LOS ANGELES' RIVERSIDE' SAN DIEGO' SAN FRANCISCO

PROGRAM IN QUANTITATIVE ANTHROPOLOGY
DEPARTMENT OF ANTHROPOLOGY

SANTA BARBARA' SANTA CRUZ

2220 PIEDMONT AVENUE
BERKELEY, CALIFORNIA 94720

21 December 1977

SUGGESTIONS FOR PASCAL IMPLEMENTATIONS
These suggestions are not based on implementation experience (I have none), but
on using, teaching, and arguing about the language and on maintaining and trans-

porting Pascal programs across several machines. Items 1 through 7a below concern
implementation and have no bearing on the Pascal language. Items 7b through 10
would affect portability if implemented on only some machines, and thus seem worth
considering as "conventional extentions."

1) A very nice feature offered by some Fortran compilers is a special comment
construction which is treated as a comment under one compiler option (the default),
while such comments are compiled if the appropriate option is specified. This
feature allows debugging code to be inserted in with the rest of the program at
no cost to the size or execution time of the final production object code (since
the debugging code is treated as comments in the final compilation).

In addition

to debugging, this feature can be used to produce two slightly different object
versions from a single source program, or for insertion of machine-dependent extra

features in an otherwise transportable program.
Pasc~l

This could be implemented in a .

compiler in two ways:

a) The most analogous implementation would use a $ comment option which would
cause the preceeding open and the following close comment symbols to be ignored
under "debug" mode, while otherwise these $ comments would be treated as comments.
This means of implementation has the advantage that it can be used for declarations
or for actions. It has the disadvantage that no comments can appear within the
"debug" code since few (if any) compilers allow nesting of comments (some allow
pseudo-nesting through different comment symbols).
b) A different implementation would use Pascal language structure rather than
special comments: "debug" code would appear within an if statement which has as

its Boolean expression only a single constant identifier. The following (compound)
statement is compiled if and only if the constant has the value TRUE. The code
for the if statement itself is not generated in either case. Means of implementation b) has two advantages over a). First, the programmer can provied as many
different "constant switches" as desired: one actually for debugging, another
if certain features are available on the host machine, etc. The second advantage
is that any Pascal compiler will generate correct code from programs using these
constant switches, in fact, I used them frequently to move programs back and forth
between machines (Texas-Austin CDC and DEC 10). Of course, such programs will
run less efficiently if the special use of the Boolean constant is not recognized
at compile

t~e.

For the specific purpose of' debugging, it would be convenient

to have a predefined Boolean constant identifier DEBUG global to the main program.
This would be FALSE unless set by the job control command invoking the compiler,
and could as usual be overriden by a local same-named constant.
2) Large programs would be easier ·to read and debug if the compiler source
listing included, at the end of each procedure or function, the names of global
variables referenced in that routine, and the routine in which they were defined.

suggested Extensions to Pascal
Part I
3) A compiler option to flag non-standard constructs is quite useful. At some
future time it may be desirable to expand this to flag only constructs which are
both non-standard Pascal and non-"conventional extentions

ll. A. Fra ley
University of British Columbia
August 25, 1977

ll •

4) If the reserved word PACKED is ignored by the compiler, the procedures PACK
and UNPACK should be implemented as the appropriate FOR assignment loops.
5) If LINELIMIT (not a part of Standard Pascal) is not called for a file, the
default should be no line limit at all, rather than a small positive limit. A
small default limit is undesirable for two reasons: a) programs writing to several
files may run ~orrectly during testing and then fail on a large production run
(Pascal 6000 enforces a limit on every output file, not just printer files), and
b) portability of programs written on machines not implementing this extention
is impared.
6) The syntax which makes one-pass compilation possible also makes possible a
compiler for interactive program entry, with syntax checking after each line of
code is entered by the user. Actually, program entry could be done by a syntax
scanner which copies good input to a file but does not generate code (thus would
be transportable). If the user was given some simple editing facilities, such
a system would compare favorable with many of the selling points of a good
Basic interpretor.

7) The following two comments on numeric input apply to either free-field or
formatted input:
a) The standard language definition of 

'"

rn

This
allows
compares.

2.

simple

implementation

of

moves

and

The parameter& are stored next.
These fields may be
interrogat€d or used for type com pa Ubili t y checks.

3.

The data area for variable sized fields is placed at
the end of the record structure. This allows direct
access to all fields without the need for computinq
displacements at run time.

4.

Each field of variable size is replaced in the
structure by a pointer to the appropriate data area.
Unlike other pointers in Pascal, the field pointer is
relative: it is the displacement of the data area from
the pointer. field.
This allows record items to be
moved without changing the pointers.

5.

When an array has a component of variable size, the
length and index origin are stored in a dope vector.

one additional restriction is that parameterized types are
not compatible with simple types.
For example, if we have the
aeclarations

racilities rpUGN 45
(Eisenberg),
#6
(Hagerty, Cichelli), 118
(Sale)].
The suqgestions in this section and the tllO that
follow address these complaints and related topics.
What is a file?
A
file is a record, one of whose
components is a system object. The system obiect contains a
seguence of typed components.
Pascal over-simplifies this
situation by iqnoring the system obiect.
When a user: first
~earns
about files, he must learn the system conventions guite
early.
Hiding them in Pascal does not shor:ten the learning time
significantly.
C/)

Files in Pascal contain the one important property which
makes them variables: they vary. The assignment operator is not
defined for this data type.
Euclid even has a method for
assignment to be illeagal for selected user types.
But
assignment of files in Pascal could be given a meaning. Just as
"1'," suggests a dereference Which does not necessarily occur,
the assignment "P1:= 1'2" could assign the system obiect from
one file variable to another.
After this assignment, F1 and F2
~ould
access the same system obiect.
(The coordination between
these files, the contents of their buffers and flags, and ether
issues would need to be decided if this inter:pretation is made.
These issue must be pursued anyway since two external files may
access the same system obiect.)
HeLe are some suggested operations on files.
Some of these
would be meaningless for the cur:rent Pascal definition of files.

YAR

V: STRING (12);
Ii: ARRAY [ 1•• 121 a!' CHAR;
PROCEDURE Q (VAR STR: STRING);

DEFI NED (file)
Returns TRUE if there is a
with this file variable.

the call Q(V) is legal, but the call Q(W) is not.

--n

system

obiect

associated

Modules

OPENED (file)
Returns TRUE if the file has been used.
If FALSE, a
RESET or REWRITE should be performed rather than a GET
or PUT.

One of the strengths of Fortran is the ability to have
library
packages.
. Some
Pascal compilers allow separate
compilation, so
that
libraries
can
contain
individual
procedures.
But for a package of procedures, there must be a
shared ·data area for retaining values and communica ting from one
procedure to another. The Fortran mechanism for this process is
"named common".
Pascal has no such mechanism. Its global data
area serves as a structured form of "blank common", but there
should be a structured form of named common.

RESET (file, name); REWRITE (file, nam~
Changes the system obiect associated with the file to
the named ob;ect.
This allows the
program
to
reference catalogged files without the user supplYinq
the name each time the program is run.
Conventions
for
names
would
need
to
be established for
portability.

Modules in the language Modula r 51 provide
such
a
structure. Selected constants, types, variables, and procedures
of a module are known to ·the outside world; all others are the
private property of the module.
Pascal should allow separate compilation of modules.
Later
compilations could reference the "obiect module", which would
contain definitions of all external names. The compiler could
include the module's obiect code with the current compilation,
or could insert the appropriate loader control lines for
fetching the module. Some provision should be made for alerting
users when the external specifications of library modules are
modified.
Files
A number of complaints have been made

about

Pascal's

I/O

M
b:l

=
c:::

::t:>

=
-<
I-'
<.0
'-I

co

EXT END (file); EXTEND (file, name)
These work like REWRITE, but can be used to extend an
existinq file without reading it first.
(Example:
A
compiler might wish to keep a statistics file of all
error messages issued to users. The second form of
EXTEND could be used, since the user would not know
about this file.)
END.FILE (file)
Assurninq EOF(file)
is TRUE. this procedure ends the
current file.
If EOF(file) is FALSE, skip past the
end of the file.
This is useful if the actual file is
a tape.

""'C

:l>

=
rn
Random access facilitie~ may be added to the existing file
facilities with little cost.
Unlike the "slow array" proposals,
the technique below does not permit integer indexes into the
tile.
While this may be inconvenient, it can be easily

~mplement€d

on most machines.
In addition, if a file element is
ueleted in an integer indexing scheme, there would be a question
dS to whether the subseguent elements should be renumbered.
POSITION (file)
This function returns a value of an internal data type
"filepos", indicating the current position of the
window in the file.
DELETE (file, pos)
Deletes an el~rnent of a file.
"filepos".

"pOSH

must

have

losing significant information in the inteqer case, so
we should avoid it in the character case.
The
statement wRITE (0 ABCD ':3) could be defined to
produce .. ABCD" instead of .. ABCD".
This would
allow the form WRITE (A:O)
to be used inside of
messages without leavinq irrelevant spaces.
3.

There are certain applications where the programmer
may wish to truncate integers or strings on output.
The statement

type
WRITE (1234:3:TRUNC,'ABCD':3:TRUNC)

REPOSITION (file, pos)
Repositions the file window to the parameter position.
Following this position, a GET or a PUT is permitted,
regardless of the current value of EOf(file).
If the
component at the indicated position has been deleted,
a GET will set EOF (file) TRUE.

could produce the output "234ABC".
4.

NEXTPOS (file, pos)
This procedure differs from REPOSITION in two ways:
1.

If the component has been deleted, a GET will
access the next component which has not been
deleted.

2.

A PUT will place the current buffer into the
file
position
immediately
following
the
indicated position.

Real
number
formatting
in Pascal is currently
inadequate.
When the decimal digits aren't specified,
the format ("E" or "F") should be chosen by the output
routine to maximize the number of significant digits
which can be contained in the field.
The call
WRITE (r:w:d)
causes "P" format output with
"d"
decimal digits, unless siqnificant digits would be
lost on the left. The field could be expanded, but a
switch to "E" format would be appropriate.
(The field
would be widened to allow for a value having the
specified number of decimal places and the exponent as
well.)
The statement WRITE (r:w:d:EI could force "E"
format with the specified number of digits.
For consistency with the previous cases, the call
WRITE (r:O)
could
output
in
free-format.
The
conventions could be those found in APL, in which
trailing zeros are eliminated when possible.

PIRSTPOS (f 11e); LASTPOS (file)
These functions return the first and last positions of
a file, respectively.

For consistency with the source language, at
least one digit must be printed to the left of the
decimal point.
I f no
diqits are requested to the
right of the decimal, "."
is not printed.
An
additional convention may be that exact zeros are
printed "0" with no decimal part and no exponent.

These functions should be easy to implement for files havinq a
lixed com~onent si1:e.
A clarification of the effects of these
procedures would be needed for text files.
(O~r system does
aeletions ,and rewriting of entire lines, rather than individual
characters. )'

I--'
LO

........
As

to

the

usefulness of this scheme,

most random accesses

reguire the use of a directory, links in fieldS, or remembering
d
location.
The special pointers can be stored as easily as
~nt",gers.
\lashing to a file isn't possible, but a procedure for
mapping integers into file locations miqht be specified.

5.

Formatted output of scalars and characters should be
provided, and should be identical to strinq output.

6.

Input of character strings should be allowed. READ (s)
would start at the current input position and fill s
with characters. If the end of line is reached before
s is full, the remainder of s is filled with blanks,
and the window remains at the end of line. If EOLN is
TRUE when the read is started, the read begins on the
next line.
(Note that if zero lenqth lines are
permitted, a null line could pass unnoticed. Our
system returns one space with EOLN false even if the
oriqinal line was empty.)

7.

It should be possible to associa·te read and write
formatting routines with each user-defined type. This
would allow all variables to be used in READ and WRITE
statements.

Formatting
The Pascal Report [1] does not specify the effects of the
formattin~ procedures READ and WRITE in sufficient detail.
The
auggestions below clarify a few points, and present some
extensions and changes which seem more consistent and flexible
than the current conventions.
1.

2.

What is the effect of WRITE
(1234: 3)?
To avoid
erroneous printing of numbers, the full value "1234"
should be printed. This has the desirable side effect
that WRITE (1:0) produces free-form output. No extra
spaces are placed around the number, so it will appear
naturally in the text.
Consistency
what is the effect of IiRITE
('ABCD':3)?
We avoided
says that the output should be "ABCD".

Input formatting,
while not discussed above, should be
provided.
People won't use Pascal if they can't read their
existing data, whether or not it is archaic.
Sometimes data is
generated Olf laboratory equipment as strings
of
diqits;
modifications to the hardware should not be forced on the user.
1n addition, most users don't have the time to write their own

0:>

~umber

conversion routines for reading the data a character at a

time.

Conclusions

The use of Fortran ca~ridqe control is archaic, and doesn't
l.nterfacE well with some operatinq systems.
(i.e.: Pascal
would need to know whether the first character is carriaqe
control in order to generate the proper file formdt.)
The
Lollowing format generators could be included as a~guments to
.

';':

PROCESS (C);
ERROR (C)

END
This has an advantage over the "OTHEWISE" notation fPUGN la. pq
26 (steensqaard-I!adsen) 1 because specific error values can be
J.isted along with the default symbol "<>".
Wirth has reiected the use of a CASE default rpUGN fa.
pq.
23]. This author feels that it is no worse than the unqualified
ELSE in an IF statement. It is an absolute requirement if the
CASE is to be useful in real programs. Consider wirth's example
of a CASE beinq used with a character field.
A proqram which
will receive wide distribution may use a restricted character
set.
All characters cannot be listed. because implementation
character sets may differ. On certain machines. some characters
Aave no external representation, and could not be entered as
case labels.
Sometimes the internal,
printer, and terminal
character sets differ. addinq to the confusion.
To restrict the temptation to misuse the case default. a
of values (such as 1•• 10) should be allowed as a case
~abel.
For characters. the ASCII orderinq could be assumed to
permit portaoility.
(' • •• ·w' means "all characters from • ,
to 'ill' in the ASCII sequence".
It does 1lQ! imply that the
~nternal
representation is ASCII.
Compilers for non-ASCII
~mplementations would need a table
to select the appropriate
character values for the case label.l
range

,Other for.ulations use "FI", "END IF". or "END" in place of
"END_IF".) The advantage to this form is that the programmer
need not decide whether a BEGIN is needed or not when writinq
his code. A line may be inserted without needinq to add BEGIN
END
brackets.
The "danglinqELSE" problem disappears: it is
41ways obvious which IF an ELS.E is associated with.

Loop Statements
Sost of Pascal's compound statements may easily be given a
closed form: a suitable closinq word is selected for the end.
For convenience. "ELIF"
(a contraction of ELSE and IF) is
4ddedto the IF statement, allowing multiple tests with only one
closing END_IF. The REPEAT statement already has a closed
format.
The CASE statement reguires the most modification to
meet this suggestion. The format below might be used:
CASE I
WHEN 1,2 DO X := Y; Y := Z
WHEN 3
DO X := Z; Y := X
END
The word "CASE" miqht be replaced by "TEST" for readability.
The CASE Statement

The existinq loop statements are not applicable in all
situations. The author suqqests an infinite loop. toqether with
an exit statement.
LOOP
EXIT IF F (I)
I := I + ';
END

< 10;

A semantics check could quarantee that each loop contains an
EXIT.
The EXIT can be Embedded in an IF or CASE, but not
~nother
loop.
The condition followinq EXIT is
optional.
,Compilers should generate a table of all exits from a loop. or
flag exit statements in the marqin.)
A FOR clause could
introduce a loop:
FOR I := 1 TO 10 LOOP ••• END

1:

For loops would be more useful if a set value could control
the iteration.

X:= Y;

10000: Y := X
END

I'TI
tI:I

:;:0

c::
J>
:;:0

-<

......
<.0

........

The CASE statement, as specified by the report. has a
number of weaknesses. The legality of the statement below is
not specified by the report.
CASE I OF

"

FO R I IN [1,7, 9 •• N 1 •••

00

~o specific o~de~ of value seiection should be assumed.

Another
FOR loops
(as moditied above) would be a code
reg~on wh~ch 1S executed
only when the ite~ation te~minates
no~mall y, but not when an EXIT is used to leave the loop.
~mp~oveme~t

~o

:= 1 TO L.IMIT LOOP
IF KEY = TABLE rIl THEN
BEGIN BESULT:= I;
EXIT END
AFTERWARDS
LIMIT := LIMIT + 1; TABLEfLIMIT];= KEY;
RESULT :~ LII'lIT
END
rhe value of the controlled variahle should be defined on exit.
dany machines cannot trap references to undefined values, so
l.mplementation dependent p~ograms could be developed which rely
on the specific values left by that
implementation.
The
variable should have the value of the last time throuqh the
loop, or be unchanqed if the loop was not executed.
Miscellaneous Points

Allow "_" in identifiers.
Allow";" before ELSE {optionally).
Proqrammers oould
then use a;" as a statement terminator if they wish.
Allow st~inqs to De extended with blanKS on the riqht.
Do
nQl automatically truncate characters from st~inqs. Allow
sinqle characters to be extended to strinqs.
Alternatively,

Explicitly
prohibit
character
continued on a new line.
Allow subranges instead
parameter lists.
Chanqe ";" to "," in
Require
parameter
parameters.

of

type

types

Allow "PROCEDUR En in place of "FU NCTION".

allow

constants

from

identifiers

in

a

being
formal

Provide procedure
variables.
A
representa tion
of
procedure pointers is available for procedure parameters.
Only top-level
procedures
(within a
module)
lIay
be
assigned
to variables,
thus avoidinq the "vanishing
environment" problem.
Use parentheses for array references (A(II
instead of
A[IJ).
An array is a method for implementing a function
of inteqer arguments.
Why should implementation decisions
affect the technique for writing the function reference?
A library packaqe miqht chanqe its implementation, without
changing its external specifications; users would then
need to chanqe their proqrams.
(Note: there is currently
no distinction between a
variable reference and the
invocation of a parameterless function.)
Provide a compiler option format,
instead of exam1n1nq
comments
for
compiler options.
"$" brackets could
surround option specifications.
Each option name may
optionally be followed by ".n, "_n, or ":-".
Options are separated by"," or ";".
Com Filer
options
should
be
standardized.
An
implementation need not provide an option, but if it does,
the name is chosen from the standard list. Options not on
the
list
may be provided as well.
Compilers not
recoqnizing an option name should iqnore it.
Compiler options which affect the qenerated code (such as
options for range and index checks, non-standard features,
optimization, or debug facilities) should follow standard
nestinq rules.
option chanqes made within a procedure
should not affect outer procedures.
Semantic Ambiguities

parameter declarations.

p~ocedu~e

for

procedures

passed

as
The validity and interpretation of each construct
should be made explicit in any forthcominq standard.

PROCEDTHlE Q (PHOCEDURE P (VAR REAL; 3 REP INTEGER));

type

TYPE PTR

~

specifications

t RECORD '"

pointer

in

END

below

1. Consider the program segment below.

PROCEDURE P;
TYPE T = fXX;
XX = RECORD ••• END;

Procedure argument lists are a specialized form of record.
The variant mechanism should be available fo~ parameter
lists.
Allow
arbitrarv
dec lara tions.

Require a ":" if the tag name is omitted.

Specify a maximum source line length.
100 is a reasonable
value.
(This allows some extra formatting space on a
132
characteL' print line, and allows for line expansion when
80 character lines are edited.)

FCB I

Provide a substring function.
number ~anqe as a subsc~ipt.

decla~ations.

END;
T obviously points to a record obiect of type XX.
But
what if the debugged procedure P is placed
in
a
surrounding program which also contains a type xx.
Usinq
many compilers, T is now a pointer to the outer XX.
Is
this interpretation proper?

(Also allow PTR to te referenced within the record.)
Allow

arbitrary

scala~

types

in

case

tag

field

2. Our
any

compiler will
messaqes.

erro~

process the declaration below without

"rn
ttl

:;:c

=

:r>
:::0

-<

TYPE COMPLEX

Language
1977.

RECORD
REAL: REAL;

Il'IAG: REAL
END;
Should it produce aD error message?
3.

Maybe two?

Exact rules for type compatibility should be stated.
We
r""cf'ntly received a proqICam which passed a O•• 100 variable
as a VAR INTEGER parameter.
Should this be leqal? If so,
how can valiJ ranqe cheCKS be performed?
How about two
record declarations having identical field structures (and
names)?

4. Our compiler used to loop when it encountered the
below.
TYPE A :
VIR

BEGIN

X:

fA;

A;
Y:
X:= Y

B

=

'8:

Does VOUL compiler qenerate the

Notif<~.§.

12: 2. Feb

wirth. N•• "An assessment of the Proqramminq Lanquaqe
Pascal", SIGE!.A N 1!Q!j,£!l.§, J ul Y 1975.

[41

Fraley, R., "Parameterized Types", Unpublished Paper,
April 1975.

r 51

Wirth, n.,
"MODULI:
Multiproqramm

[ 6]

Fischer,
C.
N.
and R.
J.
LeBlanc, "Efficient
Implementation and Optimization of
Run-Time
Checking in Pascal", E!:2.!<.
!s;:~ \.;Qllf.
.Q!! Lall.!I
~~§i.!Il! fQ£
Helia~l~ ~oft~~~.
Raleigh.
N.C.,
March 1977.

f71

Dahl,

I 81

vanWijnqaarden, A. et al..
"Revised Report on the
Algorithmic Languaqe Algol 68", .:illiPLA.!! Notice.§.
11:5, 1977.

Languaqe

for

O.
et al.. £omJ!!Qll ~g&~ gll.9.J!i!.!I!l, Norwegian
Compo
Ctr., Oslo. 1970.

(* Received 77/09/13 *)

Conclusions
Extensive changes to Pascal have been sugqested
in this
paper.
The author feels
that changes of this maqnitude are
required if Pascal is to be useable for proqram development in a
professional settinq.
Quite a
number of additional features
could be recommended;
the changes above have the hiqhest
priority.

***

If Pascal was modified as described, we may need to call it
somethinq else, for it would no lonqer be Pascal.
PeLhaps it is
Pascal 11? Or Pascal 77? A standard languaqe resembling Pascal
~s surely needed, but why
shoul~
hun~reds
of
programmers be
~nvolved in writing a standard, new processors. and textbooks if
the standardized lanquaqe has a limited life or cannot be used
tor larqe svstems?

WHAT TO DO AFTER A WHILE

D. W. Barron

Do not condemn Fortran without understanding it.
It has
changed over the years to provide improved facilities for
program development,
even if its basic structure has remained
static.
Each feature, as used in proqram writing,
should have
an equivalent
in Pascal, or good reason should be given as to
why it is not.
Fortran owes its lonq life partly to its
standard, even though it has not been strictly impLemented.
But
~t also owes its life to its usefulness in solvinq many
of the
avery-day tasks of proqramminq, such as communication with the
operatinq system and referencing libLary packaqes.
Pascal would
Denefit from expansion in some of these practical directions.

&

J. M. Mullins

Computer Studies Group.
University of Southampton.

The Problem
Biblioqraphy

q

The problem is simple. If one writes while p and
do •••• will q be evaluated if p is false? The "boolean

operator" approach says yes, the "sequential conjunction" approach

I 1]

Jensen,
K. and N. Wirth,
Eg§£sl Usg£ ~~l
RgEQ£!, Springer-Verlaq New York (1976).

I 2]

Lampson, B. W. et aI.,

"Report

on

th~

sng

Proqramming

Modular

=
rn
U?

END.

Are these types leqal?
erLor message properlv?

.:illif!.!!

f 31

program

B;

Euclid" •

says no. The Revised Report leaves the question open (though the
User ManuaZ says "yes"). and A.H.J. Sale (1) has argued strongly
that the boolean operator approach should be uniformly enforced.
We take the opposite view.

A Proposal
We propose that in the forthcoming reV1S10n of the Revised
Report the operators and and ~ should be defined as
p and q _ (if p then q else false)
p or q _ (if p then true else q) •
The reasons in favour of this proposition are summarised here for
the convenience of readers who may not wish to study the detailed
argument in the remainder of this paper.
i)
ii)

iii)

Sequential conjunction permits a programming style that
is more in the spirit of PASCAL.
If sequential conjunction is adopted as the standard,
existing programs that assume the "boolean operator"
interpretation will continue to work. The converse is
not true. (This argument does not hold for programs that
rely on side-effects of functions, but we have no sympathy
whatever for those who perpetrate such monstrosities.)
If sequential conjunction is adopted as the standard the
effect of the boolean operator interpretation can be
fabricated by user-defined functions: the converse is
not true.

Programming style and the "spirit of PASCAL"

This is a natural way of expressing the operation to be carried out;
what follows the while is a sequence of guards. which determine
whether or not the body of the loop is to be executed. If we specify
that the guards are inspected in strict left-to-right order until
one of them "triggers" there are no problems: this corresponds to
evaluating the while condition by sequential conjunction. However,
if the boolean operator approach is used we are in trouble (array
bounds) if the item sought is not in the table. OK, there are lots
of ways round this, (e.g. put the item sought at the end of the
table, use a boolean variable, or even use a goto) , but as we
illustrate in the appendix, these are distortions: the program no
longer bears a simple and obvious relationship to the problem, and
this is bad style. Our contention is that the need to distort the
program to satisfy the boolean operator interpretation is contrary
to the spirit of Pascal. Study the examples in the appendix to see
the truth of this assertion.

Uniformity and Regularity
Our argument has concentrated on while statements (and
similar arguments could be applied to repea~til constructions).
This is because these are the only constrUCtions where the sequential
conjunction interpretation is required and cannot be fabricated by
other means. The question arises whether all occurrenceS of and and
or should be treated the same way. Sequential conjunction should
certainly be used for conditional statements. If the boolean operator
approach is used, we can fabricate the effect of sequential
conjunction by writing
if (p and q) then

The argument in favour of sequential conjunction hinges
on programming style. Efficiency is sometimes raised as a
consideration but it is a red herring. For some architectures
(e.g. pipelines) sequential conjunct~on is inefficient: for other
architectures it is more efficient. But in the Pascal community
we should have gotten beyond judging language features solely in
terms of implementation efficiency. What matters is being able to
write correct programs that are easily comprehensible.

table: ~

[1. .maxsizeJ

of whatever;

index := 1;
while (index <= maxsize) and (table [index] <> item)
do

index: = index + 1 ;

(*condition for item not found is "index> maxsize"*)

else

S2

Sl

else

as
ifp then begin
i f q then

S2

end

I-'
LO

One of the classic illustrations of the two approaches
is the problem of searching a table:
var

Sl

else

S2;

'-I

00

but this is not perspicuous, and is not in the spirit of PASCAL.
What should happen to boolean expressions in other contexts
e.g. expressions? If we were starting the language design again, there
would be quite strong arguments for allowing the boolean operator
interpretation in these other contexts. It is a good principle of
language design to separate clearly the data objects and the permitted
operations on them from the mechanisms for achieving flow of control.
Sale's paper distinguishes between boolean expressions in a jump
context and in a value context. He is recognising (unconsciously
perhaps), that whilst boolean variables are data objects, and can be
combined into boolean expressions, the condition following an if or
a while is something different. To emphasise the difference,
might give it a different name; taking a term from English grammar(3)
(an obscure subject, rarely studied these days), we could call it a
protasis. Because it is a different kind of object it is possible for
it to obey different evaluation rules, and sequential conjunction is
the right approach. Equally, because it is a different kind of animal
we would need a new notation e.g. and, ~ for sequential conjunction,

we

•

The first of these relations defines sequential conjunction.
The second defines sequential disjunction, but we shall use
the term "sequential conjunction" to include both.

•

Compare Dijkstra's if and do constructions expounded in "A Discipline
of Programming". (2)-

boolor for boolean operator.
This is the solution adopted
by some other languages e.g. POP-2(4), RTL/2(S). But given that we
have a fairly well defined language already that we don't want to change,
it seems better to make sequential conjunction uniformly the method
to be used for evaluation of and and or in all cases. This has the
supreme advantage that existing-programs (and particularly compilers)
continue to work, and don't have to be changed to conform to a new
standard. It also happens to be the rule adopted by MODULA and EUCLID.

~,

Appendix
Searching a list without sequential conjunction
1.

var table : array

Before leaving this topic it is worth remarking that the
dangers of confusing a protasis with a boolean expression are well
illustrated in Algol 68. The pursuit of regularity, orthogonality,
etc. allows us to write
while

Sl;

B do

INSERT A DUMMY ITEM

[1. .maxsizeplusone]

of whatever;

index := 1;

table [maxsizeplusone] := item;

S2;

while (table [index] <>item)

meaning

L:

Sl;

if

B then

S2;

goto

do index : = index + 1;

L;

(*condition for item not found is "index=maxsizeplusone"*)

which is thoroughly confusing.
Getting the best of both worlds
Adopting the sequential conjunction interpretation allows
a more natural style of programming. (Compare Welsh's compiler with
Amman's to see this illustrated vividly.). If anyone really wants to
enforce the boolean operator interpretation of and he has only to
define
function
var

andop (p,q : boolean)

2.

USE A BOOLEAN VARIABLE
~ table: array [1 .. maxsizel of whatever;

notfound : boolean;

boolean;

index := 1;

pl,ql : boolean;

notfound := true;

while notfound and (index <= maxsize)
pI := p; ql := q;
andop := pI

and

(*ensures both arguments evaluated*)

do if table [index] = item

ql

then not found

false

else index := index + 1;
then he can replace while(p and q) by while(andop(p,q»
be assured that p,q will bo~be evaluated.

and be

(*condition for item not found is "notfound"*)
3.

References

USE A.§Q!Q
label 9;

1.

Sale, A.H.J. Compiling Boolean Expressions - the case for a
"boolean operator" interpretation. PUG Newsletter No. II,
1977.

2.

Dijkstra, E.J. A Discipline of Programming. Prentice-Hall,
Englewood Cliffs, 1976.

var table

array [1. .maxsize]

.£!. whatever;

index := 1;

3.

Onions, C.T. Modern English Syntax. Routledge and Kegan Paul
London 1971.

4.

Burstall, R.M., Collins, J.S. and Popplestone, R.J.
in POP-2. Edinburgh University Press 1971.

while(index <= maxsize)
do if table [index] = item ~ goto 9
else index := index + 1;

5.

Barnes, J.P. RTL/2 Design and Implementation.
Son, London 1977.

Programming
9: (*condition for item not found is "index> maxsize"*)
Vl

Hayden and

C)

(* Received 77/09/21 *)

ADAPTING PASCAL FOR THE PDP 11/45
D. D. Miller
GTE Sylvania, Inc
Mountain View, California

ABSTRACT
This paper describes our adaptation of the University of
illinois' PASCAL student compiler for a PDP 11/20, to a
production compiler on an 11/45. We will discuss, a) the
extensions to the language which were necessary to communicate between PASCAL programs, data and MACRO-II
code, b) support routines such as a routine debug and source
update and reformatting, and c) how we introduced PASCAL
into an existing software system and to MACRO
programmers.

INTRODUCTION
HistOrically GTE Sylvania has delivered turnkey
systems with software written in machine language.
For all the usual reasons management decided to
investigate the possibility of developing software
based on a higher level language. The target project was a system which was already in the field,
but under contract for a major revision. The system controls a real time experiment. It has several special purpose I/O devices and doesn't use any
DEC software. It is about 25,000 lines of macro-11
code and runs on a PDP 11/45 with 64K of memory.
In March 1975 we attempted to locate compilers other
than FORTRAN which were running on all-series
machine. Candidate compiler s had to be able to
handle complex data structures with ease and would
have to generate LINKable code so we could build
our own system. The only compiler we could find
to meet these criteria was PASCAL at the University of Illinois. It was running on an 11/20 under a
version of DOS-4.
We began in-house training for PASCAL using the
Jensen and Wirth User's Manual l in April. The
legal aspects of acquisition were completed in the
meantime and the Compiler was ready for use in
May.
We then wrote some toy problems to get a better
feeling for PASCAL and to test its non-standard
features. In June we identified the changes we
would have to make and tho se we woUld like to make,
and then laid out a schedUle.

The production compiler was released to the programming staff in November so that they could begin compilation. It. was completed in December
according to our requirements. But we continued
to modify it as we saw the need.

: = . I .
: = 

 : = program < identifier>;

= 

< modUle heading>
= modUle ;

= 

= 
< statement part>



A program is an executablfO entry, i. e., it contains
outer block code and has a start point. A modUle

is a non-executable entity, i. e., it does not contain
outer block code.
A modUle is composed of data and procedure declarations only. ModUles allow for portions of the
system to be separately programmed and compiled.
Selected data elements and/or procedures and functions can be accessed from other modUles or froIn
t~e program via the external and entry declarabons. Data spaces consist of the following types:

"rn
t:P

We will discuss the specific changes we had to
make to the compiler, a description of the supporting software and the non-technical problems we encountered introducing the compiler to the staff.
CHANGES TO PASCAL

normal
external
own

=

~
;;;0

Normal data space is the same as Jensendescribed.
Normal data space is allocated on the "stack" upon
entry to a procedure and is deallocated (erased,
lost) upon exit from the procedure. Each entry to
a procedure which declares normal data structures
causes space to be reallocated to those data structures. Consequently, no memory of previous value s is retained, and the same stack space may be
shared among procedures'.

The changes outlined in this section were made because the several programmers are all working on
a single system. The system as originally designed, had a large common data base which was
accessed by all programs. And the system contained several utility programs. Furthermore,
from a practical level, the routine s in the system
are better developed and maintained in smaller
units. A fifty page PROGRAM is more difficult to
develop and maintain than five ten page PROGRAMS.
A fifty page PROGRAM may also exceed the compiler s table limits.

external data space consists of those data structures that are used locally but are allocated in another Inodule or MACRO program and have been
declared as either entry points or global. The
usual declarations are used to describe these data
structures, but no space is allocated for them.

Program Cross Linkage

~

PASCAL does not allow linkage to data outside the
PROGRAM and only allows linkage to predefine external utility programs. This was unacceptable as
we expected to make use of existing MACRO code
and data. Therefore the major change to the compiler was to implement the following syntax:

;;;0

data space consists of those variables that are
allocated in a program or a module but are not put
on the It stack." own data structure s retain their
values from procedure entry to procedure entry.
~ data structures may be initialized and/or may
be designated as entry points. Entry points are
used by LINK to resolve references created by use
of EXTERNAL data spaces in other modUles.

-<

V1

f-'

Example:
program LISTEN:
external
~

TALK: CHAR:

procedure SPIT (ANSWER: CHAR):
procedure ASK:
end

exte rnal:

begin
while TALK = , 'do ASK:

Storage is allocated in one of two modes, normal
and packed. For normal storage allocation (i. e. ,
the variable has not been declared as packed, it is
not a packed type, and is not part of a packed
variable) each unstructured variable is allocated
either a byte or word. A byte is allocated for scalars with less than 128 elements, for subranges
within -128, +127, and for char. A full word is allocated for all other unstructured type s. If the next
element to be allocated is a full word and the next
available byte is an old address, then that byte will
be skipped and the full word will be allocated on the
next higher even address. Arrays and records are
allocated as a set of contiguous elements.

module SAYSO:
own
TALK: CHAR:
initial TALK: = , ':
procedure ASK;

1.

With tagfield in record
~

X:(A, B, C) of

A:(

):

B:(

):

C:(

end
2.

Without tagfield in record
~

:boolean of

true:

SPIT (TALK):
end.

Examples:

packed records are allocated in a slightly different
manner. Each element is allocated only the number of bits necessary to contain the element. If the
next such element to be allocated will fit within the
current word then it will be allocated there. If the
element does not fit, then it will be allocated starting at the next even byte. Allocation of elements
starts at bit 0 of a word and proceeds to bit 15
(i. e., from right to left).

):

false:
end

Additional Functions

We found that we needed several functions added to
the compiler

begin READ (TALK) end;
procedure SPIT (X:CHAR):

Examples of PACKED record:

begin WRITE (X) end;

Channel

Status

Unit

entry TALK, ASK, SPIT.
In this example the main, or controlling program is
program LISTEN. Within LISTEN the procedures
SPIT and ASK are declared external, indicating that
these two procedures may be invoked but are not defined within this program. The assumption is that
some other body of source code defines these two
procedures appropriately. The variable TALK is
also defined as external to the program.
The module SAYSO satisfies all of the external references made by LISTEN. Note that the variable
TALK is declared in·~ space (a necessity for
entry points) and is initialized to' '. TALK, ASK,
and SPIT are declared as entry points, i. e., they
may be referenced from other modules or programs
as externals.
Packed Records
The Illinois PASCAL didn't allow packed record or
array declarations. But our existing system contained a lot of packed data, which naturally .fell into
the packed record syntax. Since Wirth leaves the
semantics of packed records to be defined at implementation time, we chose the following scheme
for stor age allocation:

STATUSWORD = packed

~

UNIT: 0 •• 15;
STATUS: array [0 •• 8J of boolean:
CHANNEL: 0 •• 7

Procedure MACRO (CODE:INT;X:INT): This procedure reference signals to the compiler to generate an inline word of instruction. This is the mechanism to be used if special instructions must be
executed in the middle of PASCAL code. CODE
must be -I, and X may be either a constant or the
name of a variable. IF X is a constant then that
value is the value used. IF X is a vari~ble, the p_
relative address of the variable is used.
Example:
MACRO (-I, 016746B):
MACRO (-I, X):

Variant Record

W:

e chru:ged the syntax of variant record descriphons shghtly to ease the job for the compiler and to
make the presence or absence of a tag field in the
record more consistent. The semantics of this
syntax means that the record mayor may not contain space for the tag field. The variant record is
similar to FORTRAN's equivalence state~The
syntax is
:= ~ :  of
[ < variant subfield>} end
:=  I empty - etc.

Procedure TRAP (TRAPNO:INT:var SPECBLK:tbd:
varLINKBLK:tbd) This procedure first places the
addresses of SPECBLK and LINKBLK on the stack
then executes a trap instruction. The trap number
is indicated by the parameter TRAPNO. The code
generated by the compiler for this procedure call
is:
mov
#SPECBLK, -(SP)
mov

#LINKBLK, -(SP)

trap

#TRAPNO

Function FIRST (X:INT):INT: This procedure reference signals the compiler to use the lowest value
defined for the parameter X. X may be of type
integer, scalar or subrange. See below for example of usage.

V1

N

Function LAST (X:INT):INT;
This function reference signals the compiler to use the last, or
highest, value defined for parameter X. X may be
of type integer, scalar, or subrange.
Example:
~

X: 13 •• 21;
Y

(A, B, C, D);

X

= FIRST (X);

while (X:=X+l) <= LAST(X) do;
for Y:=FIRST(Y)!£. LAST(Y) do;
Function ADDR (X:TYPE): TYPE; This function
generates a pointer (i. e., the address) to the variable given as a parameter.

The compiler included a cross reference pass.
This pass sorts all the routine variables and prints
all references to that variable along with its definition. This feature is found on very few compilers
but is a valuable aid to debugging and maintaining
any block structured language routine.

Z:integer;

var

Y:t integer;
Y:=ADDR(Z) end;
Function POINTER (X:int):t; This function causes
the integer parameter to become a universal
pointer. This allows the programmers to do pointer arithmetic:
Given the following declarations:
~ DIGITS = array [0 •• 9 J of integer;

var

of PASCAL is seven core loads, linked together
with disk files. There are two routines the compiler writer has to debug PASCAL. One prints all
the intercommunication files and the other prints
the resultant code in MACRO format. This second
routine was originally the last pass of the compiler,
and generated input to the MACRO assembler. However that final pass had to be modified to print out
its table of PASCAL labels and statement numbers
versus relocatable address. This was required to
relate console debugging to compiler listings.

X:DIGITS;
W:DIGITS;

Z:integer;
then we may write the following statements:
W:=addr(X);

"W points to X"

The University of Illinois included a source deck
reformatting routine. This routine is used to enforce a consistent statement indention scheme
throughout a program and across all programs.
This permits all programs to be more portable between programmers. To assure that it is used regularly, we added a line editor to the front end, and
embedded the whole thing as the first pass to the
compiler.

curiosity) concerning some practical applications of
the language to the problem that they were familiar
with. Occasionally, some suggestions were made
to improve the data definitions. And thus a gradual
acceptance of PASCAL was beginning to be seen.
The modification of the target system included fir st,
documenting the existing system and then upgrading
it according to customer requirements. Necessarily
the documentation was carried out at a high level,
i. e., higher than machine language flow charts.
And as the system was modified, the same high
level documentation technique was used. It would be
ideal to conclude at this point by saying that the documentation style closely resembled PASCAL, but
that simply isn't true. Each designer developed his
own style. What did take place is that they learned
how to express their ideas in a language above that
of the machine while still precise enough to be
short of arm waving.
As the language decision date approached, the
lines-of-code estimates for the two language alternatives were made. Based on those estimates
alone, PASCAL was clearly the choice. However,
some of the designers, looking forward to coding,
were appalled by the suggestion the machine language was still being considered.

NON-TECHNICAL PROBLEMS
At the outset, the project staff was composed of
six programmers; five had just completed delivery of the predecessor systeIn. The author had
been hired to complete the staff. The five had little
recent contact with high level languages. Most had
spent their career at the machine language level.
And so when it became known that management was
considering a high level language for the project update their reaction ranged between-disbelief and
rebellion.

When PASCAL was finally declared to be the language, real programs began to appear. And consequently the designers' imagination crashed the
compiler on a regular schedule. Syntax was added
and in one case (the variant CASE) changed at the
suggestions of the designer turned programmer.
So finally we realized not only acceptance of
PASCAL, but an effort to improve it to better describe the problem at hand.

:2

rn

-n

rn
tel

=

c:::
:J>

=
-<

Acknowledgments

Z:=addr(X[2J );
Z:=addr(W[ 3J );
Z:=pointer(ord(W)+6); "Z points to X [3J or
W [3J"
X [1 J:=ord(Z)-ord(W);

"# of bytes"

lLpointer (ord(addr(X»=addr(X) "true"

Of course management was quick to point out that a
high level language was only being considered and
that the language decision would be made in the
future, based on availability and economic factors.
And of course, the basic design of the project
wasn't affected by the language. So design could
continue independently from the language.

then • • • ,
SUPPORT ROUTINES
The University of Illinois supplied us with several
debug and support routines, which we have enhanced. We have written others to support the user.
The compiler writer must.have access to intermediate results in order to find errors. This version

When the Illinois version of PASCAL was chosen as
the candidate compiler, in-house classes were
held, and the basics of the language explored. When
the compiler actually became available, a few five
line programs were attempted by the staff.
The first relevant PASCAL introduction for the five
was a compilation of the system's data areas in
June. This sparked some discussions (out of

We wish to acknowledge Professor Don B. Gillies
(deceased), Ian Stocks, and Jaynt Krishmasamy of
the University of Illinois for their assistance in
transferring the PASCAL compiler from the
PDP 11/20 to GTE Sylvania's PDP 11/45. In addition we wish to acknowledge the National Science
Foundation for making the Illinois PASCAL compiler available to GTE Sylvania. Especially we
must thank Larry Drews and David Shaw, whose
foresight and diligent work modified this version
of PASCAL.

(* Received 77/09/13 *)

(1)

Jensen, Kathleen; and Wirth, Niklaus
"PASCAL User Manual and Report, "
Lecture Notes in Computer Science,
Volume 18, Springer-Verlag, 1974

IJ1
1.'\1

- 2 -

(C)
PASCAL:

Standards and Extensions

Modification to the Standard for

and Case Statements

currently, multiple statements under control of a while statemp-nt are bracketed by a

A. General
In this article I ~ould like to· make some comments on the current standards/extensions
argument, and to suggest some specific modifications to the standard and some useful
extensions.
In my opinion the. following points are relevant to the standards argument:(1) Any implementation of PASCAL should conform to some minimum "standard". This
is the basic requirement for portability, which is so necessary if PASCAL is ever to
supplant FORTRAN. If any implementation does not meet this standard it should not be
called PASCAL.
(2) The standard should be based on the revised Report. However, there are areas
in which the Report needs tidying up before the standard can be specified (see the
contributions by Niklaus Wirth [pp. 22-24, PUGN #8] ,Andy Mickel [pp 28-30, op.cit.] and
below) •

begin ••• end pair, those under control of a repeat statement are bracketed by the
repeat and the corresponding until and those controlled by a case statement
by the ~ and end.
--While admitting that these forms are reasonably strightforward, I think they are
inconsistent. I consider that programming style can be much improved with little or
any extra compilation cost by treating all statements controlled by a control statement in a consistent manner, i.e. by grouping with a begin ••• end pair in the form of
a compound statement.
-To my mind the greatest advantage of this is that related statements are always grouped
in the same manner and that when reading a program each end matches with a corresponding begin.
I therefore suggest that the standard syntax for the repeat staement be modified to:
repeat +  ... until +  --I and that the syntax for
the

(3) Extensions should be allowed, but they should be "conventionalised" as
suggested by Andy Mickel [loc.cit.]. By conventionalised I understand that any extension
to provide a specific function should be consistently supplied in only one standardised
form. Possibly, only extensions that can be expressed in standard PASCAL (albeit in a
possibly lengthy or inefficient manner) should be allowed (?).

(5) The standard should be specified as soon as possible to restrict the current
proliferation of incompatible implementations. The standard should hopefully be agreed
upon by some form of concensus of the PASCAL user/implementor community. There should
also be some recognised means of conventionalising any extensions.
On the Standard Language

I would like to briefly discuss some of the points that Andy Mickel [loc.cit] has placed
in categories of standards and extensions.

(1) I think that variable extent arrays as formal parameters should be allowed
as part of the standard.· For many general purpose applications programs these are
virtually indispensible unless the source code is to be modified each time for each
specific appiication. (See also the discussion on varying arrays below)

~

statement be:

case

~



-+ of"'"

begin - - etc.

Admittedly the repeat statement can already be used in the
suggested manner, however I don't think it would be a bad thing to force programmers to
use

(D)
(4) Any compiler that implements extensions should also be capable of processing
only the standard language. This would enable any program to be checked against the
standard. This could be controlled by a compiler option indicating whether the
standard or the extended language was to be processed.

B.

~

~t

in this way!

Varying Size Arrays as an Extension

This extension to the language is prompted by a foreseen need for varying length
character strings (they make the manipulation of non-numeric data so much simpler!).
However in as much as a character string can be considered to be an array of char

or a packed array of char, the idea can obviously be extended to any array, with the
added advantage that the treatment of many problems involving the use of varying
quantities of data might be simplifed.
I therefore suggest the following extension to the declaration of array types:-

--rL----------~--"-rL------------J~~---~ ~ 2t ---~

~

packed

--.J

etc.

~~

The declared size of the array would be treated as a maximum only, the initial size
being zero.
As an example, a variable declared so:-

(2) Some decision must be made on a standard character set upon which the
type char is based.
(3) While the suggested otherwise part in a case statement would be useful I
don't think it is essential. However, I do think that the standard should specify the
action to be taken when a missing value is encountered, i.e. error or null operation.
(4) I would like to keep well away from formatted
as well).

~

statements (see below

Taking into account the above consideration, I agree basically with the cl~ssification

of the various points discussed by Andy Mickel. However, I do have some additional
points which I would like to see discussed. These are dealt with below.

~

S:

packed

varying array [10 •• 19] of char

would be a string of maximum length 10, the first element being SILO] and the initial
length being zero.
I think that such an extension would minimally require the following extensions in
addition:(1) A concatenation operator to allow appending of one string or array on
the end of another.
(2) An additional form of selector to allow the equivalent of the PL/I substring
function.
For example give S above, the reference:- S[12 •• 15]
would be equivalent to a
reference to a variable of type
packed array [12 •• 15] of char.

"

rr1

t:D

::::c

c:
:t>

::::c

-<

- 3 -

- 4 -

This form of selector need not apply only to varying arrays but could apply to any arrays.
(A relevant aside: This idea would be even more useful if variables were considered
to be of the same type if they had the same structure, not just if they had the same
type identifier.)
(3) A size function.
varying or otherwise.
(E)

This would be used to return the size of any array,

A General Inverse to the Ord Function

Very briefly, I think that some function comparable to the char function but acting on
any scalar type (except real) as an inverse to ord would be very useful. At the
moment I canlt think wha~ call it!
(F)

A Different Approach to the Treatment of File Variables

Clearly, in case (a), (c) and (d) the files have some existence separate from the
program and the file variables used to reference them. There must be some way of
associating a file variable with such a "permanent" file in such cases. This is
currently done by effectively passing the files as parameters to the program and
associating the file with the file variable by the file variable identifier. This
seems to me to be 04K. as a start particularly if the operating system provides some
method for associating external and internal file names (e.g. B6700 label equation).
However, I think this method has two disadvantages. Firstly, it seems to imply that
the files must exist for program execution to be successful, there is no reason why
this should be so. Secondly, it lacks flexibility in that a file variable must always
be associated with one particular file during program execution.
I would like to suggest that a file variable only bcome associated with a file when
the file variable is referenced by a file reference functon or procedure, e.g.:

There has been much discussion on the meaning of statements such a8:fl

(d) Exist~nce before, during and after program execution (e.g. permanent database file).

:=f2

where fl and f2 are both file variables.
I think much of the discussion has arisen through some conceptual confusion between
a file and the file variable used in PASCAL to reference a file.
I would like to suggest an approach to the whole subject which I think is different
to those that have been put forward before, but which is both natural to PASCAL and
consistent with the normal usage of file variables in PASCAL.
The notation ft (where f is a file variable) for an item in a file is identical to the
notation pt for the variable referenced by the pointer variable p. Thus file variable
f could be considered to be a pointer variable tied to the set of items in the file
which it references.
(It should be noted that this argument does not assume that an
item in a file need be transferred to a file buffer before it may be used even
though it may be transparently implemented in such a manner~)
Then,just as pl:~p2 (where pI and p2 are pointer variables based on the same type)
assigns to pI a reference to the same variable as it referenced by p2, so fl:~f2
(where fl and f2 are file variables) assigns to fl a reference to the same item in the
same file as is referenced by f2.
Consequently, the expression fl=f2 would have the value true if and only if fl and f2
referenced the same item in the same file.
The use of file variables as formal var or value parameters is also obvious by analogy
with the similar use of pointer variables.
The use of file variables in any other expressions (except as parameters to I/O
procedures or when qualified by t as in ft) would be meaningless and should be treated
as syntax errors.
Naturally enough, the usage of file variables in the above statements and expressions
would only be legal if the base types of the relevant files were the same.
As has been mentioned by others, files can have four basically different kinds of
temporal existence:(a) Existence before and during program execution, but not after (e.g. file
removal in a archiving system).
(b)

Existence during program execution only (i.e. a scratch work file)

(c)

Existence during and after program execution but not before (i.e. file

creatibn).

4

or

eof (f),
get (f) ,
put (f),
reset (f),
rewrite (f).

Until a file variable is associated with a file, it should have the value nil or an
an undefined value (is there/should there be a difference?). A file variable could
be disassociated from a file either by setting it to nil, or by using a procedure
such as
close(f).
It may be considered useful to have a corresponding procedure, the only action of which
is to associate a file variable with a file, e.?
open (f)

-n

rn
CO
;:;0

=

::t>
;:;0

-<

Of the four types of file discussed above, for (a) and (b) we need to be able to
indicate that the file is to be expunged from the system and that the file variable is
to be disassociated from the file. For cases (c) and (d) we need to be able to
disassociate the file variable but leave the file known to the system. May be a
procedure
delete (f)
or something similar, could be used'to perform the first of these functions and let
the suggested procedure close perform the second.
(What should the default action be?)
When performing output to a file we need to be able to distinguish between creating
a new file (case (c) above) or outputting to an existing file (case (d)). When
creating a new file it is possible that we may be creating a new version of an already
existing file. I would suggest that by default, output to a file should append to a
file if the file already exists, or to a new one if not. If it is wished to replace
an existing file, this can be done by preceding the first output to it by a rewrite
(or possibly a delete).
So far it has been assumed that a file variable is associated with an actual file by
correspondence of names, i.e. the file variable ~ would reference a file known
to the system as ~, unless over-ridden by some operating system control. If a
file variable is to be able to be associated with files at will then there ought to
be some method of associating a file name with a file variable. To make things
simpler this could be restricted to being legal only when the file variable is not
associated with a file. A possible way of allowing this would be to introduce
(yet another!) standard procedure,
e.g. name (f, s)
where f is a file variable
s is packed array of char and contains the name of the file.

V1
\J1

- 5 -

Finally, I would like to put in a plea for random access of files. While accepting
that a file should be considered as a sequential data structure, I think that the
term sequential should only be considered to imply that there is some positional
ordering of the items in the file and not that the items may only be accessed sequentially. Thus, I think it should be possible to access any item of a file at random
using a procedure such as

- 6 The actual values assigned would be the constants represented by the characters in the
textfile, each constant being separated by one or more blanks, or possible a comma.
i.e. with the textfile input containing the following characters:12 TRUE -1.342

seek(f,n)
where n (of type integer) is the ordinal number of the item to be referenced.

If the

GREEN 'ABCDE'

n'th item does not exist the eof (f) would become true.

15

2.

i :=12;

D:=TRUE;
r:= -1.342;
c:=GREEN

Notes:

5:= IABCDE I ;
~

1.

This scheme assumes that

2.

Seek(f,l) is equivalent to reset(f).

3.

Failing anything more efficient, seek(f,n) could be implemented by:

and put may be mixed on the same file.

The occurrence in the textfile of a constant of the wrong type for the variable should
cause an error.

reset(f);
i:~O;

while not eof(f) and i<>n do

begin get(f); i:=i+l end;
An alternative to using seek would be to extend get so that

get(f,n)

put(f,n)
5. While the file variable can be conceptualised as a pointer to an item in a file,
it would probably best be implemented still as a pointer to a buffer area and let
the various file manipulation procedures be responsible for the data transfer between
the buffer and the file.
I/O on Text Files

I think there is a great need to rationalise the methods of I/O on text files,
particularly with reference to the read statement.

output to a textfile using the write statement should produce the characters representing the relevant constant value, preceded by a blank so that any output produced by
a write statement could be input by a read statement. The current simple formatting
in the write statement, using a field width specification, could be retained provided
there is some predefined action (non-fatal error, or default output) if the value
will not fit in the given field width.
H.

would assign to f, a reference to the n I th item in the file. get (f) would still assign
to f a reference to the next item in the file.
Similarly for

G.

2

read (input, i,b,r,c,s,v) would be identical to

If the action required by the seek was not possible on the particular file, then a
run-time error condition should be indicated.

4.

-5

the effect of

Addition of Exponentiation Operator

If PASCAL is to ever supplant FORTRAN then I think an exponentiation operator
(e.g. **) should be included at least as a conventionalised extension, if not in the
standard itself.
I.

In Conclusion

I suspect that some of my suggestions (if not all) will not meet with the general
approval of PASCAL implementors and users. However, they do cover my main
dissatisfactions with the language (or at least the ones that I don't think are being
adequately dealt with by others) and I hope they will be food for thought. In
writing all the above, I have tried to bear in mind that there are basically three
areas of application for PASCAL with possibly conflicting requirements:-

Present suggestions are for

i.
ii.
iii.

formatted read statements, this I do not like.
In roy opinion, execution of a read statement should be considered to be equivalent
to the assignment to the relevant variables of some (unknown) constant values. The
values should be represented in the text file in the same way that the same constants
would be represented in the program. For example, given:
type colour = (red, green, blue);
var i: integer;
b: boolean;
r: real;
c: colour;
s: packed array [0 .• 4] of char;
v: array [1.3] of integer;
the effect of
real(input,i,b,r,c,s,v)
should be to assign
an integer value to i,
one of true or 'false to b,
a real value to r,
one of red, green or blue to c,
a character string of length 5 to s,
and an integer value to each of V[1],V[2] and V[3].

I-'
lD

'-I
00

A simple teaching language
A satisfactory replacement for FORTRAN
A useful and powerful systems programming language.

I think that PASCAL can (but doesn't at present) fulfill all of these, without straying
from its basic principles, but it is necessary to take care that in suggesting
modifications one doesn1t push one use at the expense of the others.
Above all, I would like to see some consistent standard (and soon!) that implementors
would feel morally obliged to adhere to if they wish to call their language PASCAL.

Chris Bishop,
Computing Centre,
University of Otago,
P.O. Box 56,
Dunedin,
NEW ZEALAND.

(* Received 77/12/27 *)

U1

0">

Department of Computing Science,
University of Adelaide,
North Terrace,
Adelaide,
South Australia 5039

LEIBNIZ-RECHENZENTRUM
DER

BAYERISCHEN

AKADEMIE

BARER STRASSE 21

DER

WISSENSCHAFTEN

D-8000 MDNCHEN

2

28th October, 1977.
:2

Pascal User's Group
c/o Andy Mickel
UCC: 227 Exp. Enr.
University of Minne~ota
Minneapolis, MN 55455
(612)

Miinmen, den
Telefon (089)

9.11. 1977

~: ~:;84, 84

HW/br

Telex: 05124634

376-7290

Dear Mr. Mickel,
thank you very much for sending me PASCAL Newsletters
so promptly. Sorry that I am not equally prompt with my
thanks.
On my PUG llIembership certificate you ask wether I am the
"EULER" Weber; sorry, I am not. My interest in PASCAL has
begun'only half a year ago when we received the ZurichCompiler for our CYBER 175 (with Operating System NOS 1.1).

::E:

Also in PN, it was announced that a PASCAL-Software pool will
be created and will be handled by the respective compiler
distributors. Can you, please, inform me what libraries ~a~€­
available for CYBER 175 on what conditions.
I enclose an American Express Cheque to the amount of US $ 7.00.
Please send me another set of backissues and two issues of
each PN for my membership year. Beside the set for our
official library I should like to have one for my own.
I am very expecting PN 9. The other ones I like very much.

en

I am writing to correct an impression which may have been given
by Arthur Sale's letter in Pascal News, September 1977.
At the University of Adelaide, we were fortunate to have access to
Pascal several years ago because the University computer was a
CDC6400 - I personally first taught Pascal to students in 1974.
After two years experience with earlier versions of the language,
in 1976 the department adopted Pascal as its main teaching language.
We have no;vcompleted two years of teaching wlth Pascal as the main
language in first year, second year and third year!
In detail, some
500 students in our courses are programming in Pascal in anyone
year - writing programs from prime number generators to compilers.
The number of enthusiasts is growing!
Yours sincerely,

At the PASCAL-meeting of the German Chapter of the ACM I met
Urs Ammann who told me that you could probably help me with
information about interactive PASCAL-Systems for CYBER 175/
NOS 1.1.
From PASCAL Newsletters I learned that the maintenance of the
Zurich System is now in your hands. Did you get from Zurich
a list of all installations of their system? Anyway we are
very interested to be on your mailing list for future
corrections, extensions (?!) and releases. From Urs Ammann
I heard that in early 1978 there will be Release 3 includinq
dynamic arrays. Since I am interested in procedures for
mathematical algorithms, I will be very glad about this
extension.
/

rn

Dear Andy,

Barbara Kidman.
Copy to:

Professor A.H.J. Sale,
University of Tasmania.

***

Thomas J. Kelly Jr
58-8 Meadowlake Drive
Downingtown. Pa. 19335

f-'
ill

'-J

Gear Andy

3 Nov 1977

co

Just a short note to tell you:
I've moved. new address is above.
I've changed jobs: I now work for Burroughs Corp.
I exerted some
effort and we are now using the UCSD implementation of PASCAL on our
B7700. for any other 87700 users who need a compiler. you can get one
from UCSD. I suppose. It's okay. but we have discovered several bugs.
There is also a fix that ~eeds to be installed to allow the generated
code to r~n properly on a B77JO (as opposed to B6700).
I will send that
fix on to UCSD. I don't know if they'll put it in.
If anyone wants to.
they can get one directly from me (at the above address).

Yours sincerely,

\Wl--l

\N~

Helmut Weber

We are currently beginning work on adapting Brinch Hansen's Sequential
Pascal for one of our internal projects. Interest in PASCAL and its
derivativEs (especially MOOULA) is increasing here at Burroughs. whiCh
I can't say that it is all my
I consider to be a very good sign.
doing. but I like to believe !'ve helped.

Direktorium: o. Prof. Dr. G. SeegmUller (Vorsitzender), o. Prof. Dr, F. L. Bauer, o. Prof. Dr. G. Hammerlin, o. Prof. Dr. K. Samelson

-0

:J>
Gl

rn

Take care.
V1

Open Forum for Members

'-I

THE UNIVERSITY OF BRITISH COLUMBIA

Open Forum for Members

2075 WESBROOK MALL

VANCOUVER, B,C., CANADA
V6T lW5
25 August 1977

DEPARTMENT OF COMPUTER SCIENCE

rn

wce Memor ial Hall w.
Indiana University
Bloomington, Indiana
October 12, 1977

47401

Mr. Andy Mickel
Editor, Pascal Newsletter
Computer Center
University of Minnesota
Minneapolis, Min ~54~~

Andy Mickel
University of Computing Center
227 Exp. Engr.
Univ. of Minnesota

(/)

Minneapolis, Minn.

U.S.A. 55455

Dear Andy,

Dear Andy:
I have finally found the time to rewrite the paper which I sent last spring.

I would like to add my two cents worth to the
concerning Pascal.

animated

discussions

I believe that the difficulties that arise while using interactive
input files would be resolved if a GET was required before the file
variable was defined. This would allow a programmer to state explicitly
when
(s)he wanted the first read from the file.
This modification could
be made to Pascal, and currently running programs would compile and run
correctly by simply adding a GET at the beginning of the program.

I'm afraid it was sent without proofreading.
It is much longer now so I've divided
it in two parts in case you want to print it in installments.

I disagree with your statement about not changing Pascal [PUGN #8, pg. 29J.
You may have guessed this by the nature of the accompanying paper.

Pascal can,

and should, be changed now, before a standard is created.

-"

rn

You state that documentation, implementations, and software exist, so the

language should remain static.

But minor changes will be needed to all of them

ttl

when a standard is created, so it is a good time to make other needed changes.

I think that the discussion of standards is missing historical
observatons of natural languages. Well standardized languages are dead
languages! One only has to look at I,atin or ANS Fortran.
I believe t~at
the following proposal would allow Pascal to evolve, but at the same t1me
allow portability of programs. The laguage processed by a translator can
be called a dialect of Pascal if:

;;:0

A change from Pascal to a revised Pascal ("Pascal 11") can be compared to the

change from Fortran II to Fortran IV which occurred in 1964.

A mechanical translator

aided in the translation, but many long hours were spent re-writing programs. A
Pascal to Pascal II conversion should allow a more effective mechanical translation
to occur, but machine-dependent features and under-the-counter type conversions

=

:t:>
;;:0

-<

would hinder this effort.

1.

It includes "Standard" Pascal as a subset.

2.

The implementor has provided a mechanical translator (written in
"Standard" Pascal) of the dialect into "Standard" Pascal.

I would be willing to accept a dialect that satisfied both of these
conditions as "being consistent with the design of Pascal." Of course,
when a program in the dialect was shipped to another installation,
the
dialect version and either the "Standard" version or the translator would
also be sent.
I would suspect that it might be reasonable for
the
"Standard" version that is appropriate in this context to be be
"sub-Standard" in compar ison to the present idea of "Standard" Pascal.

The point is this: a change now will affect a relatively small number of
people. If you wait until a standard is made and then try to change the language,
the amount of pain and agony will be increased by an order of magnitude or more.
I don't pretend that every change suggested in my paper would produce a
superior product. Some have not been tried; none have been subjected to a large
user community.

I am describing problems which I have found with proposed solutions

so that reactions can be gathered. Above all, I do not suggest that change be made
for its own sake, but that change remain an open possibility.
While committee action is not good for a language design effort, it can be
effective for the task at hand.

I would like to obtain copies of the back issues of PUGN, but I have
two sheets that conflict in the listed prices. How much would it be for
the issues that you have.

Designers in the committee can independently create

language versions which combine the present language with the suggestions
presented in the newsletter.

Committee critics can force a justification of each

change, and can compare different solutions to problems. A group from varied
backgrounds can provide a degree of universality which a single designer cannot
hope for.

'
?
I:lf(/·.i.
Sincerely,

~~"'.'

Robert A. Fraley

,/

\.T1

00

HEWLETT", PACKARD
3500 Deer Cr-eek. ROlJd. Palo Alto, California 94304, Telephone 415494--/444, TWX 9/0 373 1267

November 7, 1977

Is the set above of type SET OF 0 .. 10? Type SET OF 0 .. 59? I can't tell. This
is one situation where the strong typing of the "pure" language fails, and the
resulting type is therefore left to the implementor.
I would make three proposals:
1.

r

=
r1"1

S [A, B, C]

2.

Dear Professor Sale:
I read with interest your contributions to PUGN #9.
of reactions.

Here are a number

While I am strongly in favor of an "ELSE" clause in the CASE statement,
I do not like your choice of keyword. In my recent work at the University of
British Columbia I found that a common error, committed both by students and
faculty members, is to place a ";" before the word ELSE in an IF statement.
It was so common that (in our extended compiler) we allow an optional semicolon
in the IF statement. This has several effects:
a.

Programming errors and resulting frustrations were reduced.

b.

2-token look-ahead is required. (In a recursive descent parser,
a Bool ean fl ag can be added to i ndi cate whether a ";" was swa 11 owed
by the IF statement procedure before discovering that no ELSE
exists. )

c.

Combined with your syntax, 3-token look-ahead is needed.

Without this addition, however, an IF statement in the preceding case clause which
contains an erroneous semicolon will probably get an obscure error message.
Our choice for the default clause designator was the token "<>". We thought
that it looks nice, and it suggests that values not equal to the other labels
should use this clause.
Sets of characters are a problem, but I think you missed the heart of the
issue, at least in this discussion. The Pascal standard does not define the
meaning of sets, so implementations differ. Sets behave in many ways like
PACKED ARRAY [type] OF BOOLEAN
except that "type" must start at 0 and has a fixed upper bound (in some implementations). If such a restriction were placed on arbitrary arrays, with the
upper bound being implementation defined, the users would scream loudly. So
why make such restrictions on sets?

3.

This allows explicit control

::E:

en

When the elements of a set constructor are a scalar type T
other than INTEGER, the current set constructor produces type
SET OF T
rather than a subset of this type.

~
~
~

The current set constructor is illegal with non-constant INTEGER
operands. The notation in point 1 above must be used.

One other point which you raised was the character set question. I am
sick and tired of this problem, due to the variety of character codes which
I've encountered. (1401 BCD, 7090 BCD, 1620 code, Univac 1108 code, CDC code,
EBCDIC, ASCII, and occasional others.) The ASCII code was agreed upon ten
years ago by representatives from across the industry, and closely resembles
the international standard code. While its purpose is information interchange,
we could contort its original purpose and say that programs are indeed information, and their algorithms (to be transportable) must be expressed in terms of
ASCI I.
If Pascal were to impose an ASCII rule today, it may alienate a number
of supporters. But if users don't push for some sort of standard. we will never
free ourselves of this problem. Pascal currently requires that '0' .. '9' be
contiguous. Perhaps it could also require that sets such as
['!' .. '@']

be interpreted as containing those ASCII characters between '!' and '@'. This
requires a conversion table at compile time to compute the set. In those
relatively rare occurrences where the 1imits are· variable, a runtime conversion
table is required.
An eventual goal of ASCII in all aspects of the language within (say)
five years might be nice. It might encourage Pascal implementers to prod the
hardware companies into supporting ASCII files and allowing an override of
the ASCII to internal conversion for terminal input. (Univac provided such
facilities several years ago for the 1108 series.)
I am enclosing some of my own suggestions for Pascal changes, which will
appear in PUGN #11. I am looking forward to hearing your reactions to these
suggestions.
Sincerely, ,

.52

<----TA
/Gt-OA.-1flJ
c{.

Sets of characters aren't the only problem. I am implementing an interpreter which has 150 instructions, defined as a scalar type. Will I be able
to transport my program if I use sets of these instructions?

(~~

Robert A. Fraley
Hewlett-Packard Laborato ies
Electronics Research La oratory

The one language "feature" which prevents a general definition of sets is
the set constructor.
[3, I, TRUNC(EXP(R))]

en
n
:t:>

When S is a set type,
denotes a set of type S.
of the s ubrange.

Professor Arthur Sale
Department of Information Science
University of Tasmania
Box 252C
Hobart, Tasmania 7001
Austra 1i a

-c
:t:>

-c
:t:>
Gl

rn
V1

RAF/hma
cc: Andy Mi cke 1

<0

"OMSI Computing" is a product and service name of Oregon Minicomputer Software, Inc.

December 26, 1977
Dear Andy,
It seems that we owe you and the Pascal User's Group a good
deal of information about our work with Pascal, so perhaps
this letter can serve as an informal introduction.
'We' are a small group of computer freaks who have been
working and playing together for about 7 years. The group
is an outgrowth of the Student Research center of the Oregon
Museum of Science and Industry (OMSI), a not-for-profit
private science education center in Portland, Oregon.
To make a long history short, we began in 1970 with a very
small DEC PDP-8 system and over the years grew to a large
PDP-8 and a large PDP-ll/45 computer facility. This
expansion was mostly financed by swapping software written
at OMSI with the manufacturer (DEC) for additional hardware.
Several past and present DEC software products were first
developed at OMSI (the PDP-ll APL is the latest example).
The group members (John Ankcorn, Don Baccus, Wayne Davison,
Steve poulsen, Barry Smith, Rusty Whitney, Dave Vann) grew
up as assembly language programmers. Our interest in Pascal
began when Wayne noticed the Acta Informatica report - our
continued interest is probably because Pascal has the
structuring tools we found necessary (and available!) in
assembler. Pascal is also "small enough" for practical
implementation, efficient for real-world programs, and (if
used carefully) really machine independent.
(I should note
that we're not Pascal fanatics - we use several other
languages, and follow Wirth's Modula with much interest.)
Our Pascal history shifted in 1974 to Electro-Scientific
Industries (ESI) in Beaverton, Oregon. ESI manufactures
precision electronic equipment, including computer
controlled systems for on-line laser trimming of hybrid
integrated circuits. The first laser systems were
controlled by DEC PDP-8's with a special-purpose language.
When ESI switched to PDP-ll's and was faced with the task of
rewriting the control software, we (somewhat hesitantly)
suggested Pascal for the implementation. ESI's enlightened
management (Don cutler, Bob Conway) agreed, and ESI
sponsored the development of a PDP-ll Pascal compiler (ESI
Pascal). The compiler (initially patterned after an early
version from the University of Illinois) was written by John
Ankcorn and Don Baccus with assistance from David Rowland,
and became largely stable in early 1975.
Significant features of ESI Pascal include:
_ single pass compiler coded in PDP-ll assembler
_ translates to assembler code (not interpretive)
- full standard Pascal
_ extensions for process control
_ stable, reliable production compiler

Expe:ience with ESI Pascal at ESI and OMSI has certainly
convLnc~d us of the practical utilty of the language - if
anyone Ln the PUG needs a showcase example of "Pascal in the
non-aca~emic world", contact ESI.
However, ESI's design
constraLnts resulted in a compiler which is not as
gene:al-purpose as one might wish. Specifically, the
requLr~ment of a 16K word operating environment led to a
very tLghtly coded bare-bones compiler (both Wirth and Tony
Hoare exp:essed surprise at the 11K word (22KB) compiler,
and I belLeve we have a reasonable claim to the smallest
standar~ compiler in existence).
The ESI compiler is not
well sULted to the "naive user", and of course an assembler
coded compiler is hardly portable.
Agreeing with Arthur Sale's comment that Pascal must have
very robust compilers and support software if it is to be
taken seriously, we began in late 1975 the development of a
to~ally new Pascal programming system.
The compiler for
t~LS system was written in standard Pascal and was designed
wLth s~v~ral coequal goals: efficiency of compiled code;
portabL1 7 ty of the compiler and support system; robustness,
and usab 7 1Lty o~ ~he entire system. We attempted to see
each desLgn decLsLon from the user's viewpoint rather than
the compiler writer's. Our view of the 'typical user' is
the professional Pascal programmer - one who expects system
software w~thout glitches or rough edges, one who works in a
p~scal e~vLronment wLth high-level support tools (excellent
dLa~n~s~Lcs at compile and :u~t~me, Pascal debug and library
fac71LtL~s, measurement facLILtLes for practical
engLneerLng) •
The comp~ler for this system (written almost entirely by Don
Baccus) Ls.currently producing code for some members of the
PDP-~l famLly.
It LS certainly larger than the ESI Pascal
compLIer ~runs in 2-4 phases, depending on optimization and
other ~ptL~ns), but the time from compilation to program
e~ecutLon LS roughly the same (the compiler produces
dLre~tly executable object files, whereas ESI Pascal
requLres use of the assembler and object linker - both much
slower than the compiler!).
Recently (October ~977~ we formalized our relationship and
created ~ ~orporatLon Lndependent from the science museum Oregon MLnLcomputer Software, Inc.
(known simply as Oregon
Software to our friends).
"Out of the frying pan, ••• "
We've arranged with ESI for Oregon Software to distribute
and supp~rt ESI Pascal (we call it OMSI Pascal-I). The
updated Lmplementation notes should read:
Implementors,
Jo~n A~kcorn, Don Baccus, David Rowland;
Distributor and
M~LntaL~er, Oregon Software;
Machine, any model PDP-II
(LncludLng LSI-II); Configuration, 16K memory RTII
RSTS~E, or.RSX.ope:ating systems (all the DEC ~ystem~ at
last.~;
DL~trLbutLon, 9 track 800 bpi magtape, DEC
cartrLdge dLsk, $1500 ($995 for educational use)·
Reliabil~ty, exce~lent - currently about 60 inst~llations
and growLng steadLly.
We've also been talking with Ken Bowles at the University of
California, San Diego, and are pleased to announce that the
UCSD Pascal system is available now for RSTS/E timesharing
systems - a~ ex~ellent system for introducing programmers to
Pascal • . PrLce.Ls.not yet fixed, but should be established
by the tLme thLs LS published.

en
Cl

Our new Pascal programming system (known as OMSI Pascal-2)
is not yet available - we'll keep you informed as to our
progress with the PDP-ll and other machines.
One last note - we have a limited supply of Pascal T-shirts
with a portrait of Blaise Pascal from a woodcut frontispiece
for a bi?graphy published in 1891 - see enclosed copy.
These sh1rts are 100% cotton, hand silk-screened, available
in sizes S, M, L, XL - price is five dollars postpaid from
Oregon Software.
Merry Christmas, and a happy New Year!

Barry Smith
Oregon Software
4015 SW Canyon Road
Portland, Oregon 97221
(503) 226-7760

Dear Andy,
Just a short note to describe an application of Pascal here at I.e. over the last couple
of months.
All university computer installations must be plagued by their share of Startrek games,
mostly written in the most hideous basic or horrendous pl/i (sorry Ploughskeepie).
Naturally most of these installations suffer because of it, both in terms of machine time
wasted and the constant staff overhead of having to spend hours looking for and destroying
incarnations of the game only to have a PhysiCS undergraduate restore it the same evening.
Our own case was slightly different. The Department runs VM on a 370/135 with 384k of
store. MerCifully, our basic compiler wouldn't handle the Startrek program run on our
College Computer Centre's CDCs: but even had it compiled, it could have been debatable
whether the kind of response that would have been achieved could have justified the tag
'interactive'. Thus we set about writing our own Startrek, in Pascal, which we hoped
would be more elegant and efficient than the versi_ons we had access to.
The user interface was designed and implemented by Greg Pugh (the guy who implemented our
P4 compiler). It maintains a full screen display on Lynwood VDUs, showing the status of
The Lynwood features
the Enterprise, short and long range scans, damage control etc..
blinking, cursor positioning, protected mode etc. and Startrek uses them to the full.
Using the cursor positioning, only the fields that change between moves are updated.
This leads to a faster (and more exciting) game. Because everything is continuously
displayed on the screen, we have been able to remove all the commands controlling the'
display (like damage control report), so the user only has to remember about 10 commands.
These are entered as English words, like 'WARP' :no more lost games 'cos you typed 3 hoping
to fire photon torpedoes and actually warped into a Nova!
We produced our first version in June '77, which ran quite successfully (and efficiently)
despite the abuses received during our department's open day.
However (and this is the interesting bit, I hope!) we have since extended the Startrek
system to run up to 16 users simultaneously, without modifying one line of the source code.
This was possible because of the natural re-entrancy of Pascal code. All that was needed
was a small interrupt handler (1000 lines of Assembler) to interface Pascal and the
terminals. As each user 'dials' into Startrek, the interface routines find some store for
his (her) stack/heap, and enter the Pascal bit of Startrek at the beginning. The program
runs until it initiates I/O, at which point it is suspended and other users run until it
completes. Because Startrek is thorough-ly I/O bound, we have experienced no problems
with its being totally interrupt driven (indeed on VM the level of I/O activity is a boon;
it stops you from getting dropped from the "fast response" queue!).
We have run 8 simultaneous users on the same Startrek program, with no notiapble degradation
in the response of the system generally or of Startrek itself.
Since Startrek has paved the way (boldly going where no man etc ... },we have really "gotten
into" multi-user Pascal programs here at IC. lain Stinson has written a filing/archiving
system which services 16 users simultaneously_ A multi-user context editor is on the way.
I think the thing that surprised us was the ease with which all these were implemented. In
all cases, the actual low-level interface needed was surprisingly small and took very little
time to write. The Pascal programs, because they do not need to know that they are multithreaded, are equally easy (and of course are easily tested with a more conventional,
single user interface).
Anyway, if anyone is interested, send us a tape (preferably containing some goodies of your
own) and we'll return a copy of the system (including our Pascal compiler). Please specify
800 or 1600 BPI. The game itself has a "user manual" in the form of a Starfleet technical
directive, but unfortunately only sketchy implementation notes exist.
Keep Blaising the way_
Live long and Prosper.

4015 SW Canyon Road

Portland. Oregon 97221

(503) 226-7760

Dave Thomas.

Department of Computing and Control,
Imperial College
180 Queensgate
London SW7
London 589- 5111

=

.,.,
rn

co
:;0

=

::t>

:;0

-<

en
I--'

THE

UNIVERSITY

OF

NEW

P.O. BOX 1

•

SOUTH

KENSINGTON

•

N.S.W.

WALES
•

AUSTRALIA

•

2033

TELEPHONE 6630351

EXTN.

STATE OF MINNESOTA

PLEASE QUOTE

Department of Computer Science,
School of Electrical Engineering.

Crime Control Planning Board
6th Floor, 444 Lafayette Road
ST. PAUL 55101

December 30, 1977.

November 7, 1977
Dear Andy,

Andy Mickel
227 Experimental Engineering
University Computer Center
University of Minnesota
Minneapolis, Minnesota 55455
Dear Andy:
In the September 1977 issue of Pascal News I was quoted regarding LEAA
(Law Enforcement Assistance Administration) regulations vis-a-vis programming languages for use in criminal justice information systems.
While the thrust of that quotation was essentially correct, it may be
useful to publish the actual guideline referred to:
From:

First let me congratulate you and your colleagues for the excellent job you have
been doing on the Pascal News(letter}.
The new Australasian distribution arrangernnents will certainly be welcome to people
down in this part of the world and I am grateful to Arthur Sale for offering to
print and distribute Pascal News but I too am confused over the Australasian subscription rate of $lO~
This makes Pascal News the most (relatively) expensive
journal/newsletter to which I now subscribe.
You can take it as considerable proof
of the quality of your publication that/if members continue to subscribe.
The
price disparity between the Australasian on one hand and the USA and UK subscr.intion
rates on the olhe!" is such that Australasian 5ubsc,::,ibers are surely owed a public
explanation (through Pascal News).

U.S. Department of Justice
Law Enforcement Assistance Administration
National Criminal Justice Information
and Statistics Service
Comprehensive Data Systems Program Guideline
Manual (M6640.l, April 27, 1976)

I feel I must correct Arthur Salo's misleading claim to "a first for reactionary
Australia" for his proposed switch to Pascal in his first year course in the next
academic year.
That Australia is reactionary js beyond doubt but surely Arthur is
letting his newfound enthusiasm for Pascal blur his perspective of what is happening in the rest of Australia.
Simply to set the record straight and without any
pretension to claiming a "first", I would like to point_ out that the computer
Science Department at this University has been teaching Pascal as a first and
principal programming language for the past three years.

Chapter 3/Paragraph 37d:

I enclose a collection of sundry comments on various ascpects of Pascal.

Whenever possible, all application programs
will be written in ANS COBOL in order that
they may be transferred readily to another
authorized user. Where the nature of the
task requires a scientific programming language, ANS FORTRAN should be used. Request
for waivers shall be justified in writing
first to the appropriate Regional Office
and then to NCJISS/SDD for review.

-n
rn
ttl
:;:0

c::
:t>
:;:0

-<

Best wishes.
f-'
LD

Yours sincGrely,

'-.j

00

Ken Robinson

The most recent Direction of Automated Criminal Justice Information ~­
terns shows virtually all existing Criminal Justice software (whether developed under the federal guideline above, or by a local agency without
benefit of such paternalistic guidance) to be written in COBOL or FORTRAN.
Sincerely,

";j~t.Kt~
Community Crime Prevention

MRJ/amc

Sundry comments on Pascal
Standardization: I fully support the current moves for standardization of Pascal,
however I beleive a number of minor changes should be made to Pascal before such
standardization takes effect.
I disagree with Prof. Wirth's sentiment (PUGN #8)
that changes should not be made to "Standard Pascal" as "it would seem unfair to
suddenly declare that what once was a Pascal compiler now suddenly isn't any longer.
Standard revision must be prepared to add or even change features to a language if
there are compelling reasons for doing so, and as a result it has to be accepted
that compilers will be obsoleted and require change.
Pascal should be kept alive
as a language; standardization could sound the death knell of Pascal somewhat
earlier than necessary.
FORTRAN standardization provides an example which should
not be followed - FORTRAN is of course dead; many people do not realize it.

1I

m
N

Exponentiation: The exponentiation operator should be part of Standard Pascal.
The look of disbelief when a Pascal programmer first discovers that it doesn't
exist!
Complex: 'Complex' should be added as a predefined type. Have you ever tried to
convince a sroup of Electrical Engineers to use Pascal? They work most of the
time in the. complex domain and when you explain how you do complex arithmetic in
Pascal
'
Pascal is surely not only for compiler writers.
who work with real and complex numbers.

We cannot ignore programmers

Semantics, Axioms and Undefinedness: The comment is frequently made that Pascal
"leaves undefined the action of a CASE where the expression evaluates to a value
not matched by a case label" (PUGN #6 p60),or some such similar comment,. usually
implying that the action is left to the whim of the implementor.
Nonsense! The observation above is quite precise: the action is undefined not
arbitrary. Just as the action of mUltiplying two boolean expressions is undefined.
We seem to have become accustomed, due to our experiences with badly implemented
software or even hardware, to confuse lIundefined ll with "arbitraryll. Surely if an
action is undefined we expect good software to detect such an infringement of the
semantics and to signal an error? Incidentally there is no analogy between a case
statement with no label for a particular value of the case-expression and a if-then
statement in which the boolean expression; the semantics of the latter are quite
well defined.
On the above question and many others the axiomatic definition of Pascal by
Hoare and wirth [lJ is very clear and I am surprised that this paper is not
referenced more frequently within discussions of the semantics of Pascal.
The case-statement: I fundamentally lean towards Wirth's position that the case
statement should not have an exception case (else label) but one particular
exercise has fairly well convinced me that such a facility is necessary.
The exercise: write a reasonably portable lexical analyzer in Pascal.
Solution 1: Use a case-statement to classify the next character. Then all characters
will have to appear as case labels, but many/most of the characters in ASCII/EBCDIC
are unprintable (at the least) which certainly does not aid documentation. Some
characters may even be all but impossible to include in the program, for example
chr(O) in the CDC character set does not always have a character representation;
the ETH compiler gets around this one by predefining a constant (undocumented)
COL = chr (0) ~
Solution 2: Guard the case statement using a set as follows:
if next character in set of characters of interest
then
case
-- nextcharacter of
end
else
Useless~ due to the severe constraints on set of char in most implementations
(see below).
solution 3: Guard the case statement by selecting a subrange as follows:
if (nextcharacter >= first character of interest)
and(nextcharacter <= last character of interest)
then
case
-- nextcharacter of
end
else
OK for ASCII but not of much help for EBCDIC.
in solution 1 remain.

In general the problems encountered

Solution 4: In desperation you might abandon the case statement and use a mapping
vector to map from char to an enumerated scalar type. This solution eases the
portability problems but at some cost: the mapping vector is neither easily nor
efficiently tnitialized in Pascal!
Conclusion: the case statement remains attractive, but an exception case label
appears to be necessary when disciminating on an expression of type char. I
beleive the exception case is not necessary for expressions of another type.
Note: the lexical analyzer in the ETH compiler is not a good solution to the problem,
being solution 1 above. Unfortunately (or fortunately) the CDC character set is
small enough to mask most of the problems which arise with larger character sets.
Set of char: I am inclined to go further than Arthur Sale (PUGN #9,10 p66) in
relation to minimum set size. Rather than picking an arbitrary number such as 32
I feel it would be better to insist that every Pascal compiler should support
set of char for its particular character set(s). There is nothing to stop the
compiler optimizing in the case of smaller sets of course.
Without the above requirement sets containing characters must be banned from
programs which are required to be portable, and surely many if not most large
programs should be portable.
For statement: While agreeing with Arthur Sale's comments on the semantics of the
for-statement (PUGN #9,10 p66) I disagree with his suggestion of describing the
semantics in the form of an equivalent Pascal sequence. A similar scheme was used
in an earlier Pascal Report and was rejected in the axiomatic definition of Pascal
[lJ for reasons of over specification. The definition of the for-statement given
in the axiomatic definition is not open to the same ambiguity as that discussed
by Arthur Sale since the concept of "assignment to the control variable" does not
enter the axiom. Nor does the axiom say anything about the final value of the
control variable, i.e. it is "undefined" (see above).
All of the problems associated with the control variable are removed if the forstatement is implemented in such a way that the control variable is local to the
statement (as does AlgolW and dare I say Algo168) 1 the value of the control variable
after executing the statement is beyond discussion since the variable no longer
exists! I strongly urge that the Pascal for-statement be implemented in this way
and note that it is only an ~plementation change - the semantics as defined in the
axiomatic definition are not changed at all.
Files: I must disagree strongly with many of Arthur Sale's numerous criticisms of
Pascal's file type. A file is definitely a valid data structure and it is one of
Pascal's strengths that file is but another predefined structure and not some
strange special object. True! Pascal, at the moment, only supports sequential files
and there are other file structures which are ignored, amongst which direct access
could be singled out as a file organization which should be supported. I would
disagree with wirth's second thoughts (PUGN #8 p23) of substituting "sequence"
for ufile"; perhaps the qualified "sequential file" instead of simply "file" is
preferable but I feel that the word "file" is required as a reminder to the
programmer that this structure will in general reside on secondary storage.
Why is an array of files an absurdity? Done any merge sorting lately?
As for file lifetime and scope being bound; doesn't this give you the perfect
realization of a temporary file associated with a particular process? The anomaly
of the lifetime of external files and their apparently different scope is removed
by my suggested change to the program statement below.
The program statement: Pascal's program statement has been frequently picked on
as "an importation from CDC FORTRAN" and as some kludge to allow external files
to be specified. There seems to me that there is a lot of truth in these observations but the real problem is that the program statement should have the same
form and function as the procedure statement. After all a program is really only
a distinguished procedure which is called from an outer block (level 0) which
represents the external environment.

."

rn
ttl
;:0

=
J>
;:0

-<

I would like to see the syntax of Pascal changed (as shown in the syntax diagram
below) to allow declarations to be placed at level 0 and for the program statement
to have the same syntax as the procedure statement except for the replacement of
procedure by program.
I assume a number of restrictions will be required, for
example a program may be declared at level 0 only and there must be only one program
- but maybe you could have more than one program?

Example:
Old syntax:
program foo(input,output,myfile) 1

The effects of this change are manyfold:

var

the files input and output would be declared implicitly at level 0 and thus simple

:2:

myfile: text;

external file parameters would now be declared as var parameters;
New syntax:

programs could reference input and output without specifying any file parameters
in the program statement;

program

foo(~

input,output,myfile: text);

external procedures and functions could be declared in their correct environment
and, assuming the compiler compiles an object of class "module", external procedures
and functions could be compiled separately without awkwardly (and usually erroneously) imbedding them in a dummy program environmenti
a program may now possess formal parameters other files.

Reference:

an

1. C.A.R. Hoare and N. Wirth: An Axiom~e Veninit{on
the P~og~g
Language Pa6eat
Acta Informatica ~, 335-355 (1973)

blockhead

***

unsigned integer

SPECIAL TOPIC: PASCAL STANDARDS
1-----'fr--~identifi8r~r------------------;
1-4---_ _---1...--_ _ _ _ _

block

module

&,______---'

(* Andy Mickel and Jim Miner *)

We (Jim and Andy) feel that it is a good time to review what is happening with Pascal
standardization and bring new PUG members up to date.
We believe it is essential to have a tight, officially standardized base language especially
on which to develop conventionalized extensions.
ISO STANDARD Pascal
In general, events are going very well in the effort to obtain an official standard. In a
very short time (less than a year) the effort is more than half done. For those of you
who haven't read PUGN #8, Tony Addyman is obtaining an official ISO (International
Standards Organization - the people entrusted with, for example, the metric system of
measurements) Pascal standard. Tony began to organize a British Standards Institute (BSI)
working group after the University of Southampton Pascal Symposium. It is passing on a
standards document consisting of the Revised Report with the semantics "tightened up." In
no case were new language features to be considered.
Tony is a member of the programming language committee at BSI, and his working group has met
several times (in June, September, and this January). Jim Welsh and R. Tennent have
supposedly written papers for the group which we at PUG central have not seen. So far
Tony has attended an ISO language subcommittee meeting in the Netherlands in November at
which he requested consideration of an ISO Pascal standard for the first time. A Swedish
technical committee also had representatives there to request the same thing. The French
and German representatives were also keen on the idea (the Americans were COBOL people who
"were not interested at this time."). A superior committee of ISO had to decide the
question, and after the necessary applications are made it should be on the ISO agenda by
late March (Ken Bowles" letter quoting 3-5 years notwithstanding).
One problem has been that up until now, all programming language standards have been
American (ANSI) standards and that ANSI has cooperated with the rest of the world. For
example the ISO COBOL standard is simply a couple of sentences which says to refer to the
ANSI standard. In other words, precedents do not exist for an ISO standard starting from
scratch. Apparently a group recently pushing for ISO ALGOL-60 standardization was helping
do the work to set precedents on procedure. The ALGOL-60 effort has been stymied, and ISO
is now considering mechanisms for advancing a language standard. As Tony puts it, the
UK has the conscience of Pascal "in its pocket because the UK proposed first."

We at PUG central have stated before our reluctance to go through a lengthy ANSI process
for a standard. COBOL, BASIC, and FORTRAN ANSI standards were long in coming. No one that
we know of has proposed going through the American National Bureau of Standards (NBS).
This may perhaps be an easier route. But we endo~se the current.E~ropean effort to
standardize Pascal - after all it is a language wlth European orlglns!
The Swedish technical committee announced their existence to -PUG with a letter from B~ngt
Nordstrom (in this section), and sent "Yet Another Attention List.'~ .We really appre~late
that and we're glad to see contact with the British. Further, Ollvler Lecarme has ln the
past'told us of the Pascal sub-group he coordinates in AFCET (the French counterpart of
ACM). We understand that the Germans are also organizing as a result of the successful
Pascal Conference in October held by the German ACM (see Here and There).
CONVENTIONALIZED EXTENSIONS
Pierre Desjardins wrote us on 77/10/13: "Have you given any thought as to how to proc;~d
once you (we, "the pascalers") decide to conventionize an extension of Standard Pascal.
Good question. Going back to last year in PUGN and at the University of Southampton
Pascal Symposium, we developed a consensus which directed the standards.effo~t t~ do
precisely what Tony is doing. Further, areas exist (such as those outllne~ ln Nlklau~
Wirth's letter in PUGN #8) in which there is no point in having different lmplementatlons
add similar constructs in different ways. ~o, if an implem~ntor chooses.to ~xtend Pa~cal
in a certain direction, he or she should stlck to an establlshed conventlon lf one eXlsts.
Ken Bowles' letter (in this section) proposes a workshop for the purpose of getting
together a set of conventionalized extensions: We ~eel t~is ~s a good first start.
Because there is a lack of practice and experlence ln havlng lmplemented a number of
extensions (such as variable extent array parameters), the results of the workshop should
not be interpreted as a final act.
LAUNDRY LISTS OF ADDITIONAL FEATURES
Pascal is often mistaken as a SIL (systems implementation language). Although it may be
good for writing compilers, Pascal without extensions cannot be used to write operating
systems, for example. We think more support should be given to making Pascal available for
general user use where there will be widespread benefit.
It is sad to see more people calling for more and more and more redundant and even whimsical
features in Pascal. Pascal's virtue is its small size (limit on the total number of
features) which has enabled its quick spread to other machines; implementation effort is
small. That's a significant fact. If you ever want to push your own language or large
software system someday, perhaps you can write it in Pascal for portability purposes instead
of straitjacket FORTRAN. So Pascal is paving the way.
With regard to these laundry lists of changes, people still seem to be forgetting things we
learned last year from discussions in PUGN: Niklaus Wirth wrote in a letter in PUGN #5, "we
must clearly distinguish between the language and the implementation ... the language is
defined by the Report alone, and intentionally leaves many details unspecified that an
implementation inherently must define in one way or another."
We think that dissatisfaction (leading to suggestions of new features/changes) may be the
result of problems in the implementation and could be solved in th~ implementation and not
by changing the language. Niklaus Wirth also wrote in a letter in PUGN #8: " ... most ...
other extensions ... belong to a different category which, I believe, has nothing to do with
the goal of obtaining a common language. Rather their primary objective is to introduce
some favourite facility suggested by either a particular application or, more frequently, an
existing operating system. Whereas I have no objection to such extensions in principle,
they do not belong in the core language, whose facilities must be understood without
reference to any particular implementation. If at all possible they should be incorporated
in the form of predefined procedures, functions, types, and variables and in the
documentation they must be clearly marked as facilities pertaining to a given system ... "
And what about the design goals of Pascal (which appear on the inside back cover of PUGN)?
Remember that the combination of these goals has to be considered. Some of the articles
we print in PUGN may unfortunately give the impression that there is a lot wrong with
Pascal because they are full of suggested changes. We are growing weary of such articles
which too often don't explain their suggested changes in the light of the design goals in
proper proport i on.

To quote Richard Cichelli, one of the world's foremost practition~r~ ~f Pascal in indust~y,
"the problem in the United States is not the lack of language facllltles, but rather mak~~g
programs understandable and to communicate them to average and below-average programmers.
We say that changes to Pascal are basically irrelevant. It is s~ far ahead of.th~
competition! It's strange that the phenomenon of real people uSlng Pascal as lt l~ for.so
many real things can be overlooked. People who need to get real work done now can t walt
for academics to come up with Utopia 84. So-called "improved" languages such as EUCLID
were announced before being implemented (shame, shame!) and are not tempered by good ole
practice and experience.
Let's examine as an example, the case for adding an exponentiation operator to Pascal. One
of the design principles of Pascal is not to hide time and space efficiency costs from t~e
user. An exponentiation operator makes it easy to be wasteful beca~se we dare say tha~ ln
FORTRAN, its most frequent use is to square a number. (Pasca~ ~rovldes a square ~un~tlon
(SQR) which can be compiled in-line for efficiency.) The addltlon of an exponentlatlon
operator confuses the evaluation of arithmetic expressi~ns . . Is -2**3**2.= -512 o~ :6~ or
64? Of course parentheses can be used, but exponentiatlon llke subtr~ctlon and dlvlslon
(but not multiplication and addition) is not associativ~ (or ~ommutatlve ~or that matter).
Also exponentiation is hard to axiomatize (like real arlthmetlc) so that lS probably another
reason why it was left out of the base language.
But by using the principle of extending the language th~ough predifined ~dentifiers, simply
predefine a function called power (as suggested by sectlon 11 of the Revlsed Report:
real;
function power ( x, y: real)
We know of implementations which have easily done this.
As a last thought, we don't think people should look at Modula, a langu~ge developed by.
Wirth for time-dependent ("real-time") programming, to find features WhlCh can necessarlly
be viewed as improvements. Modula's design goals are different. For one thing it is a much
smaller language than Pascal, and its syntax is stripped down, too. Modula is another
experiment, and we think it is an interesting one, but Modula will not replace Pascal in the
forseeable future.
Pascal COMPATIBILITY REPORT
To end on a bright note, on 77/12/19 we received an excellent report by Arthur S~le:
Sale, A.H.J. (1977): "Pascal Compatibility Report", Department of InformatlOn
Science Report R77-5, University of Tasmania.
.
which should be of interest to the standards working groups and we hope they obtaln a copy.
The abstract reads: "This report collects implementation variations between significant
Pascal compilers for the edification of users, the education o~ comp~tibl~ software writers,
and the influencing of implementors. In most cases, the behavlour clted lS a result of
(a) an explicit loophole allowed by the User Manual or the Revised Report, or (b) an
undefined loophole left by these documents. An attempt has been ~ad~ to document important"
differences only, not local extensions, nor areas where great devlatlons are to be expected.
A special note reads: "The information contained in this report is dated at November, 1977.
Since compilers change with time, and the ones on which the tests were m~de cannot always be
certified in mint condition by the author, caution is to be used in relYlng on.any
information found here. A future edftion of this compatibility report may be lssued as more
information is available."
The main report consists of a series of two-page sections containing a test program.and the
responses made by compilers to it and the questions posed. The responses are sometlmes
abbreviated to cut down verbiage at the expense of accuracy.
Test programs include: boolean expressions~ const declaractio~s, identif~ers, for loops
1, 2, 3, and 4, pointer types, set types, wlth statements, varlables, varlant storage.
Compilers used in the preparation of the report were the Burroughs B6700 (Tasmania),
CDC 6000/Cyber 70 (Zurich), ICL 1900 (Belfast), ICL 2900 (Southampton), Univac 1100
(Copenhagen), and the DECsystem 10 (Hamburg).

-n

rn
co
:::0

=

J>
:::0

-<

Department of

December 9, 1977

1977-11-30

COMPUTER SCIENCES
GOTEBORG

Yet another attention list
Dear Andy,
There is a growing interest of Pascal in Sweden,
both in industry, universities and other governmental
inGtitution~. There arc h0Jf-n-doz0n ~rou~~ working
with implementations of Pascal of some variety.
This interest has lead to a couple of meetings with
implementors, users and possible users. These meetings
have resulted in the creation of a technical committee
for Pascal in Sweden.

Swedish Technical Committee on Pascal
Department of Computer Science
Fack, CTH
S-402 20 Goteborg, Sweden
3.

Terminology: This section should cover all relevant terms
and expressions used in the definition of the language
(associate, identical, correspond, denote, undefined,
scope ... ). These should be defined, explained and/or listed

The goals for this committee are to:

for easy reference.

- critically analyze current definitions and implementations
of Pascal in order to discover problematic spots.

Special symbols:
nil is here listed as a reserved word.

- suggest a standard for implementation of Pascal which
solves most of these problems.

It is however conceptually a predefined constant comparable

- work for getting an international standard for Pascal.

to "true" and "false". The ETH-compilers view in fact nil

- in a second phase develop

as a predefined constant and you may redefine it.

- a programming standard for Pascal
- a standard for extensions of Pascal

Comments m2_y

- a "very" portable subset of Pascal.

not always be removed! They should be

considered as equivalent to space instead.
We have been in touch with the Brittish standardization
group. Vie find it very important that an international
standard group will be created. Otherwise there will
be several national variants of Pascal, which probably
will be hard to follow since the computer market is
very international.

4.

"values of scalar types" to first sentence (cf. Burnett-Hall).
The phrase: "Their association .•. " is neither clear nor
sufficient. What type of asso~iation? What about record
definitions and with-statements?

We would like to get in touch with any group working
with some sort of standard and also with implementors
and their lists of problems in the definition of Pascal.
Yours sincerely,

Identifiers: Add "programs", "fields and tagfields in record",

6.

Terminology: The terminology for description and
classification of types and their properties is obscure
to say the least (cf. below) .

The members of the committee are:

... associates an identifier with the type. array A of B is
a type. What is the associated identifier?

Per-Olof Lundberg, L M Eriksson, Kft, Fack
S-431 20 Molndal
Hans Lunell, Informatics lab, Linkoping University,
S-581 83 Linkoping
Lars MOSSberg, Volvo Flygmotor, Box 136,
S-461 01 Trollhattan
Bengt Nordstrom, Dep:t of Computer Sciences, CTH, Fack,
S-402 20 Goteborg
Staffan Romberger, Dep:t of Computer Sciences, KTH,
S-lOO 44 Stockholm
Ake Wikstrom, Dep:t of Computer Sciences, CTH, Fack,
S-402 20 Goteborg

6.1.1.

Scalar types: This term is in the subsequent usea to denote
at least three different things:
- all simple types;
- all simple types except real;
- the types that are described in this section.
UM-5A (p 34) states that they are given the values 0,1 etc.
Real: Is real a scalar type? Note that scalar types are
"ordered set(s) of values by enumeration"!

en
en

9.2.2.2. Why not change the syntax to:
6.1. 2.

Standard types: Are they predefined scalar types or
::=:

predefined simple types?

It is not good

Char: UM-2D (p 14 f) also describes some properties that
are shared by all implementation (cf. also Axiomatic

9.2.3.3. The manual and the report is not in agreement about the
semantics.

case : Certainly not every
typeidentifier.

6.2.4.

=

rn

Defini tion) .
6.2.2.

programming practice to jump between case

list elements.

9.2.4.

It can be argued that the with-statement evaluates its
 only once. This is part of a more

file of : Restrictions on type should be clearly

general problem: The philosophy of Pascal is to leave

stated.

certain things undefined so that a program which relies

Can a file be a part of other structured types?

on these undefined constructs is not portable. It is

Can new be applied to a file?

assumed that such a program is poorly written. But is this
the right way to prevent people from making bad programs?
It is usually not the same person who writes a program and

8.

evaluated (b+a)+c, but not as a+(c+b). What about a*b+c*d?
8.1. 2.

who transports it. The wrong person is punished.

Sequences of operators: The expression a+b+c may be
10.1,

Should passing of predefined procedures and functions

11.1.

as parameters be prohibited?

10.1.1. (l)What happens to eoln at reset of a text file?
(2)It has been suggested that reset should not assign the
value of the first element of the file to the buffer

The syntax for  is erroneous. The

and <> on pointer variables should be listed

m~never

possible, define typerules by a corresponding

 or several in the case of generic

here.

8.2.

functions.
and <> defined in UM-App B (p 108).

11. 3.

What are the types of the result of trunc and round?

Function application: There are several things left

11. 3.

How is ordinal number defined? With

undefined here. For example, in what order is the actual

type colour

(blue,red,yellow);

parameters (evaluated and) bound?

warmcolour

red •. yellow;

Especially in connection

with functions one has to consider side-effects, global

var

variables etc.

begin

c:colour; w:warmcolour;
c:= red; w:= red;

what is ord(c) and ord(w) and what is ord(-l)?
11.1.4.
9.1. 3.

\->

00

11.1.

Sets:

-<

'I

(for a Boolean b): or b.
Pointers:

=

:J>

<.D

variable.

possibility  allows you to write

8.1. 4.

t::O

:::0

var i: 1 .. 10?(5ee also the axiomatic definition: §1.3-1.4)
8.1. 3.

rn
:::0

Is type-checking of a subrange done only in assignments
or in arithmetic too? Is pred(succ(i)) always legal, where

-n

What is the significance of leading zeroes in a label?

Should succ of the last and pred of the first value
of a scalar type be explicitly illegal?

UNIVERSITY OF CALIFORNIA, SAN DIEGO
BERKELEY • DAVIS • IRVINE • LOS ANGELES • RIVERSIDE • SAN mEGO • SAN FRANCISCO

INSTITUTE FOR INFORMATION SYSTEMS

SANTA BARBARA' SANTA CRUZ

MAIL CODE C-021
UCSD
LA JOLLA, CALIFORNIA 9209_1

30 Dec, 1977
To Andy Mickel
PASCAL User's Group
Subject: Standardized PASCAL Extensions
As discussions in PUGN have made clear, many people in the
PASCAL user community feel it mandatory that PASCAL be extended in
various ways, either for specific applications, or to make the
language easier to work with in general. A large subset of the same
people are also very much concerned because all the extension
activity seems to be leading PASCAL into the same multi-dialect state
that characterizes BASIC.
You and others have ventured the oplnlon that the evolution of
PASCAL has already progressed beyond the stage where there is much
hope of obtaining formalized standardS, via ANSI or ISO, for more
than the language described in Wirth's revised "Report". One U.S.
representative to the ISO language standards activity told me
recently that it is not unusual for an item to take 3 to 5 years just
to be put on the agenda for ISO consideration. Those who cite the
short (two years) time it took to standardize MUMPS should recognize
that MUMPS is used primarily by a close knit user community concerned
with a fairly small range of applications.
My feeling, shared by many others, is that PASCAL is now being
accepted so rapidly as the base language for practical system
programming that there is no time for formal standardization to be
completed before extended versions of the language come into very
widespread use. In that environment, defacto standards are likely to
prevail, and there may be many defacto standards as is the case with
BASIC.
As an alternative to formal standardization, you have already
proposed that there might be formed sev.eral quasi-standard extensions
to PASCAL covering specific application areas. At a small PUG
meeting, held in Seattle during the recent ACM Convention, it became
apparent that numerous large industrial firms are preparing to use
PASCAL as the base language for serious system programming. The point
made repeatedly is that these firms find it necessary to extend
PASCAL to make this practical. The nature of the extensions generally
falls into several familiar areas which have been mentioned already
in the pages of PUGN - particularly random access facilities for disk
files. In general, each firm is making its own extensions since there
has been no evidence that anyone would come forward to coordinate the
extensions in this field of applications. The industrial people said
repeatedly that their firms would be making sufficiently large
investments in system programs using the extended dialects of PASCAL

(typically in units of Millions of Dollars) that they would find it
effectively impossible to retrofit to a standardized set of
extensions starting more than 6 months to a year from now.
I am aware that there is a subset of the current PUG membership
which feels that PASCAL should be retained by the academic community
as a basis from which to study better future languages. They feel
that extensive practical applications of PASCAL would prevent this
from happening, and argue that PUG should not assist in the effort to
make PASCAL a practical alternative to BASIC, FORTRAN or COBOL in the
world of computing at large. Judging from the rapid ~rowth of PUG
membership among those who wish to use PASCAL for practical purposes,
I would guess that the great majority of the membership would (very
soon if not now) favor pressing on with the promotion of PASCAL as
the next major language. I would also guess that, lacking leadership
from PUG or someone else, there will be a wide divergence of opinion
on what constitutes PASCAL in this sense.
The PUG membership should also be made aware of another large
scale activity that is sure to have a big impact on the PASCAL
community, like it or not. This is the project at the United States
Defense Department currently known as "Ironman". The ambitious goal
of this project is to force all development of so-called "embedded"
system programs to be done in a common programming language that we
can refer to as "000-1". The range of programming activities
currently excludes the major business applications, which tend to use
COBOL, and scientific applications, which tend to use FORTRAN.
Embedded system programming is reputed to cost 000 more than $3
Billion per year, much of it redundant or inefficient. The
expectation is that common use of the new language will make this
activity more efficient by a significant amount. At present the
Ironman project is waiting for delivery, expected in February 1978,
of reports on preliminary language designs from four contractors all
of whom are working from an overall specification published by 000
last year. All four are reported to be using PASCAL as their base
language. The overall specification makes it appear very likely that
000-1 will differ slightly from PASCAL within the range of the base
language, and it will contain many important extensions very similar
to those already being discussed for industrial and commercial system
programming. If all goes well, 000 expects to start implementing
early in 1979, after a round of additional refinements based on the
reports due this year.

"'T1

rn
ttl

:::c

=

::t>
:::c

-<

It is probable that any possible quasi-standard extended PASCAL,
as discussed in this note (I'll call it PASCAL-X from here on), will
differ in some respects from 000-1. If the Ironman 1977 specification
is held in the final 000-1 product, there will be no subset or
superset languages. If our experience with code compression is a
valid guide, this will probably rule out the use of 000-1 for
interactive program development on small microcomputers such as those
we use at UCSD. On the other hand PASCAL-X might amount to a large
subset of 000-1 and still be implemented on the micro's. A visit to

m
00

DoD in December convinced me that they too are very much interested
in using stand alone micro's for interactive program development.
Apart from the size issue, the major differences that will probably
make DoD-1 incompatible with the PASCAL base language have to do with
tightened rules to help prevent side effects committed within
functions and FOR loops. A persistent rumor that I have not yet been
able to check is that Niklaus Wirth himself has had a hand in
recommending that these rules be included in DoD-1, and/or in at
least one industrial firm's version of extended PASCAL.
At the Seattle ACM meeting, and on several occasions since then,
I have asked representatives of large industrial firms interested in
using PASCAL for serious system programming whether their companies
might be willing to participate in a 'workshop' convened to seek a
consensus on PASCAL extensions among such firms. The implication
would be that the influence of such a group of firms would be great
enough to make the consensus language, PASCAL-X, a defacto standard
for those interested in PASCAL for practical system programming. The
verbal responses I have received so far have been enthusiastic and
affirmative.
Lacking an alternate invitation, we propose to convene such a
workshop here at UCSD during the forthcoming summer, probably for
several weeks during July. In order to have a reasonable expectation
that the workshop will indeed emerge with consensus on a sUbstantial
range of extensions, it will be necessary to limit the attendance to
a maximum of about 30 people. Attendance will be by invitation only.
Those attending from industrial firms, and from government agencies,
will be asked to pay a registration fee of several hundred dollars to
help pay the expenses for running the workshop. In addition to paying
the fee, these organizations will be asked to give credible
assurances that the participant(s) they send will be able to
influence their employers to use the resulting consensus language.
Approximately three quarters of those attending should be from
organizations which will have made investments in practical system
programming uses of extended PASCAL exceeding 10 person-years by the
end of 1978. We would hope to attract a small number of academic
experts who enjoy the widespread confidence of large subsets of the
remaining PASCAL user community. The aforementioned fee will cover
the expenses of these experts, and of a small UCSD.group (mainly
students) who will serve as the staff of the workshop.
As a plan of action for the workshop, we propose that those who
expect to participate should begin circulating position papers and
proposals regarding features they wish to see included in the
expected consensus language PASCAL-X. Though we have no formal
commitment from them, it appears likely that the Defense Department
group will allow us to use the language descriptions resulting from
the Ironman project as part of the set of position papers. We assume
that the Ironman papers will allow a moderately accurate projection
to be made regarding the description of the expected DoD-1 language.
Assuming that our conjecture is correct, that DoD-1 will amount to an

extended version of the PASCAL base language with few
incompatibilities, we will urge the workshop group to make PASCAL-X
as compatible as possible with DoD-1. Naturally, we will insist that
PASCAL-X remain faithful to the overall philosophy embodied in
Niklaus Wirth's original design. Wherever incompatibilities with the
base PASCAL language seem frivolous they will be strongly
discouraged.
The workshop will probably consist of relatively short plenary
meetings on most days in the weeks when it is in session, plus
smaller working group meetings on specific topics. I plan to chair
the plenary meetings, as convener, in the hope that I may be able to
keep the attending group focussed on the objective to reach consensus
on as large a set of extensions as seems important to most of the
group. To assure reasonable acceptance of the results of the
workshop, most decisions will have to be reached by consensus - i.e.
with the acquiescence of virtually all of those attending. Except for
our own extensions associated with the pre-declared type STRING, and
with the READ statement for interactive implementations of the INPUT
file, we at UCSD still have relatively small investments in the
specific syntax of most other changes or extensions to PASCAL. We
will circulate position papers regarding these matters.
Copies of this note will be going directly, with invitations, to
representatives of the firms that we already know are likely to be
interested in participating in the workshop. Since we may not know
about others, readers of this note in PUGN should feel free to
contact us. Please bear in mind that we are a small group, and
currently close to saturated for communications with others due to
the high interest in our software package. For a reader who thinks that
his/her firm should be on our invitation list for the workshop, a brief
letter explaining why would probably be the most effective way to get
started.

..,.,
rn
ttl

=
=
=
-<
J>

Bowles
Director IIS

-0

:J>

=
rn
en
lD

Implementation Notes

PORTABLE
Pascal P4 -- How (Non-) Standard is it?

GENERAL I NF 0 RMAT I ON
A number
general:

of

short

comments are in order about this issue and our editorial policies in

Some of us at Pascal News

have

implementation~ "Standard

seen

a

Pascal"

disturbing
simply

trend

recently

to

label

differs from the standard in a number of significant ways. We have compiled the
_ INDEX: The index near the end of this issue covers the Implementation Notes from last
issue (/19-10) and this. issue. Earlier issues are not referenced because: (1) they are
out of print, and (2) the information in them was summarized and updated in #9-10.
_ Corrections:
Unless otherwise stated, the information in this
issue supercedes the
information in #9-10. We received several corrections (and complaints) about incorrect

information in #9-10. As

~

policy, we print the information that we

have

available

At the suggestion of Rich Cichelli we start with

next issue to print the source code of programs which are known

practice

of

writing

software.

to

be

useful

in

the
the

Rich will be editing this section, and programs may be

submitted to him for consideration. We also encourage criticism and

comments

on

these

programs. Rich's address is: 901 Whittier Drive, Allentown, PA 18103, USA. Also, Tom
Tyson (DECUS SIG)has offered to distribute software at cost. Details are not yet clear
to us, but Tom's offer is quite encouraging.
---- Pascal Variants:
We have decided as a policy to print notices of machine-dependent
implementations of Concurrent Pascal, Modula,
etc.,
in the
"Machine
Dependent
Implementations" section. Also, the "Index" will not discriminate between the variants
of Pascal. Notices of general interest will continue to appear in the "Pascal Variants"
section.

Checklist:

When

submitting

Data

implementation notes please use the Checklist (#9-10, page

60), and send dark camera-ready copy (see Policy, page 2!). As we begin to concentrate
more on applications~
standards, and software tools, we will be less willing to rekey

following

Systems Development;

Consultants; Suite 302; 1894 Commercenter West; San Bernardino, CA

92408),

using P4.
-Jim Miner

1. P4 implements nil as a predeclared constant, and forward as a reserved word. The
standard indicate;--that nil is a reserved word, and forward is not listed as a reserved
word.
-----

2.

P4 does not support the standard comment delimiters { and }.

3.
P4 does not provide the standard predeclared identifiers maxint, text, round, ~, or
dispose. Further, the following standard predeclared identifiers are recognized, but are
flagged as errors: reset, rewrite, pack, and unpack.
4. P4 does not require a program heading. Further, where a program heading is included,
P4 does not require it to contain a parameter list.
5.

P4 does not allow "non-discriminated variant record types"; i.e., every variant record

must have a tagfield. The standard does not require a tagfield.
6.

material which is not properly prepared.

z
rn

and also based on our own experience with P4. In no way do we intend this
list as
a
criticism of the authors of P4; rather we hope to raise the awareness of implementors

to

us. Although this sometimes leads to confusion, we have found that printing incorrect
information causes people to send corrected material
when they might not have done so
otherwise.

Software Tools, and Applications:

list of deviations, based on a list sent to us by Ted Park (Director,

Medical

P4-based

because they are based on P4. In fact, P4

P4 does not allow a ";" before the "end" in a record type.

(See the P4 Bug list,

item

3. )

- Jim Hiner (78/1/5)
7.

P4 does not implement any of the following file-related features:

~

Declarations of file types, variables, and parameters.
The standard predeclared type text, and the standard predeclared procedures reset,
rewrite, and ~.

AP P LIe AT ION S

The requirement that standard files input and
header if they are used.

HELP WANTED!

of

the

must

appear

in

the

program

Access to non-text files via the standard procedures read and write.
Output of Boolean expressions, or output of real exp~ions in the fixed-point form

If PASCAL is to make any inroads into serious scientific computing (currently the almost
exclusive preserve of FORTRAN) it must have a decent library of scientific subroutines which means, as far as the U.K. is concerned, that there must be a PASCAL version

output

(r: ex1: ex2) via the procedure write.
8.

P4 does not support formal procedure or function parameters.

9.

P4

NAG (Numerical Algorithms Group) library.
It should be possible to make
machine-dependent features being
method of production of the
ALGOl 60 versions, together with

a PASCAL NAG library largely machine-independent with all
collected into the "X"

routines.

Probably

the

library would be a straight transcription of the existing
the writing of the set of "X" routines for each different

range of machines.

does

not

allow

set

constructors

containing

the

subrange

notation

(e.g. ,

['0' •• '9']).

easiest

10. P4 does not support goto statements which jump out of the procedure or function in
which they occur. (In fact, P4 has a bug wherein it fails to diagnose such goto's, and
treats them like "local" jumps -- see the P4 Bug list, item 6.)

Please send your views on this matter, and offers of help, to:
Pascal P4 -- Bug Reports.
Professor D.W. Barron,
Computer Studies Group,
Department of Mathematics,

The Univers ity,
Southampton, Hants, S09 SNH, United Kingdom,
who is coordinating this project and negotiating with NAG.

We

have received several reports of bugs in P4, in addition to Updates 1 and 2 which were

printed in Pascal News #8. Since Zurich has not promised support on P4 we intend to

print

such reports here, including fixes when possible. Also, to make sure that they are widely
known, we are reprinting Updates 1 and 2 from Chris Jacobi. These should already be
included in the P4 distribution tapes.

~
~

00

The

list

following

Univers ity

of

O.W. van Wijk
News) •

is

based

on

bug

reports

from:

Juha

Heinanen (Computer Center;

11.

Tampere; P.O.Box 607; SF-33101 Tamp ere 10; Finland;
(931-156111»,
(TNO-IBBC; P.O. Box 49; Delft, Holland; (015-138222», and Jim Miner (Pascal

change:
tu:

P4 bugs not affecting portability.

12.

Insert after PASCP.461:
IF LGTH = 0 THEN ERROR ( 205)
ELSE

On line PASCP.1079
change:
to:

IN [IDENT,CASESY]
IN FSYS + [IDENT,CASESY]

~

C/)

n
:x>

Correct error numbers.

r:2:

rn
~

13.

Write end of line on last line of listing, and also flag errors in all cases

on

the

last line ..

Replace P.555 with:
IF LIST THEN WRITELN(OUTPUT);
IF ERRINX > 0 THEN
BEGIN LIST := FALSE; ENDOFLINE

Assure non-compatibility of different length strings.
Insert after P.145:
AND (FSPl~.SIZE = FSP2~.SIZE)
Allow ";11 between field list and "end" in record type.

-0

10 THEN
6 THEN

On PASCP.2277 and on PASCP.2285
change:
ERROR(125)
to:
ERROR(116)

Disallow zero-length string constants.

2.

Correctly diagnose "write(f)".

On P.380

14.

C/)

'I*:
I-'
I-'

END

P4 does not diagnose forward-declared procedures and functions which are not actually

defined. No fix has been submitted for this bug.
P4 portability-related bugs.

Correct comment.

On line P.307
change:
to:

5.

The items listed here involve implementation dependencies.

(*LOD*)
(*LDO*)

15.

On line PASCP.1772
change:
to:

to:

:= 0 TO 58 DO

:= SETLOW TO SETHIGH DO

16.

Insert after PASCP.2893:
WHILE DISPLAY [TTOP] .OCCUR <> BLCK DO TTOP := TTOP - 1;
TTOP1 := TTOP;
Replace PASCP.2895 and PASCP.2896 with:
LLP := DISPLAY [TTOP] .FLABEL;
Correct comment.

On line P. 500
change:
to:
8.

9.

(*lJP*)
(*UJP*)

Allow label definition inside of a with statement.
On PASCP.3153
change:
DISPLAY [TOP]
DISPLAY [LEVEL]
to:
Avoid spurious "undefined forward type" diagnosis.

Replace PASCP.1368 and PASCP.1369 with:
END
ELSE LCP2 := LCP1;
LCP1 := LCP1~.NEXT
10.

Correctly diagnose "read(f)".

On P.347
change:
to:

8 THEN
5 THEN

Implementation Notes

SET OF O•• 58
SET OF SETLOW •• SETHIGH

Diagnose set declarations exceeding implementation defined limits.

Replace PASCP.1275 to PASCP.1278 (inclusive) with:
IF LSP1 <> REALPTR THEN
IF LSP1 <> INTPTR THEN
BEGIN GETBOUNDS(LSP1,LMIN,LMAX);
IF (LMIN < SETLOW) OR (LMAX > SETHIGH) THEN
ERROR( 169) ;
NEW(LSP ,POWER) ;
WITH LSP~ DO
BEGIN FORM := POWER; SIZE := SETSIZE;
ELSET := LSP1
END
END
ELSE ERROR( 169)
ELSE ERROR(l14)

Correct failure to disallow non-local gato's.

7.

Correct declaration of set values.

On PASCP.85
change:

Correct generation of set cons tants ..

17.

On some implementations it is not safe to allow tests of (in-) equality on arrays and
records. This is because P4 does not guarantee that all storage units within an array
or record type are accessible to the programmer, due to alignment considerations. The
following changes disallow such comparisons, except for strings.

Replace PASCP.2826 and also replace PASCP.2831 with:
ERROR(l34) ;

PASCAL - P4 Installation Parameters
intsize,realsize,charsize,boolsize,setsize,ptrsize:
Number of addressable storage units to be reserved for variables of type integer,
real, character, boolean, set, pointer. As to 'setsize', remember that a set must
be able to hold at least 48 elements if you intend to use the system to bootstrap
the compil er.
intal,realal,charal,boolal,setal,ptral:
Variables of the corresponding types will be given an address which is a multiple
of these alignment constants.

I-'
lD

'-J
00

stackelsize:
Minimum size for a value on the expression stack. The expression stack is that
portion of the stack which is used for the evaluation of expressions.
'Stackelsize' has to be equal to or a multiple of 'stackal '.

Concurrent Pascal
COMPlITER SCIENCE DEPARTMENT

22 September 1977

Su.VAToaI CoMPUTEI. ScIENCE CENTU.

stackal:
Alignment constant for a value on the expression stack. 'Stackal' must be a
multiple of all other alignment constants and must be less or equal to
'stackelsize' .

UNIVERSITY OF SOUTHERN CALIFORNIA, UNIVERSITY PARK, LOS

~"IGELES,

CALIFORNIA 90007

Dear Colleague:

strglgth:
Maximum length of a string. (In fact all strings will be of length 'strglgth').
A string must be able to hold the character representation of a number (real or
integer) with its sign. The minimum length for a bootstrap is 12.

I am pleased to announce that the distribution of Concurrent Pascal tapes
has been resumed. The two tapes contain copies vf the Solo Operating
System and the Sequential and Concurrent Pascal compilers. The system
is ready to run on a PDP 11/45 system and can (with some effort) be moved
to other minicomputers.

intbits:
Number of bits used for representing an integer without the sign.
integer is:
2intbits_ 1

To obtain the system tapes, please contact

So the largest

sethigh,setlow:
Maximum and minimum ordinal values for the element of a set.
ordmaxchar,ordminchar:
Maximum and minimum ordinal values of the character set.
Depending on the alignment conditions there may be two possibilities for the assignment
of store on top of the expression stack:
_ Each stack element requires the same amount ,of store. In this case 'stackelsize'
has to be greater than or equal to the maximum of the other size constants.
(Remember: 'stackelsize' is a multiple of 'stackal').
_ No waste of store: A new element on the expression stack has to be placed at the
next position allowed by the alignment constant 'stackal '. In this case
'stackelsize' has to be less than or equal to the maximum of the other size
constants.
Thanks to George Richmond for sending us revised Pascal-P ordering information.

Mr. George H. Richmond
Computing Center
University of Color~do
3645 Marine Street
Boulder, Colorado 80309
Concurrent Pascal and three model operating systems written in the language
are described in
P. Brinch Hansen, The Architecture of Concurrent Programs.
Prentice-Hall, Englewood Cliffs, New Jersey, July 1977.
The compiler is described in

A.C. Hartmann, A Concurrent Pascal Compiler for Minicomputers.
Lecture Notes in Computer Science 50, Springer-Verlag, New York,
N.Y., 1977.
I am interested in hearing about any experience you may have had in using
Concurrent Pascal.

Pascal-P may be ordered from:
In Europe, Asia, and Africa:

In Australasia:
In North and South America:

Chris Jacobi, Institut fuer Informatik, ETH-Zentrum,
CH-8092 Zuerich, Switzerland.
(*last published cost was SFr 160 for
configured compiler - do not prepay;')
Carroll Morgan, Basser Dept. of Computer Science,
Univ. of SydDey, NSW 2006 Australia.
U'last published cost was $A30 ,,)
George Richmond, Computing Center: 3645 Marine, Boulder,
CO 80309 USA. ('·'new prices: $60 for tape,
documentation, and overhead, please prepay,
and $30 additional for configured
compiler. ;,)

PASCAL VARIANTS
Pascal-S
(* See the Checklist and letter from Rich Cichelli under CDC 6000 in the Machine Dependent

Implementations section. *)

Per Brinch Hansen
CONCURRENT PASCAL DISTRIBUTION

George H.

Richmond

Septembe" 1977

Concurrent PASCAL is a variant of
PASCAL
developed
by Per Brinch
Hansen
while
he
was
at the California Institute of Technology.
This
system is implemented for the POP 11/45.
It includes the Solo Operating
System, the Sequential
PASCAL
Campi leI",
and
the Concurrent
PASCAL
Campi leI".
The
software
suppl ied
is
ready
to
run
for
a suitably
configured
POP
11/45 system.
It
could
be
transported
to
other
minicomputers as the bulk of the code Is written in PASCAL.
The
University of
Colorado
is distributing Concurrent PASCAL In
cooperation with Per Brinch Hansen following the publication of his most
recent book liThe Architecture of Concurrent Programs"
by
Prentice-Hall
in
July 1977.
This book describes the Concurrent Pascal system.
It fs
not included in the
documentation distributed by
the
University of
Colorado.
The
materials available
include
two
magnetic
tapes containing a
complete copy of the Solo Operating System for loading onto a RK05
disk
pack
on
a PDP 11/45 computer and a source and vi rtual code copy of the
Solo programs for listing on any computer.
Documentation
includes
two
reports
not
included
in "The Architecture of Concurrent Programs" and
other items or suitable replacements as follows:

en

Li terature about the Programming Language Pascal (5 pages)
A Note on the Concurrent Pascal Tapes (2 pages)
Concurrent Pascal Implementation Notes (2B pages)
Sequential Pascal Report (46 pages)

TEXT FI LES «SCll)

A text fi Ie conSists of one or more I ines.
Each
1 ine conSists of
zero or more characters terminated by a LF character (decimal value 10).
(There are no CR characters.)
A text
fi Ie is terminated by an EM
character (decimal value 25 ).

The cost may be paid in advance by check (payable to
the University
of
Colorado)
or a more formal purchase order and invoice mechanism can
be used.
Concurrent
PASCAl. can be mai led from
the University ot
Colorado to outside ot North America for the addttional cost of air-mai 1
postage.
•

< 1 i ne > LF

The Solo system consists of a Single-user operating system written in
Concurrent
Pascal and a set ot ut1! ity programs written in a variant of
Sequential Pascal.
It includes two multi-pass campi lars for
Sequential
and Concurrent Pasca 1 (see:
P. Br inch Hansen, The Programmi ng Language
Concurrent Pascal, IEEE Transactions on Software Engineering 1, 2.
.June
1975) •
The Solo system was bui 1t only
development of Concurrent Pascal.
It
programm1 ng
(but can be made so) •
following machine configuration:

< 1 i ne > LF
EM
The text is packed into blocks of 512 characters.
So aline may
begin
in
the middle of one block and end somewhere in the next blocK.
The character's (if any) I.\;'hich follow the EM character in the last block
of the file are irrelevant.
A text file is also terminated by an end of
fi Ie mark on the tape (just as any other fi 1e).

to support
Per Br inch Hansen I s
is not convenient
for casual
The Solo system require. the

VIRTUAL CODE FILES

- POP 11/45 computer with floating-point arithmetic
- Memory management and 4BK words of core storage
- Line frequency clock KW11-L
- Disk cartridge drive RK11-D
- Teletype terminal LT33

code
fi Ie consists of
16-bit binary integers.
Each integer is
output as two 8-bi t bytes.
The 10",'('r order 8 bi ts
are output
f; rst,
foll0'... ed by the higher oreer 8 bits (this is due to the byte addressing
of the PDP 11/45 computer).

This configuration allows editing and
recol'lpilation
of
compi lers.
The system also supports the following peripherals!

both

When a tl3p~ is reproduced on another machine,
the bytes should
therefor\? be output
in exactly the same order in which they ar"e input
from the tape.

- Magnetic tape unit TM11 (9 tracks, BOO bpi)
- Punched card reader" CD1 1-A (BO co 1umns, 1000 cards/mi n)
- Line printer LP (Data Printer Corp., 132 columns, 600 lines/min)

The virtual code is packed into blocKs of 512 8-bit
bytes each.
A
code
fi Ie
is terminated by an end of fi Ie mark (just 1 iKe any other
f i 1 e) •

The Pascal campi lers generate code for" a virtual machine that can be
simulated on a variety of 1S-bit minicomputers.
(The Sequential
Pascal
campi leI" was moved to another minicomputer in one man-month.)

.."

0:1

This tape contains.2 files.
The
first
file
(of
blOCk)
is an
autoload prcgN~m that can copy the second fi Ie onto a disk pack on a PDP
11/45 cor.,puter.
The second file (Of 4800 blOCkS) is a complete copy of
the Solo disk paCk.

Distribution Tapes

;;0

=

~

;;0

-<

The SOI.O COPY tape is a magnetic tape (9 tracks. BOO bpi,
600
feet)
containing a complete copy of
the Solo system.
It also contains an
autoload pr"ogram that can copy the system onto an RK05 disk pack on a
PDP 11/45 computer".
This tape can only be used on a PDP 11/45 computer with double-length
floating-point arithmetic, memory management. 48K words of core storage,
line
frequency clo...:k KW11-L,
disk cartridge drive RK11-D 1 teletype
terminal LT33 (or an equivalent terminal), and magnetic tape unit TM11.
The SOLO FILES tape is a magnetic tape (9 tracks. BOO bpi, 600
feet)
containin;.! copies of
all
Solo programs
in alphabetiC order.
Each
pr"ogram is stored both as Pascal text (ASCII code) and virtual code (16bi t integers).
Th i s tape can be used to 1 i st the programs on any computer.
The system can be moved to another computer by rewriting an assembly
language program,
called
the system kernel, that Simulates a virtual
machine and 1ts periper"als.
The tape contains a copy of the kernel
for
the PDP 11/45 computer (4K words).

SOLO FILES TAPE
This tape contains 116 files.
The first file is a
text
f1le
that
lists all
the other files.
The other 115 files are copies of the text
and code fi les of the Solo operating system.
Cost
Concurr"ent PASCAL Order Form
1.

Oocumentat ion for Concurrent PASCAL

$10.00

2.

Distribution Tapes for Concurrent PASCAL

$50.00

3.

Over"seas Postage

4.

Tota 1 Cost of Order

8111 ing Address:
Per Br inch Hansen

CONCURRENT PASCAL TAPES

rn

SOLO COpy TAPE

To get a copy of the system, please reture the enclosed order form.
Please notice that neither Caltech, the UniversitY of Colorado,
Or
the
University of
Sourthern Cal ifornia make a warr"anty of any kind, end do
not guarantee correctness or maintenance of the Solo system.

f->

to
"-J
00

Sh i pp i no Address:

July 1977

TAPE FORMAT
Each magnetic tape (9 tracks, 800 bpi,
600
feet)
contains
several
files.
Ther"e are no labels on a tape.
I t begins with the first block
of the first file.
Each tape contains a fixed number of
files.
There
is no end of tape label.
Each
fi Ie consists of one or more blocks of 512 B-bit bytes each.
file is terminated by a single end of file mark.

[1 ... [1'

[1 ... [1 •

[1 ••• [1 •

< File 1

<

< File n

>

File 2

>

A

understand that
the distribution costs
entitle me to use the
Concurrent P~scal, system on a non-exclusive basis only,
and
that
the
se~lerS,(Callfornla Institute of Technology, University of Colorado, and
Unn/ er"slty of Southern CalifOrnia),make no warranty of any kind, and do
not guarantee correctness or malntenanCe of
the system.
I
1IIIil1
aCknowledge
the
authorship ot
the
system and retain
the names
"Concurrent Pascal" and "SalaM In all uses of It.

>

Each file contains either ASCII text or virtual code.

Signature:

Date:

-0
~

Gl

rn

TRW DSSG
One Space Park
90/2178
Redondo Beach, CA 9f)27fl
(213) 535-0312
19 October 1977

TRW
Dear Andy:

The Multi-Minicomputer Architecture IR&D Group at TRW, headed by Roger P..
Vossler, is using Per Brinch Hansen's Concurrent Pascal, to write specja:-ourpose operating systems for distributed computing research. Although Hansen's
Concurrent and Sequential Pascal compil ers generate vi rtua 1 code for an ideal
machine which is implemented by an interpreter, we find that for some applica·
tions this approach can compete successfully with real machine code running
under a general purpose operating system. One of the advantages of Concurrent
Pascal is that its compile time enforcement of access rights eliminates many
potential time-dependent run time errors.
We have developed a number of utility programs to supplement those available on the SOLO distribution tape. Other work has involved writing device
drivers for additional 10 devices, improvements to the co~pilers, and an experimental kernel with all 10 drivers removed and rewritten in Pascal. Future
plans include moving the interpreter and parts of the kernel to microcode on
machines with WCS, such as the PDP-ll/60.

(ii)

The VALUE statement for presetting global variables has
not been implemented,

(iii)

The procedures "off" and "arnongll have not been implemented.
Their effect can be obtained by other means within the
language.

The following run-time systems are available.
(i)

(ii)

A similar nucleus for the PDP-ll/OS, including the out-ofline routines for division and multiplication, requiring about

(iii)

A simple system for running "sequential" MODULA programs under
RSX-llD.

200 words,

J.B. Heidebrecht

Checklist mentioned is listed
Dependent Implementations section. *)

under

A structured test set of about 100 programs to test the
sequential parts of the language, and

(ii)

Many device driving MODULA programs (including those given
by Wirth) for testing the full language.
We have device
drivers written in MODULA for the DL-II, KW-IIL, RK-Il,
AR-ll, GT40, CA-IIF and many other DEC devices.

DEC PDP-II (Redondo Beach) in the Machine

(ii)

TELEPHONE 0904 59861

DEPARTMENT OF COMPUTER SCIENCE

Professor of Computer Science: 1. c. Pyle

1-'

(i)

(i)

HESLINGTON, YORK, YO! SDD

13 September 1977

Dear Mr Mickel,

A MODULA Compiler for the PDP-l1 computer

Providing a cross compiler for the INTEL 8080 that runs on the
PDP-llj40.
An initial version of the code generator and runtime system is now complete.
Our initial conclusion after
development of this version is that the 8080 is unsuitable for
an efficient version of MODULA,
and
Making the compiler run under UNIX.

We have just applied to the Science Research Council of Great Britain
for funds to support a programmer who would look after the MODULA
compiler maintenance and distribution.
Until we know the result of
this application we will not know what distribution scheme we will
adopt.
In the meantime", we would like to hear from any PASCAL
Newsletter reader who would be interested in receiving the compiler so
that we may gauge the interest in this work.
We would also be
interested in knowing what areas of application potential users have
in mind.

A recent copy of the Pascal Newsletter asked for details of any
compiler for the programming language MODULA.
We are writing this
letter to inform you and the readers of the Newsletter about the
existence of a compiler written at the University of York and
completed in the spring of 1977.

Our initial conclusions on MODULA, together with further details on the
compiler, are given in

The York MODULA compiler is written in BCPL and is structured in
four passes using a sequential binary stream for communication
between the passes.
The present version of the compiler runs
under RSX-l1D and requires a 16k partition for the compilation of
a program of about 1000 lines.
The compiler output is MACRO-ll.

A paper presented to the 1977 IFAC/IFIP Real Time Programming Workshop
held at Eindhoven, Netherlands, on 20-22 June 1977.
To be published
by Pergamon Press.

All of the MODULA language as defined by Wirth has been implemented
with the following exceptions.

Yours Sincerely,

(i)

All names must be declared before use, thus mutually
recursive procedures are not possible,

en

The compiler and its run-time system have been tested using:

UNIVERSITY OF YORK
Modu1a

and

So far the compiler has not been distributed to any other institution.
At the present time our efforts are directed towards providing full
external and internal documentation of the compiler (we hope to produce
a document similar in style to Hartman's description of the
Concurrent PASCAL compiler) and putting the present RSX-llD system into
a presentable package.
Our present development work is:

Sincerely,

(* The

Including a "loader II to overwrite the operating

system, the nucleus requires about 150 words of code,

Although we are unable to serve as a distribution center, we are interested
in exchanging ideas and programs with other users of Concurrent Pascal. An
Implementation Checklist for our implementation is attached.

JBH:nc

A nucleus to allow MODULA programs to be run on a base
PDP-ll/40.

J. HOLDEN & I. C. WAND:
MODULA' •

(Experience with the programming language

g'

We have a very limited number of preprints of this paper available.

() .'1,j~''P
• Holden

--

~~.
1.

C. Wand

"rn
to
;:0

=
»
;:0

-<

ponent accesses if regularity is attempted, this feature, too, is virtually un-

FEATURE IMP LEMEN TAT ION NOTES

implementable on machines which use descriptor-based memory organization, and
in particular on the Burroughs B6700.

UNIMPLEMENTABLE FEATURES - WARNING
This note addresses some features I have noted others adding to their PASCAL

Arrays and records in this machine are not stored on-stack, rut are allocated

compilers which I condemn as particularly nasty because they are not implementable

memory on demand, this memory being described by an on-stack descriptor word.

on the Burroughs B6700 system and possibly on other computers.
great potential features is that of portability.

One of PASCAL's

make a plea to everyone

In the B6700, this descriptor is memory protected by its tag-field (an extra
3-bit memory field), and the "RETURN FROM FUNCTION" instruction (RETN) does not

not to introduce features that are not implementable on all computers, and to

recognise a descriptor as a legal value to return: it expects an operand value

remove any that presently exist.

as represented by an integer, real, etc (with tag-field = 0).

Consequently

attempts to return such va 1ues wi 11 a lways crash due to the" I NVALI 0 OPERAND"
(I)

Passing pointer values as

Seen in PN #9/10, page 40.

addre~ses.

interrupt.

even in-stack.

The following program is allowed to execute, storing
The

the (stack) address of x in p:

~

way around this problem that does not totally destroy the architectural

features of the B6700 (thereby slowing it manyfold), is to:

program P;
var p

t integer;

x

integer;

begin

(a)

turn interrupts off,

(b)

shift the local PASCAL stack up

(c)

adjust the dynamic and static stack activation record pointers to

by one word,

correspond to the shift,

x:=I;

p:=tx;

(d)

{the horrod

implant the return descriptor into the caller's stack in the free
word created under the make-stack word, and

end.
Since the concept 'address' does not exist in some computers, and notably not
in the Burroughs B6700 in the sense used here, this is virtually unimplementable.

(e) turn interrupts back on.
have omitted some important features which maybe

could be resolved, like how

Stack-addresses are generally not computable segment addresses have two compon-

the returned memory get de-allocated, but this should suffice to show that this

ents; and any contortion made to try to implement this feature will cause either

is really impossible.

serious security risks, or explode all pointers into requiring two words of

48-bits for storage (with a time penalty too), or destroy the structure of B6700
programs making them CDC-like.

Pointers are not necessarily

address~s;

a point

(3)

Allowing pointers to file-types and the use of new{file)

Observed in correspondance, on Univac PASCAL.
program P;

which seems not to be widely realised.

var p
c

The restriction in the PASCAL report was there for a reason:

leave it there.

t file of char;
char;

begin

The feature should not exist, or should only be available when specifically

new{p);

enabled by a computer directive.

reset{pt);

(2)

read{pt,c)

Returning function values of all kinds except files
end.

The Report. allows one to define functions which return values which may be:

*
*

And it will execute.

scalars of all types,

The following will compile:

In the Burroughs B6700, file-descriptor-blocks (the oper-

ating system's status area for a real file) must reside in the task's st,ack.

reals, and
;, po inters.

They cannot reside in some other area such as the heap as they will not then be

It has been proposed to extend this permission to all types except file-type.

closed and de-allocated by the operating system's block-exit procedure, and the

(PN 9/10, page 48).

ensuing mess will be horrible to contemplate.

were also

omitt~d

The omission of file-types is a blessing, but the others

for a definite purpose.

Apart from the invention of array

and record temporaries on the PASCAL run-time stack (which do not otherwise
occur), and the greater difficulty of distinguishing recursive calls from com-

fi les.

Moral:

beware what you do with

rn

CONPILING BOOLEAN EXPRESSIONS -

The User t1anual, our second "standard" document is thankfully more

THE CASE FOR A "BOOLEAN OPERATOR" INTERPRETATION
In some recent correspondence, I became aware that there might be
some argument about the correct way to implement boolean expressions
in PASCAL.

This argument arises partially because the "standard"

generally preferred implementation method for evaluating boolean
expressions.

is in error!

the consensus area is perceived by some to be "restrictive".

I wish

here to argue two points:
that the consensus area outlined in the "standard" documents
should be preserved, and

*

It says:

"Boolean expressions have the property that their value may be
known before the entire expression has been evaluated. Assume
for example that x=O. Then
(x > 0) and (x < 10)
is already known to be false after computation of the first
faetor, and the second need not be evaZuated. The rules of PASCAL
neither require nor forbid the evaluation of the second part in
sueh cases. This means that the programmer must assure that the
seeond faetor is well-defined, independent of the value of the
value of the first faatoI'. Hence if one assumes that the =ray
a has an index ranging from 1 to 10, then the following program

documents of PASCAL do not say the same things, and partially since

*

explicit.

that a IIboolean operator'l interpretation be regarded as the

:x:=0;

repeat x:=+l until (x > 10) or (a[x) = 0)
(User Manvnl, pp 20-21)

The problem area
The essential problem is related to complex boolean expressions, for

/I

While this comment only covers some of the possibilities, it is quite

example:

explicit as far as it goes.

(a < 0) £!:. (b > c)

Are both relational expressions evaluated, followed by a logical or-ing
of the result (the boolean

op~o~

interpretation), or is the first

factor evaluated and only if it gives false is the second factor
evaluated (the 4equential eonjunction interpretation)?
I give, if a,b

&

op~o~

or the 4equel"..tJd c.onjunction approach. (Perhaps this freedom is
regrettable, but that is a question of language or standard criticism.)

In the example

c are all simple variables, the t\10 evaluations give

identical results.

If you accept the authority of the User

Manual, implementations are at liberty to choose the booiean

If however there could be side-effects, whether

This would seem to dispose of my first question: the consensus area
reserved for implementors in the standards.

Now, which is preferable?

intentional ones due to funcdon evaluations, or unintentional ones

This is a quite difficult question (impossible to resolve in abstract),

due to undefinition of values, then the two possible implementations

and hinges around three points:

may give different execution results.

Hhich is an implementor to

*

regularity,

* efficien~y,

choose?

1<

and

portability.

The "standard" documents of PASCAL
The Revised Report does not specify the semantics of an expression, except

Regularity

by a rather remote impl ication.

One of the guiding principles-of PASCAL is parsimony of concepts.

It simply states the syntactic rules for

expressions, prefaced by an introduction which says:

"Expressions are eonstruets denoting rules of eomputation for
obtaining values of variables and generating new values by the
applieation of operators.
Sequenees of operators of the same preeedenee are exeeuted
from left to right . ...... "
(Revised Report #8)

In

general, one expects expressions to be evaluated as they are written, and
this is the practice for all expressions in existing PASCAL compilers,
apart from the cases we are now considering.

Regularity therefore

suggests that treating boolean operators just like all other operators
(both left and right side operands are evaluated) is the more regular
approach.

Certainly a naive student learning how to program is likely

to assume this when tracking down an elusive bug, though a programmer
conditioned by exposure to other languages might not.
There is little semantic guidance here, except to imply that all operators
are intended to be applied.

Particularly

is this the case if the boolean expressions become even mre complex than
the ones I or Wirth give.

=
rn

Time-efficiency

Existing compilers

The evaluation of a complex boolean expression might be quite

I cannot speak for all compilers. because I don't have access to them

time-consuming.

all.

Obviously, minimizing the number of things to be

Of those I knO\v. we have:

evaluated \"ill alvlays payoff for sufficiently complex expressions,
more especially if function evaluations are involved.

Just where the

break-even point comes (if it exists) depends upon whether the boolean
expression is in a jwnp eontex.t as in.!.i., while or repeat, or in a

va1.ue eontex.t where it

~

deliver a boolean value.

It also depends on

on a Burroughs B6700 in toto, than by sequential conjunction.

This arises

because conditional branches flush the instruction buffers (lookahead), and
delete the top-of-stack value.

On a DEC PDP-II, this would be reversed.

On the other hand, involving a function evaluation in the second

sequential conjunction

CDC 6000 seri es

ICL 1900

PASCAl-P (all of them)
C/)

Burroughs 66700/7700

the machine architecture of the target computer.
For example the sample expression I gave first is faster to evaluate

boolean operator

Other factors
I have said before that PASCAL does not have a good standard, and this
can be illustrated here too.

Nowhere in the "standard" documents is

it required that a compiler .,hich implements sequential conjunction
eva 1uate the 1eftmost factor first.

I don' t th ink any exi st i ng compi 1er

is that clever (they are largely one-pass) but an optimizing compiler

factor as in

might quite easily decide to evaluate a simpler second (or third)

(gtyptr = realptr) and compatible(gtyptr,ltyptr)
would always be faster evaluated by the sequential conjunction method.

factor before the leftmost one. It seems reasonably certain that
some PASCAL compiler will attempt it if the language has a reasonable
future to go.

Space-efficiency
Unlike speed, which tends to be dominated by the properties of a small
proportion of a program, space occupied by code depends upon the properties
of all the code.

Since typical PASCAL programs have a fair number of

boolean

sequential

operator

conj unct i on

-

boolean expressions, compactness is also a desirable property of a compiled
boo I ean express i on eva I uat i on.

Here the dec i s ion cou I d go either \vay,

depending on the machine architecture, or could exhibit a cross-over

(as with the Burroghs B6700's time-efficiency). Again to give examples,
"a:=b and c"

better

speed

?

-

better for complex
expressions

the n6700 alViays requires less code space for the boolean operator
interpretation (the most extreme case

regularity

requires 8 bytes

or 18 bytes for the two approaches), and the reverse situation holds

space

?

?

portab iii ty

better

-

in the DEC PDP-II.

As happens so often, we end

Portab iIi ty

desirable properties.

u~

comparing incomparables: efficiency vs

Fortunately for me, the Burroughs 66700 architecture

Any implementor must be cognizant of the effects of a compiler on the

un i forml y favours the method ,.i th the bes t propart i es, and there was no

likely portability of the programs written under its umbrella.

confl ict.

a preference here?

Is there

The answer is fortunately relatively clear: a compiler

that implements boolean expressions just 1 ike all other expressions is

This \.i 11 not be so in other computers where a comparison

does not give a boolean result, but sets condition codes or some such
hardware fudge.

likely to lead to the detection of more illegal PASCAL constructs (1 ike

"[6

a eompileJt. -fA Wended

pOJr. teac.hlng

that instanced by Wirth) by run-time errors before they leave the system

Let me

supposedly debugged.'

llegu!aJU:ty -fA hnpoJt:ta.nt and e66,[ci.e.ney not). 01l,.[6 :the pllomotion

Since part of the role of a compiler is detecting

illegal constructs (as well as compiling legal ones), the
eonjun~n

6eque~~

interpretation can be seen to reduce the portability of

PASCAL programs.

My, tha;t

puJtp06 U

(60:that

06 pllogllam ,.[1'l.:teJt.eha.nge -fA llegaltded M hnpoJt:ta.nt, then the cJ1.O,.[ee 6eem6

quUe cleM :to me: boolean opeJt.a:toJrh 6hou1d be hnplemented
and eveJty 6ac.:t0Jr. eva1.ua.:ted.

M

6ueh,

Only in a compUelL wlU.c.h -i.6 ct-i.med at plwdue-i.ng op:tim-i.zed code. 06 lugh
qu.a..U;ty wou.td .u 
and 
you ha.ve. 
:;;c

-<
I--'
"-.I
00

is issued at this point.
Masquerade:
The most important case to detect: this may successfully compile on both

tel
:;;c

c.D

S ibl ing:
This is a distinct name which is so treated on the B6700, but will result

but would possibly execute with quite different effects.

-n

rn

during the subsequent entry of the name into the table.

v:=initial;
if (final - initial)

~

0 then begin

repeat beg i n

MAC HI NED EPEN DEN TIM P LEMEN TAT ION S

s'

v:=v+l
end unti 1 v > final;

Alpha Micro Systems AM-ll

end;

See DEC LSI-ll (San Diego).
The consequences are

(i) the order of execution is el, e2, assign to v.

Identical to PASCAL-6000

Andromeda Systems ll/B

ANOROMeo~

and 86700.
(ii) the exit value of v if the loop is never entered is el.

sys,eMS.

(iii) the exit value of v if the loop is entered is (e2 + 1).
Additionally, the controlled variable can be altered from within the loop, and
this alteration affects the progress of counting.
It is interesting, and sad, to note that all three compilers reported so far

have different answers to my questions (ii) and (iii).

The uniform answer to

November 21, 1977

question (i) is perhaps a sign for the future ...
Professor A.H.J. Sale,
Department of Information Science,
University of Tasmania.

Mr. Timothy 1"1. Bonham

D605/1630 S. Sixth St.
Minneapolis, MN 55454
Dear Timothy:
Thai1k you for your inquiry about our ll/B System.
standard product literature enclosed.

You will find our

In regard to your specific questions:

FOR Statement

- Robert A. Fraley
1.

IBM 370 (UBC Version)
HP 3000 (Forthcoming)

(2 31 on IBM.

We have been in communication with Ken Bowles and nis
assistant ~ark Overgaard. Based on our discussions
we have no reason to believe the UCSD Pascal won't ~ork
on the II/B.
(If we were to offer Pascal directly it
would be UCSD Pascal.)
,

3.

I'm not familiar with the systems mentioned so I can not
comment on them.

There are no limits except for word size.

Currently 215 on the HP, but double word integers

may eventually be supported.)
For the IBM version, optimizations are made in several cases:
a.

If the limit is a constant, it is not stored in temp 2.

b.

In order of decreasing efficiency, the loop forms are:

If you should have any further questions, please don't hesitate to contact
me.

down to 1
down to constant
to constant

<

to constant
vari?b 1e 1imi t

,,0

2.

The program behavior matches that of the CDC 6000 version,
as printed in PUGN #9.

We are considering offering Pascal with the II/B.
final decision has been made yet.

224 (with initial value ~ 0)
14701 ARMINTA STREET NJ PANORAMA CITY, CALIFORNIA 91402 (213) 781-6000

f-I

<.D
'-I
00

Burroughs B5700 (Edinburgh)
Burroughs B6700/7700 (Tasmania)
Department of Computer

Science

Arthur Sale sent us a very
implementation: B6700/7700

impressive (about 170 pages) manual for his B6700/7700
PASCAL Reference Manual (R77-3; July, 1977). Arthur also sent

~n. interesting report entitled "Th~ Use of Tag Six in a Pascal
37-39 Grassmarket, Edinburgh EH1 2HW

Heriot-Watt University

Tel 031-2258432 031-2265601 Ext

Compiler"

(R77-4),

the use of words w~th tags of six in the PASCAL implementation for the
Burroughs B6700 developed at the University of Tasmania. It involves questions of language
definition, undefined values of variables, and machine design. 1I (From the abstract.)

Head of Department

Mr. A. Mickel,
PASCAL Users' Group,
277 Experimental Engineering Building,
208 Southeast Union Street,
University of Minnesota,
Minneapolis,
Minnesota, 55455,
U.S.A.

Professor A Balfoul, MA, FIMA, fBCS

Both

of these reports are published by the Department of Information Science, The University of
Tasmania, G.P.O. Box 252C Hobart, Tasmania 7001. (* Thanks Arthur! *)

your ref

Burroughs B6700/7700 (San Diego).
our ref

date

ABjKM

30th November 1977.

In
PA

Dear Mr. Mickel,
I thought it was about time that I let the PASCAL Users'
Group know about the implementation of PASCAL that we are
running at Heriot-Watt University on our Burroughs B5700. We
have a PASCAL translator that produces a Burroughs XALGOL
program.
It is based on the CDC 6600 compiler written by
U. Amman & R. Schild, and conforms as closely as possible to
the definition by Jensen & Wirth.
We have been using it
for almost 2 years now very successfully.
Indeed, one
colleague has almost completed writing a MODULA compiler in
~ASCAL using it.
The only major extension to the compiler
1S a cross-referencing option.
We also have a frequency analyser that can be run in
conjunction with the compiler.
This is still being worked
on to tidy it up, but works very well.
The PASCAL compiler was produced for us by an M.Sc.
student from.Oslo, Norway called Dag Langmyhr, to whom we
are extremely grateful as he continues to maintain it for
us.
The frequency analyser was written by another M.Sc.
student Mike Staker.
Recently we obtained a PASCAL compiler for our Burroughs
B1726 from Paul Schul tess of the University of Zurich.
This
has so far proved very successful with no problems.
I have
extended it slightly to allow the slightly odd character set
from our B5700 PASCAL programs to be acceptable to it.
We
look forward to the implementation of real arithmetic by
Herr Schultess.
Anybody wishing any information about our efforts with
PASCAL can contact me at the above address.
I will be
on~y to~ ~lease~ to help if I can.
We already have several
un1vers1t1es uS1ng our compiler in the USA Japan and South
Africa.
'
Yours sincerely,

which

d~scusses

a letter dated 3 November 1977, Thomas J. Kelly, 58-B Meadowlake Drive, Downingtown,
19335, wrote:
"I've changed jobs: I now work for Burroughs Corp. I exerted some effort and we are
now using the UCSD implementation of PASCAL on our B7700. For any other B7700 users
who need a compiler t you can get one from UCSD t I suppose. It's okaYt but we have
discovered several bugs. There is also a fix that needs to be installed to allow the
generated code to run properly on a B7700 (as opposed to B6700). I will send that fix
on to UCSD. I don't know if they'll put it in. If anyone wants tat they can get one
directly from me (at the above address). tI

Also see Tom Shields in the Here and There section.
CDC Cyber 18 and 2550 (Santa Ana)
Jim Fontana reports that the Implementor/Maintainer of this implementation is Gordon Wood,
CDC t La Jolla t California, and that the Distributor is Control Data Corporation t
Professional Services Division t Sunnyvale t California.
CDC Cyber 18 (Berlin)
1. IMPLEMENTOR/DISTRIBUTOR/MAINTAINER. Implementors: Lutz Chris toph (Kernel) and Thomas
Wagner (Interpreter); Technische Universitaet Berlin; DV-Grundausbildung; Institut fuer
angewandte Informatik; VSH 5; Otto-Suhr-Allee 18/20; D-1000 Berlin - 10; Germany. Phone:
secretariate 30-314-4893 from 8 to 13 MEZ except Tuesday.
2. MACHINE. CDC Cyber 18, Models OS, 10, and 20. Model 17 is not supported due to use of
the Enhanced Instruction Set, and Model 30 because it is a dual processor machine.
Floating point firmware and software will both be supported.
3. SYSTEM CONFIGURATION. In interpretive form
compilation. Requires a disk (cartridge or SMD).
4. DISTRIBUTION.
branch. )

Not

yet.

will

need

less

than

48KW

for

self

Later will be distributed by CDC. (Agreement with the German

5.

DOCUMENTATION. A supplement to the Brinch Hansen articles is planned.

6.

MAINTENANCE POLICY. Not determined yet.

7.

STANDARD. Brinch Hansen Pascal. Some extensions are to be discussed.

8.

MEASUREHENTS. Will be provided when system is operative.

9.

RELIABILITY.

/"

v~A~

~A.

Cooper.

co
f-'

10. DEVELOPMENT METHOD. Kernel/In·terpreter
Compiler: Development not started.

rewritten

and

cross-assembled

on

CDC 6500.

11. LIBRARY SUPPORT. As with all Concurrent Pascal implementations. (poor)
CDC 3200 (Minneapolis)
Unfortunately, the rumor printed in Pascal News #9-10 regarding John Urbanski (West Bank
Computer Center, 90 Blegen Hall, University of Minnesota, 269 19th Ave.
South,
Minneapolis, MN 55455) and the CDC 3200 i~lementation is no longer viable. John's 3200 is
being replaced by a different machine.
CDC 6000, Cyber 70, Cyber 170 (Zurich)
George Richmond has announced: (1) that Release 2 of Pascal-6000 will be distributed for
$60, and (2) that buyers may no longer send their own tapes to receive Pascal. Also, John
Strait and Andy Mickel sadly announce a six month delay in the long awaited Release 3.
CDC 6000, Cyber 70, Cyber 170 (Bethlehem)

PASCAL-I

Interactive. Conversational PASCAL-S

PASCAL-I is a version of the Wirth PASCAL-S (PASCAL subset) system
designed to interact with a terminal user. The system compiles and
interactively interprets PASCAL-S programs. It automatically formats
source text on compilation and allows the user to edit his program.
Text editing functions include GET and SAVE a file. All other editing
operations follow PASCAL scope rules (i.e. the command LIST defaults
to listing only the procedure being edited). Statements can be inserted,
erased, replaced, moved, and printed. Strings can be searched for and
changed. The REPEAT command reapplies the last edit command. There are
no line numbers; the editing scope is alw~ys very local, and none seem
needed or desired. The edit pOinter can be moved from procedure to
procedure, up and down within a procedure, and to the top and bottom of
a procedure. Entire procedures can be moved or deleted. Their levels
can be easily changed. A tree structured listing of procedure
relationships is produced by the STRUCTURE command.
The HELP command gives detailed instructions and examples for each
command. The MESSAGE command gives a full descriptive statement of
the cause of a syntax error and sometimes includes recommendations for
possible fixes. "LIST,E,M" will list only the erroneous lines of a
procedure with the full descriptive messages for each error.
The compiler automatically formats the user program on input and
re-compilation. Statements are placed on single lines and properly
indented. Data structures are neatly laid out. Comments are well
handled. and inter symbol spacing is rationally done.
The internal text is efficiently stored as linked. variable length,
blank suppressed lines. After program changes. the compiler recompiles
only the minimal set of affected procedures. The internal code is a
dynamically managed, linked group of variable length code blocks. This
internal code resembles PASCAL-S code, is position independent, highly
compressed. and exceptionally efficient for interpretive execution; the
linked data structures allow the system to perform efficient automatic
dynamic garbage collection. Code and text for statements are mutually
linked so that the run time system displays user program statuses with
actual text line references.

A user may EXECUTE or CONTINUE his program. Single statement stepping
is available. Statements or procedures may be traced. Fifteen


::0

-<

SCOPE 3.4 with INTERCOM.

00
N

8.

9.
10.

We now have a fairly complete checklist for you, which I
enclose, and some details of timings, both execution and compilation,
which Bob Berry put together. I think PUG readers might find them
interesting.

MEASUREMENTS. Interpreter and overlayed. Beats CDC BASIC hands down
in cpu efficiency (size and time), features, etc. It is the fastest
compiler on campus (because of partial compilation it outperforms
PASCAL-S), and it does very well at run time. The compiler forms
the largest overlay segment and runs at 358K
The editor 3egment
runs in about 24SK. PASCAL-I will compile and interpret PA8CAL-S
programs of up to about 500 lines as the system is currently
ccmfigured.
F.ELIABILITY.

Thanks,

Runs just great.

DEVELOPMENT ~lETHOD. Started with PASCAL-S and Wirth-Jensen I/O
routines. Built suitable data structures for storage of compressed
program source and interpr'eter code. Modified PCSYSTM to fully
recover from user aborts and system timeouts. Also added file
access primitives and moved stack and heap to low core to enable
the segmented loader to vary field length. Development took place
during April, 1977 to Octobe:r, 1977 and was a very part-time effort.
The system is about 7000 lines of tightly formatted PASCAL.
Implementor responsibilities:
Curt Loughin
Editor
i"ormatter
PASCAL-S compiler rewr He
PASCAL-S interpreter rewl'ite
Immediate code routines
Jor,r, McGrath
I/O routines rewrite
HELP conuuand
PCSYSTM mods
Richard Cichelli. (project leader)
Post mortem dump
and other run-time control and status routines

Arthur Foster.
1.

segment structure. Self-compiles in less than 60000.

- First released in July 1976. Now used at four sites, running under Scope 2.1.4.

R.E.BERRY and A.FOSTER
Computer Studies Department
University of Lancaster
Bailrigg
Lancaster

Data General Nova
3.

4.

Developed with RDOS 4.02, we also use it under RDOS 5.00, and one user
tells us he uses it under RDOS 6.10 without any trouble. We assume at
least 32K words of core, disc backing store. The present system assumes
no hardware Multiply/Divide or flcating point.

-n

Distribution: from Lancaster

2.5 Mbyte cartridge disk
Data General Cassette
in U.S.A. two people who have Lancaster Pascal have offered to oct as
distributors thus increasing the range of distribution media.

Dr.H.S. Magnuski
Gamma Technology
BOO Welch Road
Palo Alto
California 94304.
(9 trac~ BOO BPI mag tape)

CDC 7600 (Hanchester)
Peter Hayes (UlIRCC; Oxford Road; Manchester M13 9PL; England; 061-2738252) reported on 22
November 1977 several corrections to the Checklist printed in Pascal News #9-1D:
---------- Price: 30 pounds sterling (instead of 50).
- Core requirements (octal): 42402 Se11, or 36045 i f segment loaded (using a simple

Distributors/Implementors

rn
t:>:J
:;;0

=

Jim Hebert,
51 Thomas Road
Swampscott
Mass. 01907.
(9 track 800 BPI mag tape)

::t:>
:;;0

-<

'J

5.

User manual provided, Pascal User Manual and Report assumed.

6.

Maintenance pol.<.cy : No formal commitment to provide support can be given,
however, bug reports welcome. To date all kno~n bugs have been fixed and
this policy will continue for as long as is practicable.

7.

Pascal P4 subset accepted.

B.

Measurements : P-code is generated, assembled and then interpreted

00

Data General Nova (Lancaster)

University of Lancaster

Compiler core requirements (n.b. compiler uses overlays)
Release 2
Release 1
Department of Computer Studies
Ballrigg, Lancaster
Telephone Lancaster 65201 (STD 0524)
Head of Department: J A. Llewellyn B.Sc.,

M.PhiL, ERGS, ELM.A.

Compiler

(decimal)

Additional fixed table space
27th October 1977.

Deer Andy.

Hp.re at Lancaster we are just about ready to distribute the
\.ye are aiming to do this
or. or about, 25th Ncvember 1977. I;Je have already sent details to
Dr.Maqr:uski end ,Jim Hebert. They should also have copies of the
ne\·' compiler shortly.

14,055

15,505

(words)

1,092

1,197

(words)

The workspace remaining depends upon size of the ROOS system usee!.
size of program which can be compiled depends upon the number of user
defined symbols (dynamic area used) and the depth of nesting of procedures/
statements. Thus it is difficult to make any general statement acout the
size of progra'll which can be compiled, however, we observe that the
assembler for the system is of some 1,100 lines of Pascal source g"ner<:ting
7,400 Pcode instructions and we can compile this on our 32K system. ~e
cannot compile the compiler but would expect to do so with more than 32K
of core.

Th~

second relefise of Nova PASCAL Comniler.

1,~1AX

More about the test programs
Timing
9.

See attached sheet.

Reliabili ty : Release 1 was made available to our own department user<:, in

January 1977 and at the time of writing has been distributed to eight knO\;n
sjtes. No significant bugs have been reported from ext€;rnal users. ReleasE?
is at present available to our own use£s and will be available to others by
the time this appears in PUG newsletter.
10.

Develol'ment : Originally cross-co'npiled from a CDC 7600.

The P-code

asser,bler was written from scratch in Pascal; the P-code interpreter was

implemented in Nova Assembly language.
11.

Libraries : no library support in Release 1. Under Release 2 user procedures
may be separately compiled enabling the user to set up his own libraries. It
is not possible to link into any other librariES.
2:iming information for Nova Pascal Release 2
We have no+: a::; yet campi] ed the compiler

cannot give figures for that.

\-,1i

th our sys tern so

Instead to provide the basis for

our statement that the performance of our Pascal 'lcompares favourably"

with DG Algol a list of times obtained by running some well known
small, and often uninteresting programs are given. The timings are
taken from a Nova 2/10 running under RLJOS 4.02 with 32K of core
and no hard~'are multiply divide and no floating point unit. They
were (rather crudely) obtained by using the GTOD command to prefix
and postfix the CLI con~and necessary to load the appropriate program.
"Compile" should be taken to mean ",he production of a save file (.SV)
from the .3ppropriate source program.

1.

A program consisting simply of BEGIN END

2.

Matrix multiply of two 50'50 matrices of integers.No I/O

3.

Matrix multiply of 50'50 matrices of reals. No I/O

4.

Sort an array of 1,000 integers into descending order of magnitude from
ascending order of masnitude. No I/O

5.

Ackomans function (3,6).

6.

Write 10,001 integers into a file.

7.

Read 10,001 integers from a file.

8.

Generate 5,000 random integers (printing only the last).

9.

Genera'e 5,000 random integers and write to a file.

No I/O

Timings 5uch as these offer much scope for debate. It is safer
to let others draw what conclusions they will from these figures (and
any other figures that may be produced). I simply wish to observe that
interpretive Pascal "comparEe; favourably" with the code produced by DG
Algol. r" the programs used above the Algol and the Pascal looks very
much the same. No attempt is made to exploit one feature of a particular
language or implementation, and no tuning has been done. If anyune has
other examples to contribute to such timing comparisons I would be
pleased to hear ?bout them.

R.E.Berry.

Algol
Program 'H'

Compile

~

Pascal

B2!

Compile

B2!

m:s

m:s

m:s

m:s

1.

0:55

0:06

1:21

0:07

2.

1:15

1:54

1:39

2:35

3.

1:16

14:32

1:40

11:59

4.

1:10

2:06

1:38

5: 56

5.

1:09

2:52

1:37

1:55

c.

1:06

3:18

1:35

1:11

7.

1:08

1:28

1:36

1:03

8.

1:36

1:56

1:57

3:13

- A.Foster l:elieves that ~ programs both compile and execute
more efficiently in PASCAL than Algol, due to the nature of the lan~age.
He has experience writing large programs in Nova PASCAL and Nova ALGOL
over the last year and believes that the real advantages of PP5CAL are
that Nova PP.SCAL programs are considerably easier to develop than Nova
Algol programs, in his view.

GAMMA TECHNOLOGY
October 6, 1977
Dear Andy:
Thanks for the pre-release of the DG notes.

9.

4:46

4:30

Here's some new information for you.

I have made an agreement with R.E. Berry of the University of Lancaster to be a
secondary distribution point for his NOVA PASCAL. We will supply the program on
9-track BOO-bpi magnetic tape in RDOS dump format, and the manuals. The distribution
charge is $70 for the binaries of Release 1. We will collect trouble reports and
ship them to England, but all corrections will have to come from U.1. Also, we
cannot supply the program on any other media, on disks, on floppies, on cassettes, in
bottles or cans. California residents must add the appropriate sales tax.

=

During September I had a chance to run a comparision of the Lancaster PASCAL against
the PASCAL written by Ted Park now with Medical Data Consultants (formerly Loma Linda
University). First, I must compliment both authors on the ease of use of both of
these compilers. For both systems I had compiled and run a program in less than an
hour after loading the tape, and there were no mysterious system crashes or wipeouts

as one would expect with the first release of a new
used (courtesy of ROLM Corp.) was a top-of-the-line
disk. The Lancaster PASCAL was also run on my 32KW
drive. Five short PASCAL programs were compiled (a
three of the programs were executed.

Compile time (seconds)
Run time (seconds)

software package. The system
ECLIPSE C330 with DG's ZEBRA
NOVA 2/10 with a Diablo 30 disk
total of 5319 characters), and

These are the results:

Lancaster

Lancaster

NOVA 2/10
515
86

C330
242
47

Loma Linda
C330
582
299

After these tests I called Ted to ask him what his program was doing with all that
CPU time, and he described to me a long list of problem areas where performance could
be improved (changes in his macro facility, use of variable size data structures,
more efficient use of the RDOS I/O structure, revision of his paging algorithm, less
runtime e.rror checking in the compiler's P-code interpreter, etc.). He has implemented
a virtual memory scheme and makes heavy use of the ECLIPSE instruction set, so with a
little tuning up of his software I predict he'll be able to run larger programs faster

You have received a letter from Hank Magnuski comparing my
system with the Lancaster system. He pointed out several
problem areas (speed-wise, we still have found no bugs!) I
mentioned to him. Since his letter to you I have cleaned up
all these problems and am putting together a 'final' version.
I am obtaining a copy of the Lancaster compiler to do my own
internal benchmarks; I want to make detailed comparisons of
the two systems. The Lancaster version will always compile
a little faster than mine and maybe run character-oriented or
integer-oriented programs faster. I feel the strong points
of my compiler are:
1.

Total integration into the RDOS environment

2.

The exclusive use of double precision (32-bit) integers

3.

The exclusive and fast use of double precision (64-bit)
reals

4.

Ease of modification and extension.

rn

will share my benchmark results with you when I complete them.

than the Lancaster group.

The Lancaster PASCAL has a few quirks of its own, primarily related to problems of
the compiler and run-time system knowing about their environment: a subdirectory is

difficult to use, long filenames cause errors, and it doesn't work at all in the
foreground partition.
Nevertheless, my conclusion is that we have two good

implementations now available

on DG equipment.
Yours sincerely,

am still happy to distribute my preliminary version free. I
am negotiating with Hank to market the nevi version for a cost.
The exact price and distribution methodology have not yet been
established.
By the way -- It is no secret that PASCAL-P4 is a subset but has
anybody compiled a complete list of its differences? I have
begun one and will enclose it for your information. I'm sure
it is not complete and would like someone to add to it and perhaps
publish it in PUGN.

H.S. Magnuski, President
Gamma Technology, Inc.

800 Welch Ro.d

•

P.lo Alto

•

California 94304.

415-326-1661

•

TWX: 910-373-1296

Ted C. Park
Director, Systems Development
TCP:map
cc: H.S. Magnuski

Data General Eclipse (San Bernardino) (previously Loma Linda)

1894 Commercenter West, Suite 302, San Bernardino, CA 92408

MD
MEDICAL DATA CONSULTANTS
October 19, 1977

•

Dear Andy,
I received your pre-release of the D.G. notes for #9 and #10 -thanks. I have some updated information for you concerning my
ECLIPSE PASCAL system:

(714J 825-2683

DEC PDP-8 (Minneapolis)

The SSRFC Pascal Group (SSRFC; 25 Blegen Hall; University of Minnesota; 269 19th Ave.
South; Minneapolis, MN 55455 (612/373-5599) announced on 31 December 1977 that: "The
project is undergoing extensive redesign and development. We apologize to all those who
have received no response to inquiries regarding distribution. He are not distributing any
version presently. A mailing list is being maintained so that interested parties can be
informed of changes in status."

"0

:I:>
Gl

rn
00

V1

DEC LSI-ll (San Diego)
Digital Equipment Corporation (DEC) PDP-ll and LSI-ll -- Introduction.
See also Ken Bowles' article "Status of UCSD Pascal Project" in this issue for information

about Z80's, 8080's, and CP/M.

Good News: DECUS Pascal SIG was resurrected by John Barr (Pascal SIG; c/o DECUS; 146 Main
Street, PK-3/E55; Maynard, MA 01754; -OR- Hughes Aircraft Co.; Box 92919; Los Angeles,
CA 90009; Attn: John R. Barr 377/C209) who edits the bimonthly DECUS Pascal SIG
Newsletter. So far (31 Dec. 1977) we have received two issues: Vol. 1, numbers 1 and ~
dated Sept. 1977 and Dec. 1977. Number 3 is on the way. To quote "From the Editor" in
issue number 1: "Welcome to the Pascal SIG. The Pascal SIG has been in existence

in

*********************************************
k

name

OF-r'ICIAL NOTICE OF RELEI1SE OF UCSD

~

*

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

only since Atlanta (Spring 1976 DECUS). It was started again in Boston (Spring 1977 DECUS)
with a commitment from DEC (Larry Portner) to aid the SIG in the development of a Pascal

January 1978

compiler for the PDP-II computers and operating systems. 1I And from the same issue:

"The main goal of the Pascal SIG is to provide DECUS members with common Pascal
compilers for all DEC equipment. One of the highest priority prerequisites of the
effort is that such compilers will be

available

to

users

for

only

the

cost

of

reproduction through the DECUS library. Support of the compilers will rest with the
Pascal Implementation Working Group who will use this newsletter to report bugs and
fixes to these bugs.
"A secondary goal of the Pascal SIG is to report the existence of commercially
available Pascal compilers and/or compilers developed outside of the SIG which may be
of interest to users. In accordance with DEGUS policies we cannot report the cost of
such compilers but can only indicate who the users can contact for information on
them. We will publish at most one announcement per year from any company which has a
Pascal compiler available for DEC computers."

John Barr reports that the following persons are Officers of DECUS Pascal SIG:
-

Program Librarian: Tom Tyson (PUG member).
PUG/SIG Liaison: John Iobst (PUG member).
Standards Committee: Ken Bowles (PUG member) and John Iobst.
DoD-l Language Committee: Fredreck Bartlett and Don Chaney.

- Concurrent Pascal Committee:

Roger Vossler.

Anyone may join DECUS by contacting one of the following offices:
AUSTRALIA and NEW ZEALAND:
DECUS
P.O. Box 491
Crows Nest, N.S.W. 2065
Australia

EUROPE and MIDDLE EAST:
DECUS
Case Postale 340
CH-12ll Geneva 26
Switzerland

CANADA:
DECUS
P.O. Box 11500
Ottawa, Ontario K2H 8K8
Canada

ALL OTHERS:
DECUS
146 Main Street
Maynard, Massachusetts 01754
U.S.A.

This PASCAL system is our first system intended for general purpose
use awau from UCSD.
We are still making maJor modifications to the software.
and expect that you will find errOrS.
If you do find an error in our system.
please contact us before attempting to fix the problem yourself.
We may have
already found the error. and solved it.
There are many expansions yet to be
made to our PASCAL system. and hope that you will let us know what is needed.
Recompilation of object code files will be necessary on" maJor updates of
the system
Please remember that our proJect is mainly staffed by students.
We iniend to support USBrs who have paid the distribution fee within our
resources. but may not respond as quickly as a commercial vendor might. due to
conflicting university schedules.

We are offerin9 two kinds of subscriptions:
Complete subscription:
Floppy disks with all sources and code.
Compiled listings
all SDurces.
User and system maintenance documentation as complete as it
exists
Updates at least three times during the next 12 months.
$200. (paid in advance)

0'

Code subscription: Floppy disk with system code.
Users manual but no detailed
system documentation.
No continued support for later subscriptions.
Only
minimal assistance in response to telephone inquiries.
$50
(paid in advance)
The complete subscription is a years bond with our proJect.
We will
do our best to answer your questions. and keep you up to date on new subscriptions.
The code subscription is for the user who is not concerned with
our development. and Just wants a running PASCAL system.
A user of the code
subscription may upgrade to the complete subscription upon payment of $175.
Please make your check payable to:

Regents.

Please return the completed order form.

DEC PDP-ll (Stockholm)
Seved Torstendahl's implementation has become quite widespread -- it was reported (in PUGN
Checklist form!!) in the first issue of DECUS Pascal SIG Newsletter, and we have heard
from several PUG members who have used it: Jo;--Gross (Minneapolis), Steve Schwarm
(Wilmington), and Rich Cichelli (Bethlehem).

University of California

and your check to:

PASCAL GT'OUp
Institute for Information Systems
UC SD Ma i 1 c: 0 d e C-021
92093
La Jolla. CA

In a conversation with Andy Mickel on 17 December 1977, Ken Bowles mentioned that DEC is
coming out with Writable Control Store (WCS) for the LSI-ll. Ken expects that use of this
feature will speed up the UCSD system by a factor of five -- allowing it to compile 3000
lines per minute!

00

en

DEC PDP-II (Amsterdam)

*" li-.*********************************
REGUEST FOR COPY OF UCSD PASCAL *
***~******:;.;;*:;;;;*;;*;;**.*;;:;;;;**

1.DISTRIBUTOR/IMPLEMENTOR/MAINTAINER.
DISTRIBUTOR: Sources, binaries and documentation are part of
the third UNIX software distribution.
IMPLEMENTOR: Johan Stevenson, Vrije Universiteit.
MAINTAINER: Andrew S.Tanenbaum, Wiskundig Seminarium, Vrije
Universiteit, De Boelelaan 1081, Amsterdam, The Netherlands, tel: 020-5482410.

LSI-tt
PDP-tt model
] TERAK 8510
] TERAK 8510A
:I other (please specify)
]

----.---

)

2.MACHINE.
DEC PDP 11, all models on which the·UNIX operating
system version 6 will run.

The above mentioned processor has PDPtl/40 type (e. g.
'loating point hardware
Memory space available gn

~

LSI-1t EIS/FIS chip)

RKII (DEC floppy dlLk drives)
(or hardware equivalent / software transparent)
TERAK

Other (please speci.y,

l

~tlA!1!.

to I I

we may not support it,

l
l

J The above system has a

line

L

[

printe~

UD..a.tl~

with an LPII (or equivalent) interface.

devi~

to aboy£' system:

Decscope series (please specify model)
._ _ _ _ _ _ _ _ _ _ ._ _ _ _ _ .__
:1 Uatamedia product (please specify)
._______.__________________.______
Other (please specify)

.L.ljP~

[

someone else might)

~ted_:

Termlnal(s) to be attached I I
l

Q.£ r.el.!ll!. !!!!3.Il.ted:

Complete release ($200 paid in advance)
Cude release ($50 paid in advance)
No release. but keep us up to date on new developments.

Please complete this form.

and return with your check to:

PASCAL Group
Institute for Information Systems
UCSD Mailcode C-021
La doll",. CA
92093
SHIP TO:

5. DOCUMENTATION. Short manuals for the compiler and interpreter
in UNIX MAN format. A 12 page description giving details
about the implementation.

3100

RK05 (we may not be able to support all 'ormats)

Qj;Jlll

see 2.

4.DISTRIBUTION. The UNIX software distribution center takes care
of distribution.

W01"'d~;.

AED

3.SYSTEM CONFIGURATION.

process.2.!:.:

{i. e.

-n

6.MAINTAINANCE POLICY.
Bug reports are welcome. There will be
no improved release of the current system.
However, we
are working on a totally new one. Main differences with
the old one are:
a new hypothetical stack computer named EM1 (see
Tanenbaum, A.S. "Implications of structured programming for machine architecture" CACM Dec. '11). This
intermediate machine allows very compact code (only
15000 8-bit bytes for the compiler itself) and fast
interpretation. Emulating EM1 on a microprogrammable
computer must be easy. Moreover, this EM1 machine
allows compilation of other high-level languages as
well.
a new interpreter with all kinds of runtime checks
and debugging aids .
- expansion of EM1 code into PDP-11 instructions.
- less restrictions on the language Pascal.

rn
tx:I
:;:c

=
::J>
:;:c

-<

1.STANDARD. Main differences with full Pascal are:
- no goto's out of procedures and functions.
- procedures and functions can not be passed as parameters.
- extern procedures and functions not implemented.
- mark and release instead of dispose.
- only non-local textfiles (up to 15).
an explicit get (or readln) is needed to initialize
the file window even for input.

where do you want your PASCAL sent}

---.-.-----------------------------------------

-----------------------------------------

8.MEASUREMENTS.
Compilation speed: 40000 chars per minute on a PDP-11/45 with
cache.
Compilation space: 48k bytes to compile the compiler.
Very
big programs can be compiled.

00

"

execution speed: You lose a factor 8 by interpretation. However 1/0 is relatively fast.
Compared to not interpreted
Pascal on a big machine (Cyber 73)
it
is ten times
slower.
execution space: The size of the complete interpreter is 5300
bytes. The binary code for the compiler is 23000 bytes.
9.RELIABILITY. The compiler and interpreter are good.
the runtime checking of the interpreter is poor.

5.

There is lots of good comments in 'the source compiler
and supplementary information on the internals of the
compiler system have also been written. There isn't much
good information on the usage or details on the extensions
however. We used the first edition of JENSEN and WIRTH
user manual.

However

rn
::e::
6.

10.DEVELOPMENT METHOD.
The compiler is based on the
PASCAL-P2
compiler.
A Cyber-73 was used for bootstrapping. The
time needed by an unexperienced implementor was about 6
months.
11.LIBRARY SUPPORT.

DOCUMENTATION:

No library support at all.

MAINTENANCE:

en

The compiler probably will be maintained for several
years, to support the application.
It is not expected to
change much over the years -- it is quite satisfactory as
it stands. Any problems which may turn up will probablY
be worked around rather than fixed.
For instance, LABEL
doesn't appear to work altogether correctly, but we don't
use it anyhow.

DEC PDP-ll (GTE SYLVANIA)

7&B IMPLEMENTATION:

1.

IMPLEMENTORS:
Larry Drews
(Address Unknown)

Sharlene Wong (almost PUG member)
GTE SYLVANIA
P.O. Box 205
Mountain View, California 94042
(415) 966-3373

2.

David Miller (PUG member)
GTE SYLVANIA
l1203A Avalanche Way
Columbia, Maryland 21044
(301) 992-5665
David Shaw (PUG member)
STRUCTURED SYSTEMS CORP.
427 Embarcadero Road
Palo Alto, California 94301
(415) 32l-Blll

MACHINE:

As described in our paper, we probably have the most
non-standard PASCAL in the world. We are therefore its
most fearsome friend.
(PNB - p33).
The following shopping
list is a concatention of the University of Illinois
PASCAL (PN5 - p53, PNB - pSI-52), and of our own modifications.
EXTENSIONS:
- Overlay: the compiler is itself an overlay with nine
segments. The application doesn't use this feature.
- Identifiers may contain an underscore as a break
character.
- It recognizes octal constants.

Digital Equipment Corporation
PDP 11/45 and up I suppose

- Multiple assignments and imbedded statements are
supported.
McCarthy boolean expression evaluation has been
implemented.

3.

SYSTEM:
- WRITE formats may specify; octal, hexidecimal, binary,
unsigned decimal; field width; with or without
leading zeros.

DOS/BATCH-II V9.20C

4.

- Pretty print/line editor pass may be included in the
compilation. The editor line numbers are carried
through the compiler.

DISTRIBUTION:
Corporate policy has not been decided at this time.
there is enough community pressure it could be arranged.
must be emphasized that this compiler was developed to
support a single application.

If
It

A cross reference pass may be included in the
compilation.
- Compiler directives include:
list suppression
page eject
statement number code suppression (used for post
mortum trace)

00
00

CHANGES:

subscript and pointer check (execution time) code
suppression
stack size specification
comment blocks
lexical inclusion of other source files (we included
TYPE and VAR files)
conditional compilations
fast code linkage for procedures at the expense of
tracing

- Abbreviations:

BOOL, INT, PROC, FUNC

- Lexical changes:
for
\ for
"for
& for
for
#

- Post mortum trace and stack unwind.

c>
NOT
{and} limited to one line
AND
OR

- DIV (and I ) implemented as floor function to be
consistant with MOD.

- Real time procedure trace.
- CLOSE, EXTEND for files.

- WRITE f (list)

- DISPOSE and NEW with one argument.

- READ f (list)

- POINTER treats an integer as a universal pointer
variable.

- PROGRAJl parameter redefined to be consistant with the
application.

ADDR creates a pointer.

Usage of tag field in the variant record.

- NIL as zero.
- EOL.

9.

- MODULE, ENTRY to link PASCAL and/or MACRO object.

RELIABILITY:
In our controlled environment, pretty print and the
compiler have excellent reliability. However, at this
writing, there are only four users.

- EXTERNAL, ENDEXTERNAL to support data linkage.
- MACRO to imbed machine code in the PASCAL code.
- TRAP to communicate within the application executive.

10.

FIRST and LAST to get the limits of a scalar.

The compiler is written in PASCAL (about 10,000 lines)
and its father is from the University of Illinois. The
run time support package is written in MACRO (machine
language). I have no estimates on the man-hours expended
to build our PASCAL.

- EXIT from a procedure instead of GOTO.
- The compiler generates either load and go ~no linking
required) or linkable object code. The obJect
.
generated has separate instruction and data space flIes
to allow the application the greatest use of the
11/45 architecture. Because PASCAL modules can be
linked, dynamic array can be explicit~ly used. However, the compiler doesn't support thlS feature.

ANCESTRY:

DEC PDP-II (Redondo Beach)

{* Please see the letter from J.B. Heidebrecht which accompanied this
in the PASCAL VARIANTS (Concurrent Pascal) section. *)

checklist,

printed

Concurrent Pascal Implementation Checklist
DELETIONS:
WITH
SET and its support operations
REAL and its support operations
PACKED ARRAY

- lV'lAXINT

1.

J.B. Heidebrecht, R.A. Vossler, F. Stepczyk
O. Heimbigner. M. Feraud, and S. Danforth

PAGE
PUT, GET

TRW DSSG
One Space Pa rk
Bldg. 90/2178
Redondo Beach, CA
(213) 535-0312

- READLN, WRITELN

- PACK, UNPACK
- EOLN
-

(* and *)

Imp1ementors!

90278

(Original implementation by Per Brinch Hansen and Alfred C. Hartmann.)
2.

Machines:

PDP-11/40, PDP-l1/45, PDP-11/60

co
<.D

3.

Operating systems: SOLO, Experimental Development System, and user written
systems.
48 KW
Minimal hardware configuration:
memory, 1 - RK05 disk drive,
1 - 9-track
tape drive, FPll floating pOint option.
Future versions will run on smaller PDP-ll machines without floating point.

4. Method of distribution: no established policy.
5. Documentation available: (a) machine retrievable user manuals are
available for all utility programs; (b) several books and papers have
been published by Per Brinch Hansen and Al Hartmann on the operating
systems and compilers.
6. Maintenance:

DEC PDP-II (Vienna)

Distributor and Maintainer:
osterreichische Studiengesellschaft fur Atomenergie Ges.m.b.H., Lenaugasse 10, 1082 Wien, Physikinstitut
Implementor:
A portable Sequential and Concurrent Pascal compiler has been designed
and implemented by Prof. P.B. Hansen and A.C. Hartmann, California
Institute of Technology. The Compilers have been modified and a new
runtime system has been implemented by D.I. Konrad Mayer, osterreichische
Studiengesellschaft·fur Atomenergie.

no established policy.
Machine:

7. Two compilers are available: CPASCAL (Concurrent) and SPASCAL (Sequential).
SPASCAL implements most of standard Pascal. The main exceptions are that
procedures may not be nested, and only a few of the standard predefined
Pascal functions are available. CPASCAL has further restrictions on scope
rules and does not implement the pointer type. Extensions to CPASCAL
include processes, classes, and monitors, and compile time checking of
access rights.
8. Both compilers generate virtual code I"lhich is interpreted. The· interpreter
and operating system kernel are written in MACRO-ll, the PDP-ll assembly
language. Together they comprise less than 7000 statenents, and are the
only assembly language components of the operating system. Work is currently
being done to reduce the size of the kernel. The SOLO operating system is
written in Concurrent Pascal, consisting of about 1200 statements. All other
utilities, including compilers and the file system, are written in Sequential
Pascal. The compilers consist of seven passes each, totaling about 9200
statements per compiler. Compilation speed is about 240 char/sec on a
PDP-ll/45.

Digital Equipment's PDPll, all types
System Configuration:
Operating System
a) Rsxll-M (version 2 or later)
or compatible systems (RSXI1-D, lAS)
b) RT11 (version 2C or later)
Minimum memory requirements for self-compilation of the compiler.
a) RSX11M: 23 k words-part.ition
This amount can be reduced by using overlays.
b) RT11: 24 k words (including the operating system).
Distribution:
Distribution medium:

9. Reliability of compilers: very good; only one bug has been found in
nearly a year of heavy use.
Reliability of interpreter:
10. Method of development:

excellent; no bugs have been found to date.

developed by A1 Hartmann and Per Brinch Hansen.

11. Libraries of subprograms are not available. Procedures and functions to be
referenced by a program must either be included in the source file or
accessed through a procedure entry in the operating system. Facilities for
using procedures written in other languages are not currently available.
Separate compilation is available in a limited sense in two ways: (a)
commonly used procedures may be compiled and included in the operating system;
(b) a sequential program can call another sequential program.
DEC PDP-ll (PAR)
The implementation started by Michael N. Condict (PAR Corporation; On the Mall; Rome,
NY 13440; 315/336-8400) and reported in Pascal News #9-10 has been discontinued.

......
DEC-tape or floppy disk or
magnetic tape (9 track, 800 bpi).

<.0

'oJ
00

E'ormat
Files 11 or RT11 or DOS for DEC-tape and floppy disk
A "PRESERVE"-copy of a RK05 disk for magnetic tape
The package contains
- All sources and codes of the Sequential and Concurrent Pascal compiler.
- All sources and object code of the runtime system and the I/O routines.
- All indirect command files (RSXll only) for assembling and building the
runtime system.
The runtime system can execute only Sequential Pascal Programs! A system
for Concurrent Pascal programs will be available later.
- A disassembler for analyzing the generated code of Sequential and
Concurrent Pascal programs.
- Documentation
Distribution costs:
5.000,-- Austrian Schilling
including distribution media.

<.0

o

Documentation:
The compiler and the language is described in
Hartmann, A.C., A Concurrent Pascal Compiler for Minicomputers.
LGctur€f Notes in Computer Science 50, Springer Verlag, New York, NY, 1977
and in the Concurrent and Sequential Pascal Reports of California Institute
of Technology.
The distribution package includes a supplement to the reports and a description
of the runtime system.

Maintenance and Warranty:
Although every attempt has becn made to achieve accuracy and freedom from
errors, Osterrcichische Studiengesellschaft fur At.omenergie, makes no warranty
of any kind and does not guarantee correctness or maintcna_nce of the system.
But reported ~rrors will be corrected, if possible. Please report errors to
D.l. Konrad Mayer (address see above).

La~'Llage

Sta.nda,.E.d!

Note, that Sequential Pascal is different to standard Pascal. The Sequential
and Concurrent Pascal comp.ilers have been extend8d slightly (a different lexical
analyzer) to meet RSXll and RTII standards. I/O routines for handling sequential
and random access files are provided.

Measurements:

3.

SYSTEM CONFIGURATION. RSX-llD, lAS, RSTS, and RSX-llM.

4.

DISTRIBUTlpN. Send 600' mag tape. No cost.

5.

DOCUMENTATION. (* no information given *)

6. MAINTENANCE POLICY. Bug reports accepted with corrections
Newsletter.

the

DECUS

Pascal

SIG

7. STANDARD. Implements most of Standard Pascal. Exceptions are no for loops, real
arithmetic, or set operators "<=" or ">="; set operators are represented by"!" (union)
and u&u (intersection); logical operators are II-II (negation), "!" (disjunction), and u&"
(conjunction); functions and procedures not supported are: abs, arctan, ~, eoln, ~,
In, round, sin, ~, sgrt, trunc, pack, ~, readln, unpack, and writeln; predefined
terminal input and output files are INP and OUT; reset and rewrite require a second
parameter of type array [O •• N] of char representing a file specifier terminated by a
blank. Extensions are structured constants and the ability to mix the order of ~,
~, and var declarations.

.."

Heli5'bi li_t.z'_

11. LIBRARY SUPPORT. Several Pascal programs which aided in the development effort are
available. At present there is no facility for separately compiling procedures or for
linking to non-Pascal subroutines other than the run-time library.

Development method:
started with the distribution kit of the Solo system. Then we wrote
a kernel-interpreter, which can execute Sequential Pascal programs without
needing the Solo operating system. The interface to DEC's operating system
RSXll (RTll) is the virtual machine instruction CALLSY.
External assembler routines can be called via the "program prefix". Every
external routine must be defined in the program prefix and can be linked
using the standard Fortran call conventions.
DEC PDP-ll (Los Angeles)

(* The following was obtained from the DECUS Pascal SIG Newsletter vol. 1, number 1. *)
1. IMPLEMENTOR/DISTRIBUTOR/MAINTAINER. John R. Barr; 377 /C209 - Hughes Aircraft Company Box 92919 - Los Angeles, CA 90009 (213/648-8295).
MACHINE. PDP-ll/35 and higher. Requires EIS.

rn
to
;;;0

=

::t>
:::c

-<

DEC-l0 (Hamburg-DECUS)

UNIVERSITAT HAMBURG

INSTITUT FeR
INFORMATIK

~Ie

External routines:

c,,?

9. RELIABILITY. At present the BSM compiler will loop and possibly abort under several
conditions. Syntax errors are reported using references to the error table in Jensen and
Wirth. The Pascal versions are expected to be much better.
10. DEVELOPMENT METHOD. The major portion of the compiler was taken from Brian Lucas' DOS
version of the compiler. The PASS2 Pascal code has been extensively debuged in about three
months of part time effort.

The portable compilers of P.B. IIansen/A.C. Hartmann are in use on some
sites on different machines. 'The first release was January 1975.
(See Pascal News, Vol. 6-10)

rn

8. MEASUREMENTS. The compiler is currently written in Block Structured Macros, and is in
the process of being converted to Pascal. It is a two pass compiler with each pass
requiring approximately 20K words of task space. Compile speed is approximately 450
characters per second. PASS2 of the compiler written in Pascal is approximately 2200 lines
which compiles in less than four minutes on a PDP-ll/45.

Compilation speed: 150 - 200 characters per second (PDPI1/45)
Execution time: 1 to 3 times of equivalent Fortran programs

The reliability of telle system is really excellent. ~le have the system in
use since one year. Up to now we have had only one minor problem with the
system.

2.

in

Prof. Dr. H.-H. Nagel
r

Inftitlrt fer laformatllt
1 Hamba... n, SdalltenmBe 66-7l

Dear Mr. Mickel,
in February 1977 I made our PASCAL compiler for the DECSystem-10
available to Digital Equipment Corp. to whom I had ceded the distribution rights. Since the envisioned distribution through DECUS
took some time I received numerous enquiries concerning our comiler system. I refered people interested in using PASCAL on the
DECSystem-10 to DECUS. I would be interested in learning whether
the distribution of our compiler version through DECUS is now
running to the satisfaction of interested users. Experiences with
the distribution of our current compiler version might influence the
way that a further improved version might eventually be distributed.

";;J

)::>

=
rn

Since I no longer know who intends to use our latest compiler version
and who is actually using it I would appreciate if you could include this letter in the next PASCAL Newsletter.
With many thanks in advance I remain
yours sincerely,

Hewlett Packard HP-21MX (Dallas)
David Mcqueen from Analyst International, Dallas, Texas, reports that he has a Pascal
system for the HP-21MX implemented in Fortran which provides direct access files.

Honeywell 6000

(* Please also see the article in this issue by James Q. Arnold entitled "A Novel Approach
to Compiler Design". *)

THE UNIVERSITY OF KANSAS/LAWRENCE, KANSAS 66045
Department of Computer Science

Dear Andy,

18 Strong Hall

29 October 1977

913 864-4482

Thanks for entering my membership in PUG.
I have read
my backissues of the PUG newsletter and find only passin;J
reference to the implementation of Pascal on the
Honeywell
66/60 under GCOS.
Pascal is a "software pr oduct" 0 ffer red
by Honeywell to installations with Series 6000 and Series 60
Level
66 computers.
The compiler originated at the University of waterloo,
waterloo,
Canada,
and
is distributed
through Honeywell (shades of WATFIV).
There are two aspects
of the implementation which will be of interest to
PUG
members:
what the
implementation should do, and what it
does do.
The Honeywell v ers ion of Pascal is an
independen t
implementation
(unrelated to CDC-Pascal or Pascal-P) and is
written in "B," an implementation language and successor of
BCPL.
It
is ccmpletely time sharing based
(compiled
programs can be run in either batch or TSS).
The compiler
has
one
restriction on Standard Pascal and several extensions.
The
restriction
is that the program statement
is
replaced by ·.Erocedu~ main;" and the dot terminator at the
end of the program is eliminated.
This has a curious sideeffect.
Constants, types, variables, and procedures (functions) may be defined Q.Y£!.il!!l. of "main" and thus allows
the
definition of a global environment which may be replicated
for externally (separately) compiled procedures,
thus allowing the global variables
to be accessed both from the
program ("main") and from the externally defined procedures.
Other
than that the compiler accepts
Standard Pascal
programs.
Of the implementation dependent features,
several
are
worth mentionin;J
here.
Ide,ntifiers need to be distinct in
the first 80 characters.
The base type of a set is
limited
to
at most" 9,437,184 elements (36 bits x 262,144 words).

The compiler distinguishes between lower and upper cases and
will recognize keywords in both case~ or in lower case only.
This is based on terminal command and means that you can use
the upper case version of a reserved word as an identifier
-- not suggested, but it can be useful.
Our typical use
is
uppercase
CONST
and
TYPE
identifiers and lowercase
variables.
The standard character set is Ascii.
There are several extensions in the Honeywell implementation.
An
alternate I/O package is provided (in addition
to the standard get, put, read, write,
etc.)
to make
interactive use easier (it is based on the RATFOR input/output
package described
in §.oftwi!.~ !.Qols,
by Kernighan
and
Plauger).
External procedures are allowed and calls may be
made to Pas ca 1 pr ocedur es or to pr ocedur es wr it ten in ot her
languages.
The declaration of external procedures is implemented as i t is in CDC Pascal with the exception that
"extern "
can be
used to declare an external
procedure in another language Currently, < language> may only
be
FORTRAN.
Extensions are planned to allow GMAP, COBOL,
Algol, PLll, B, C, etc.
An ~ls!l. clause is added to the case
statement
(and
in the record variant section) to allow
default selection.
Files may be of any type, except ~ of
file.
Files
may be
accessed and associated with a file
;;r1able at run time via a
procedure
call.
The standard
files "input" and "output" are normally directed to the terminal, but can be redirected to files by
terminal command
when
invoking a Pascal program.
Subscript checking is implemented by bounds checking on all variables of subrange
type.
Now that I have decribed the way the compiler is supposed to work, allow me to describe some of our experiences
using it.
We at KU have had access to the compiler for
approximately
10 months
(s ince January 1977).
We are currently using version 5 of the compiler and
expect
a
sixth
version by late December.
As stated earlier in this letter,
our Pascal is distributed through Honeywell.
The actual implementor
is the University of Waterloo.
This leads to
several problems; most of them havin;J to do with the
communication of bugs, suggestions, questions, etc.
The lack
of fast and accurate communications would not be quite so
important,
however,
if the
compiler worked and
if the
documentation were complete.
Unfortunately,
the
compiler
has been plagued with several very serious bugs.
When usin;J
compound structures, the compiler sometimes computes
incorrect addresses
thus resulting in memory address faults or
operation faults (where the data is unintentionally stored
over the program code and subsequently "executed").
The
compiler aborts when it encounters sane simple syntax errors
(such as using a reserved word as an identifier).
Resettin;J
an output file garbages the file.
Most of the serious bugs,
and
hence most of our complaints, center on the compiler
either aborting with no indication of what
is
wrong,
or
procucing
object code which behaves similarly.
At present,
we have found more than 30 serious bugs in the compiler; the
current version retains 11 of them (the others being fixed).
Fortunately, we now have direct contact with Waterloo and
are getting much better response to our complaints.
We hope
that by next January, most of the serious bugs will be
fixed.
As it is, a couple of people working on large Pascal
programs have almost (?) given up USing the compiler
(one
has writt-en a letter to PUG to vent his frustrations).
It
is, unfortunate that more extensive testing was not done
before releasin;J the compiler for distribution.

We are curren tly using the compil er in three
classes:
Data Structures.
Compiler Construction.
and Programming
Structures.
This totals more than 150 students each using
the
compiler several times a week. Two graduate students
are Writing an assembler and a simulator (emulator?) for the
Interdata 85 minicompute r
to a id in teaching an undergraduate course.
We are also trying to implement the BOBS
System Parser Generator
(our copy from the University of
Aarhus. Denmark).
Unfortunately. these projects are at a
standstill because the compiler either won't compile them
(the compiler aborts) or cc::rnpiles them into incorrect object
code.
But. we're all hoping for the best. so until January
and a new version ....•

I u. Ole VELUPMENT 'lET:10D. Thfl H310 k"rnfl1 i mitat"s the pnp 11 1 rflv"rs"dbyte addres5inq which makps it comoatih1fl with the distrihl)tion t"ln o
tout slow in exp.clltion. The deVfdoi'ment was don" IlndP.r W1S ;>10.
ThR kernel is wri tten in nAP700.
II. LIBHMIY SUPPORT. Those Drovided b;' th" SflLfl s'fstel'l.

=
IBM 360, 370 (Australia)

I am enclosing documentation which defines
the differences between Standard Pascal and Honeywell Pascal -this is in the form of an appendix to the User Manual and
Report.
You mayor may not want to include it in the newsletter.
It's up to you.
I am sorry not to have written
this
in the form of the implementation checklist. but I am
not the implementor -- I have talked with the folks
fran
Waterloo and
they assure me they will send you a letter.
Thanks for spreading the word.

AUSTRALIAN ATOMIC ENERGY COMMISSION
Sincerely.

NUCLEAR SCIENCE AND TECHNOLOGY BRANCH
RESEARCH ESTABLISHMENT. NEW ILLAWARRA ROAD. LUCAS HEIGHTS

Greg Wetzel
Research Assistant

TELEGRAMS:
TELEX:

ATOMRE. SYDNEY
24562

TELEPHONE:

531-0111

IN REPLY PLEASE QUOTE:

ADDRESS ALL MAIL TO;
AAEC RESEARCH ESTABLISHMENT
PRIVATE MAIL BAG, SUTHERLAND 2232
N.S.W. AUSTRALIA

GWC .mwb

4 January, 1978.

-n
rr1

to
:;;0

c:::

:t>
:;;0

Dear Andy,
Honeywell H316

I.
I MPLC:iAENTLJR/DISTfl I BUTOfliMAPHAI NEil. Roh",t A.. strv lc • i'r)""'lwcd 1
Corpor atR Computer Sci ence Cent"r. 10701 Lyndelle AVA. .Sr) ••
Bloomington, MN 55424; 612/887-4356.
2.

,'.,\j\CHIiIE. Honeywf> 11 11311\.

3.
SfST;:::,! CDNFIGUFlATI();I.
7 track magnetic tape.

32K, dual cartridae disks.

linA orint8r.

4.

DISTFlIBUTION. 1 track tape with proqrams to hnotstrA() from BflS ?IO.

5.

D[)CUMf:~ITATlU:l.

6.

MfdrHAINANCE. No known errors, no work p1Flnn8d.

1.
Two versions are now supplied - the original compile-and-go
version, with provision for saving compiled code, as well as a version
which produces IBM-standard object modules and can link to externally
compiled procedures written in Pascal or Fortran or Assembler language.
2.
The price is now $A100 for both versions of the system in source
and object form, plus machine-readable documentation, all supplied on a
600 ft. magnetic tape. There is now no agreement to be signed.
Yours sincerely,

Informal comments on 31 r, kArn81 impl8rnentFltinn.

7.
STANiJARD. P. B. l1ans8n's SDUJ system with modifi8d sti'ndard
and Concurrent Pascal.
MEASJflE!-:ENTS. SDLCl systp.m neRds minimum of 40K to execilt"
compilers.

8.

9.

-<

Enclosed is up-to-date information on our implementation of
Pascal 8000 for IBM 360/370 computers. Variations from previous
information are:

FlELIABILITY. No known P.rrors.

Jeffrey M. Tobias
Gordon W. Cox
Applied Mathematics

&COmputing

Division

6.

PASCAL SOOO FOR IBM 360/370
1.

Implementors:
T. Hikita and K, Ishihata,
Dept. of Information Science,
University of Tokyo,
2-11-16 Yayoi
Btmkyo-ku TOKYO,
113 JAPAN

Maintenance Policy.

No guarantee on maintenance is given; however we are anxious to receive
bug reports and suggestions, and will do our best to fix any problems which may
occur.
7.
Standard.
The full standard is supported with finiteness in a few areas:
- maximum static procedure nesting depth is 6.

(HITAC - SOOO Version)

- maximum set size is 64.

(this precludes set of char.)

It is hoped to

increase this soon.

G.W. Cox and J.M. Tobias,
Systems Design Section,
AAEC Research Establishment,
Private Mail Bag,
SUTHERLAND, 2232,
N.S.W. AUSTRALIA

maximum number of procedures in a program is 256
(IBM 360/370 Version)

Distributors/Maintainers:
G.W. Cox and J.M.Tobias
address as above
2.

Machines:
IBM360 and IBM370 - compatible machines

3.

System Configuration:

The compiler rtms tmder any of the OS family of operating systems - i.e.
MVT,MFT, VS1, VS2, SVS and MVS. A minimal program can be compiled in 12SK;
the compiler requires about 220K to compile itself.
Distribution:
Write to G.W. Cox and J.M. Tobias at AAEC to receive an order form. The
cost is $A100; there is no agreement to be signed. Two systems are supplied:
4.

a "compile-and-go" system which has its own compiled-code format, and a
"liI)kage-editor" system which produces IBM-standard object modules. Both source
and load modules for these systems are supplied - the compilers are written in
Pascal and the rtmtime support in 360 Assembler.
An implementation guide, plus machine-readable implementation JCL, and
machine-readable documentation are also supplied.
The system is distributed on a new 600 ft. magnetic tape at a density of
SOO or 1600 bpi; the tape is supplied by the distributor.
5.

Documentation
Machine-readable documentation is in the form of a report comprising a

summary of extensions to Standard Pascal plus a complete specification of the
language as implemented.

- maximum size of compiled code in anyone procedure depends on its static level:
the main program may be up to 24K, and this is reduced by 4K for each
increment of static nesting level.
Significant extensions to the standard are in the following areas:
- Constant definitions for structured types.
arrays, records and sets as constants.

It is therefore possible to have

- A '~' statement for variable initialisation
- A 'forall' statement of the form:
forall  in  do 
where  is of type set.
- A 'loop' statement, specifying that a group of statements should be
repeatedly executed tmtil an 'event' is encotmtered. Control may then
be transferred to a statement labelled by that event.
- The types of parameters of procedures or ftmctions passed as parameters
must be specified explicitly, and this enables the compiler to guarantee
integrity.
The 'type identifier', restriction in a procedure skeleton has been
relaxed to allow 'type'.
- Ftmctions 'pack' and 'tmpack' are supported, as are packed structures
in general.
Exponentiation is fully supported, and is used via the double character
symbol '**'.
- A 'type-change' ftmction has been introduced that extends the role of
'chr' and lord'.

- Case-tag lists may now range over a number of constants, without
explicitly having to list each constant.
The range is denoted by
 .. 
Thus,

4,6 •• 10,15,30 •• 45
is now a

v~lid

case tag list

A default exit is also supplied via

'"Tl
I'T'1
I:>"
:::0

c:
;x:.
:::0

-<

else: 
i.e. else:

10.

is a valid case tag in every case statement.

This path

will be used if none of the other tags match.

Pascal-P by Hikita and Ishihata, who got it running on a HITAC-SOOO computer

Other interesting features of the system are:

(similar instruction set to IBM360).

Procedure 'new' is fully supported, obtaining the minimum heap requirements
as specified by variant tags.

Procedures 'mark' and 'release' are

also supported.
- Files may be external or local.

Thus, structures such as 'array of files'

External files are named in the program statement, local

files are not.

Both external and local files may be declared in a

procedure at any level.

= FIB].

All real arithmetic is in double precision (64 bit floating-point format).
- Control of input and output formatting is as described in the Jensen and

[:n1

The form is

11.

Library Support.
The linkage-edit version has the ability to perform separate compilation of

editor as necessary.

These can be stored in a library and selected by the linkage

It can also link to routines written in FORTRAN or other

languages which use a FORTRAN calling sequence.

To use an externally compiled

routine, one must include a declaration for it.

Such declarations consist of the

proce'dure or function skeleton followed by the word 'pascal' or 'fortran I .

The

linkage-editor then automatically searches for that routine when it is linking the

[:m], where nand m are integer expressions.

Further, elements of type packed array

Cox and Tobias spent about 10 person-months on the system.

was already a very workable system.

procedures or functions.

- Text-files with RECFM of F[B] [S] [A], V[S] [S] [A] and UrAl are supported.

X

The compiler is written in Pascal SOOO (6000 lines) and runtime support is in 360

Most of this time was spent improving the OS support and adding enhancements to what

are available.

Non-text files must have RECFM

This version was further developed by Tobias

and Cox for use under the OS family of operating systems on IBM360/370 computers.

Assembler (3500 lines).

Procedure 'dispose' is not supported.

Wirth report.

Development Method
The compiler was developed from Nageli's trunk compiler and bootstrapped using

.2i

program~

char may be read on input.

Global variables are accessible to externally compiled Pascal routines.

Pascal procedures cannot be overlayed.

- Execution errors terminate in a post-mortem dump, providing a complete
execution history that includes procedure invocations, variable values,

A symbolic dump of local variables and traceback of procedures called is provided
on detection of execution errors.

type of error, etc.
- the use of separately-compiled procedures in Pascal, FORTRAN or other
i--'

languages is supported by the linkage-edit version.

Thus one can build

up a library of Pascal procedures or use a pre-existing library of

LO

IBM 360, 370 (Williamsburg)

'.J
00

FORTRAN routines.
8.

Measurements.

- compilation speed about 2,500 chars/sec on an IBM 360/65
- compilation space

l28K for small programs
l60K for medium programs
220K for the compiler

- execution speed
- execution space

1.

Michael K. Donegan
Dept. of Mathematics & Computer Science
College of William and Mary
Williamsburg, Virginia 23185
(804) 253-4481

2.

IBM 360/370

3.

OS/VS
Requires 192-256K to compile the
"normal" programs.

comparable with Fortran G.

about 30K plus the size of the compiled code, stack and
heap
Compiled code is fairly compact - the compiler itself
occupies 8SK.

9.

Reliabili ty.
The system was first distributed in its current form late in 1977.

currently used at about 30 sites.
excellent.

It is

Reliability reports have been generally good to

A few minor problems which have been reported are currently being fixed.

4.

compile~

l50K is sufficient to compile

Distribution is in the form of object, source, and documentation on 9-track
tape and is currently free if you supply a tape (we can't). This is subject to change.

LO

Vi

5.

Documentation is distributed on the tape.
implementor's guide.

6.

Maintenance is currently in the form of a new distribution and reported
bugs will be fixed on a time-available basis. We are continually working
on the limitations of the system and have plans for:

7.

We are currently writing an

1)

Additional debugging facilities, cross-reference, post-mortem dump
callable as a built in procedure, frequency profile.

2)

Better interactive capability for TSO users.

3)

Double-precision arithmetic.

4)

Dynamic arrays--as soon as some one can come up with a decent syntax
for them.

5)

A bottom-up version of the compiler.

Differences in the handling of EOLN.

2)

Sets are limited to 64 elements (no SET OF CHAR).

3)

No subranges in sets, e.g. [1. .4J.

4)

Subscripts are enclosed in parentheses.
(~

5)

Set brackets are

6)

PACK and UNPACK not supported.

7)

Dynamic values cannot be freed.
All files must be declared globally.

9)

Single precision REAL amithmetic.

Additions
1)

TECHNISCHE

UNIVERSITjXT BERLIN

BERLIN

Fachbereich Informotik (20)

DVG

Technische UniversitiH Berlin (Fa 20)
LEHREINHEIT DV·GRuNDAliSBILDUIljG
1
10, Otto-Suhr-AUee 181'20

aerlin

. Otto-Suhr-Allee 18120, 0·1000 Berlin 10

PASCAL News - Editor

Tel., (030) 314-

University Computer Center
227 Experimental Engineering
208 Southeast Union Street

Telex: 1 84262 tubln -d.

University of Minnesota
Minneapolis, MN

and ,).

8)

(* The editors wish to thank the persons in Berlin and London for taking the time to fill
us in so well on their activities. We never expected such an outpouring of information
when we wrote #9-10! Once again, thanks! -Andy, Jim, and Tim *)

'llJ Berlin· FB 20 . VSH ___ 5

The major discrepancies are:
1)

IBM 370 (London)

55 455

4893

November 30, 1977
USA

Dear Andy:
A necessary correction of if 8 and 9/10 : At the Technical

include~

University of Berlin, we never embarked on an implementation

Additional formatting capability.

based on P4 , but we do not intend to drop our efforts at a

2)

I/O for arrays, records, and all scalar types.

3)

Modified handling of labels and gotos.

4)

Direct Access Files.

of Concurrent PASCAL for the CYBER 18. We have added check

5)

Formatting for READ and WRITE is different.

lists for both projects, reporting the current status.

8.

Compiler written in PASCAL (5500 lines). Compiler size is 108K + 8K
runtime support. Compiles itself in -78 seconds on IBM 370/158.

9.

Runtime support for files has essentially no diagnostics. Real number
formatting is less than ideal. Post-mortem of variables is not available
on all errors. The compiler has been used for three semesters here with
little difficulty.

new implementation of PASCAL for IBM /370 under CMS (Thomas
Habernoll). In addition, we are starting an implementation

We are using the P4-based implementation of Imperial College
London for purposes of teaching and bootstrapping. As these
people seem to be very modest (humble programmers 7), a word
of praise for their work seems appropriate:
1. Greg

10.

11.

Pug h

implemented a VM /370 CMS PASCAL-

The compiler was written in PL/l using the unrevised compiler for the
CDC6600 as a model. This was done by two undergraduates, Doug Dunlop and
Mark Gillette, and required an academic year. The bootstrap took another
year of less-than-intensive effort. Improvements have been added as more
users have dictated. A major rewrite of the runtime system is in progress.

compiler in September 76 based on P4. Its P-code

No, but should be available this year.
this time.

rating system is very convenient to use.

No separate compilation planned at

is converted to standard OS object modules in a
separate pass. A number of extensions are helpful
for systems programmers; the interface to the ope-

2. At Technical University of Berlin, the London compiler was ready to use within a few hours; we found
some minor bugs within six months of heavy usage,
and these

have been corrected in the latest release

from London.

l.O

en

IMPERIAL COLLEGE OF SCIENCE AND TECHNOLOGY
3. Full Standard PASCAL is supported with several
notable additions,
- full file support, including in-store files,
random-access files, explicit opening of files,

DEPARTMENT OF COMPUTING AND CONTROL
180 Queen's Gate
London SW7 2BZ Telephone: 01-589 5111
Telegrams: IMPCOL London SW7 Telex: 261503
Head of Department Professor J.H. Westcott, D se, FBCS.

FlEE

non-standard opening of files for interactive
use;
- external procedures and functions;
alfa variables and returncode in program heading;
- symbolic post mortem dump;
- cross reference option.
The compiler is not very fast (about 65 lines per

Andy Mickel
Pascal Users Group
University Computer Center:227EX
208 S.E. Union Street,
University of Minnesota
Minneapolis.
MN55455
USA

CPU-second), but we consider it now very reliable.

4. Along with the compiler comes a special batch system
running in CMS environment. It has been adapted and
extended for our purposes by Thomas Habernoll. It has
drastically reduced time-consuming system overhead
(re-initialization of the CMS batch machine) •
By fall, we have switched - at last - our introductory course
from ALGOL to PASCAL, with excellent 'results so-far.

T HAN K S

T 0

LON DON

Dear Andy,
We are using Pascal on our tiny 3'70/135 under CMS,to
support our undergraduate course,for systems programming
and in a number of research projects.
Greg Pugh,one of our research students implemented
our compiler from the P4 compiler(* described in the
attached letter and report *)

Our undergraduate teaching began using Algol on the
7094,and moved to Delft Alpp,",\~en the 370/135 appeared.
Because we wanted to use a ~ set of data structures and
types than those available in Algol 60 we changed our initial
teaching language to Algol\; .After two years with Algol" we
have again changed our initial teaching language - this
time to Pascal. There were a number of reasons for this change:
1) Some of us had regarded the choice of Algol" as
a stop-gap until a reliable Pascal compiler was
available under eMS.This we now beleive has
happened with the pif implementation at IC.

/IZ_~
(A.

~:dl)

£ /-,:.-LZ
~
c::!!? ---(L. Christoph)

7:i~ A d ji,JeI-'/(
(T. Habernoll)

(* The Berlin implementation mentioned is listed separately, below. *)

2) \-Ie use a number of different computers during
the undergraduate course,and we found that
, standard' Pascal ,oms the only programming language
that we felt able to use on a Computer Science
Course,which had similar implementation across
these machines (IBH370/135,CDC Cyber 1'73,ICL 1900
if CDC 7600)
3) It was clear that 'standard' Pascal included a
number of features which ,lOuld'''extend the life"
of our initial programming language,putting
off the time when any additional language need
be taught to provide a practical tool for
course support.
4) 1-/e had a number of bad experiences with the

AlgolW Compiler.For example some ::'arge valid
programs,would fail to execute,however
seemingly arbitary changes to them, got over
the problem.

-n
rrl

b:1
;;0

=

:l>
;;0

-<

We attempted to look at the compiler to fix the problems
but found it an almost impossible task to understand the
commentless PL360.TheP4 Compiler C* the first pass anyway *J
being written in Pascal C* although with few comments *J is
generally understandable and therefore possible to correct.
Greg tells me the main areas where he met problems was in
the reliance of CDC character set ordering.
Its too early to say whether the change over has made
any great impact on the course or on the students' programming
ability - it can be said with some certainty that they are no
worse than other years 1 We beleive that by starting off their
programming in a well disciplined enviroment,that students
make better and perhaps a more cautious use of other programming
enviroments they meet later on.
Our final year students carry out group projects. Some of
them are using Pascal to implement the nucleus of a multiprogramming
operating system and others are implementing an algebraic
manipulation package in Pascal.(* Attempts to persuade the Data
Processing project groups to use Pascal Failed: *)
In the area of systems programming we have made a great deal
of use of Pascal. The P4 implementation is well integrated into the
C~lli system and behaves exactly. like any of the other compilers.
By accepting the basic architecture imposed by CI1S, the P4 cO'lJpiler
has avoided any problems about "being special" or "being an
exception".This has aided in user acceptability and made it much
easier to use for systems programming. Work is now in progress on
implementing out batch subsystem schedular in Pascal. Various system
utilities,and our central file manager which supports multi-user
access to the file base,have been written in Pascal.
.The research use,of Pascal is quite diverseC* program
development systems,m.cro~assemblers,multi-user editors *J and our
research students have produced a number of useful tools to aid nice
program production (* POLISH - a very powerful reformatting program,
SPUP - a Pascal system similar to CDC Update *l.A research group in
the department piloted the ICL 2900 implementation of Pascal to
u'se Pascal in research irtto operating system architectures.
Pascal,then is in wide use within the Deptment of Computing
and Control here at Imperial College :
Please keep up the good work of PUG :

4. DISTRIBUTION. The current version is available for distribution now. Distribution is
by 9-track magnetic tape in standard CMS tape dump format. Cost is just postage plus cost
of tape (or provide your own tape).
5. DOCUMENTATION. A user's manual is available replacing chapters 13 and 14 of the Jensen
and Wirth User Manual and Report. This includes details of all departures from standard
and additional features plus descriptions of error messages, invoking commands, etc.

6.

MAINTENANCE. Currently we cannot offer any guaranteed support, since we are very short

of

manpower,

however we are using it for teaching ourselves so problems will probably be

fixed i f you tell us about them.
7. STANDARD. The compiler provides a number of additional standard procedures and a
couple of small extensions to the language syntax. The compiler gives warnings when
non-standard features are used. There are a few minor restrictions. The following
summarises the differences:
Extensions
Hex and Octal numbers are supported.
Expressions can be used to define the value of constants.
External procedures can be declared.

Some

20

additional

standard

procedures

are available, including DATE, TIME, DAY,

MONTH, CPU time, routines to do direct access I/O

on

files,

and

several

routines

allowing VM/370 commands to be issued from the program.
ALFA variables can be specified on t~e PROGRAM statement as well as files.
Restrictions

Sets are o•• 255
Files of files

are not allowed, but files can appear within other structures (i.e.

arrays and records of files are o.k.).

."
rrt

to
:;;0

Dispose doesn't work (the dread Mark and Release can be used).
Packed is accepted but ignored (character strings are always packed anyway).

=

::r=:;;0

Features

-<

We accept upper and lower case identifiers with 30 characters significant.

Integers are 32 bits and reals 64 bits.
The compiler produces listings with bold printed
etc.

keywords,

titles,

nesting

level,

I--'
LD

'l
00

Best wishes to you all,

lain Stinson

8. MEASUREMENTS. The compiler is a much developed version of the P4 compiler. An
assembler for the P-code runs as a second pass producing standard object code. The P4
compiler is now about 7000 lines of Pascal, the assembler is 5000 lines of .PL370. The
run-time system consists of about 90 small modules (in Assembler F) which are included by
the loader on a by-need basis (a small program may only use about a dozen of these
routines). I'm not sure about exact compilation speed, but it is faster than

and

slower

IBM

Fortran

than AlgolW. The compiler generates re-entrant code and is shared between all

users (which saves a lot of store since the compiler code is quite large).

(* Greg Pugh wrote the following checklist. *)
1. IMPLEMENTOR/DISTRIBUTOR/MAINTAINER. lain Stinson
(distributor)
and
Greg
Pugh
(implementor); Department of Computing and Control; Imperial College; London SW7; England;
Phone: 01-589-5111, extensions 2700 and 2758.
2. MACHINE. IBM 370 (~ 360s). Our machine is a 135 with 384k. It operates a student
service within the department with some terminal work (up to 8 terminals) and a batch
stream, Pascal is the main teaching language.
3. SYSTEM CONFIGURATION. Operates under the VM/370 system using the CMS subsystem. It
would take quite a bit of work to convert the system to run under any of the other IBM
systems. The compiler should run on any machine that runs VM/370 (i.e. model 135 and
upwards, >= 256k).

9. RELIABILITY. Reliability seems pretty good. Currently the compiler is being used
mainly for fairly large programs (4000 lines). A student version is now available and
shuld put the system to a severe test.
10. DEVELOPMENT METHOD. The compiler was developed from the Zurich P4 compiler by writing
an assembler for the P-code in PL370 in 1976. The run-time library was written at about
the same time. A symbolic dump package dumping all variables (including records, arrays
etc.) is available. A batching version is available for student use.
11. LIBRARY SUPPORT. Procedures can be declared to be external and compiled programs can
be placed into object code libraries. Assembler and Fortran procedures can be accessed.
LD

00

IBM 360, 370 (Berlin)

r------------------

----,

I'Modular PASCALI1370 Compiler
12/01/11 I
LI _____________________________________________________
Page
- - -1- JI

1~~_~g!g12Rmgni-mgthQ~

The compiler is written in PASCAL. The syntax analysis is
based on the PASCAL 6000 compiler. which influenced the
method of code generation too.

1,,-_I!!!l!!g!!g!!t2~

Thomas Habernoll
Technische Universitaet Berlin
{Fachbereich Informatik}
[Institut fuer angewandte Informatikl
OV-Grundausbildung
iSH 5
Otto-Suhr-Allee 18/20
0-1000 Berlin 10

IBII /360, /370
(Implementation is done on a 370/158)

VII 370 (CP+CIIS)
OS (with some modifications of the rUIl time system)

Not yet. probably starting fall 1918.

A detailed reference manual will
retrievable form.

HOpefully good.

be available in machine

Not yet determinated.

Full standard PASCAL. The compilec is the first step to a
'compiler family'. Later members of this family will
include extensions
(especially for system pcogramming).
But they will ~Qt be uamed 'PASCAL compiler'! (becanse
PASCAL is the
language defined in the
report of
Jensen/Wirth: User Kanual and Report. At this level,
enough difficulties arise for portability of programs.)

Presently. no precise information can be given.

The rnn time system is written in PASCAL and Assembler. I
hope that the Assembler part can be reduced to a minimum.
As I started working we didn't have a PASCAL compiler
useful for bootstrapping on
the /370 at Technical
University. The Stony Brook and lIanitoba compilers were
not sufficient.
Therefore I wrote a PASCAL->Simula
compiler {in SIIIULAI. It is slow {compilation speed 10
lines per CPU secondl. I have learned something due to
this project: don't think that it is a simple and
straightforward task to translate a high level language
into another (relatively similar) high level language.
Just as I finished the PASCAL->SIMULA compiler, we got
the PASCAL P4 compiler from Imperial College London. This
facilitated my work.
I am trying now to write a 'modular compiler': that
means, the compiler architecture allows changing of the
accepted language and/or of
the generated code by
exchanging only few modules. Therefore we will have not
one compiler for Standard PASCAL and another one fora
subset (e.g. for educational purposes)
but a set of
modules. Depending on the command, the modules necessary
for a specific purpose will be loaded.
Writing modules
{in the sense of IIOOULAI in a block structured language
makes fun - if one has grim humour.
Presently the compiler is a one pass compiler.. But its
structure allows splitting it into a mUltipass compiler.
The first version to be released will accept Standard
and
produce
{for
several
reasons)
PASCAL
IBlI/310-Assembler code. Later
versions viII prodnce
relocatable macnine code (in standard OS loader format).
As a vision the following versions exist:
- PASCAL subset for

educationa~

purposes;

- PASCAL supersets.
First level: machine independent extensions like else
or Q.t!Ht£!!i§.g in £!!§.~ statements: a simple module
concept.
Second level: extensions for systems programming.
- Generation of interpretative code. This is normally the
first step to implement PASCAL, but I
think that
interpreters are a good tool to check out programseven for large ones (one of these reasons is the fact,
that additional check out code and test aids need
additional space resulting in frustrated programer of
large progcams, who fights against storage constraints.

--n
fTl

t:>:l
;;0

=

:J>
::0

-<
f-'

to

.......
00

Another reason is a possible step-by-step execntion of
interpretative code, that is more nsefnl than execnting
step-by-step on machine instrnction level.)

ICL 1900 (Belfast)
(* Thanks to Judy Mullins and to David Joslin who wrote on 4 Nov.
1977 and on 13 Oct.
1977, respectively, to correct the information which we printed in issue #9-10. David
provided the following revised checklist. *)

- Optimizing compiler.
processing of pre-scanned
source programs (assume
programs to be edited and analysed on a mini compnter,
the processed sonrce being sent to the /370 for
compilation and executing.

1.

Implementor & Distributor:

Dr. J.Welsh,
Dept. of Computer Science,

Someone somewhere interested
should please contact me. To
provide a better support than
more software aids besides the
(for example the embedding of
system is a useful task).

Queen's University,

in )o1.ning this project
have a chance, PASCAL must
other langnages. Therefore
compiler must be provided
the compiler in an editor

BELFAST,
2.

~:

3.

Operating System:

N.lreland,

BT7 INN.

ICL 1900 series.
Any (although the Source Library facility is
only possible, and the Diagnostics package only

practicable, under GEORGE 3 or 4).
Ninimum Configuration: The compiler needs at least 36K of core,

Linkage to FORTRAN subrontines is withont any problem.
Separate compilation is available. The first release
provides no symbolic dump. In the event of a run time
error the following informations will be given: error
message, corresponding source line number and a back
trace of procedure calls (with source line numbers of
calls).

and uses CR, LP, DA files.

4.

Distribution:

Free.

Send a mag. tape (either 9-track PE 1600 bpi

or 7-track NRZI

5.

Documentation:

556 bpi) to Belfast.

Belfast's Users' Guide (supplement to Revised

"

Report) and implementation documentation is
distributed with the compiler.

:;:c

Glasgow's supplement to the Revised Report is available from
Bill Findley or David Watt,
ICL -- Clearing House
(*

University of Glasgow,
GLASGOW, Scotland, Gl2 8QQ

-<
c.o
'J

(\;ho produced the Diagnostics package).
6.

Maintenance Policy:

- Exchange of library routines;

CO

No formal commitment to maintenance.
No plans for development in near future.

Avoidance of duplication of effort in provision of new facilities;
- Circulation of user and other documentation;

Send bug evidence to Belfast, and also a note of the bug to PCHICL

- Circulation of bug reports and fixes;

(see separate notice) who circulate bug reports & fixes to their
merJbers.

- Organisation of meetings of Pascal users and implementors;

- Acting as a "User Group" to negotiate with Pascal 1900 and 2900 suppliers.
There are currently about 40 people on PCHICL's mailing list, mainly in Computer Science
departments and Computing Centres of U.K. Universities and Polytechnics. Any User of
Pascal on ICL machines whose institution is not already a member of PCHICL should contact

7.

Implementation Level:
Exceptions:

The language of the Revised Report, with:

There are no anonymous tag fields;
FILEs cannot be assigned, passed as value

David Joslin,

o~

University of Sussex Computing Centre,

Falmer, Brighton, Sussex, BNl 9QH, United Kingdom.
All ICL Pascal users are urged to notify
make,

:;:c

1-'

PCHICL - the Pascal Clearing House for ICL machines - has been set up for the purposes of:

they

=

::t>

Dept. of Computer Science,

David Joslin sent us the following announcement on 13 October 1977 *)

modifications

f"T'1

Cd

any

useful

David
programs

of

any
or

bugs

they

find,

any

compiler

routines or documentation they have

written, anything they have that may be of use or interest to other users.

para~eters,

oocur as components of any structured type;

Predefined procedures & functions cannot be passed as
actual parameters;
The correct execution of programs which include
functions with side-effects is not guaranteed.

ICL 2900 (Southampton)

""1:J

J>

Thanks again to David Joslin and Judy
information. *)

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

(*

Only the first 8 characters of identifiers are significant.
SETs are limited to x •• y where 0 ~ ¢RD(x) ~ ¢RD(y) ~ 47
The ICL 64-charaoter graphio set is used for type CHAR.
PACKED is implemented, and TEXT = PACKED FILE ¢F CHAR.

Mullins

(see

ICL, ADDRESS¢F, allow use of inline machine code.
8.

Compiler Characteristics:

Compiler, producing absolute binary
machine code.

9.
10.

11.

Reliability:

sending

revised

en
n
J>

r

=
rn
:::e::
en
"It::

......

......

PASCAL
1(a). Implementation
ICL are providing support for
University of Southampton.
Project Supervisor:

The compiler is written as c. 14000 lines of PASCAL & c, 3500 lines
of Asser.1bler Lan[;Uage (Issue 3). Performance is better than !.lost
other rCL 1900 language processors (exceptions are incore compileand-eo batch systems of the the HATF¢R type).
The postmortem analysis program is written as c, 2500 lines of
PASCAL.

for

1900)

~~
-J~@

r

ALFA = PACKED ARRAY 1 •• 8J ¢F CHAR.
Extensions: VALUE and DISP¢SE are implemented.
Integers may be written in octal.
Additional predefined procedures & funotions DATE,
TIME, I1ILL, HALT, CARD are provided, and procedures

ICL

an

implementation group

based on

the

Dr.M.J.Rees,
Computer Studies Group
Faculty of Mathematioal Studies,
The University,
Southampton, S09 5NH,
England.

-n
rn

Telephone: 0703 559122 x2270
Implementors:

Very good.

Hethod of development: Complete rewrite of original PASCAL 1900
compiler, which was bootstrapped from the original ZUrich CDC
compilers by Welsh & Quinn.

J.J.M.Reynolds,
Computer Centre,
Queen Mary College,
University of London,
Mile End Road,
London, E1 4NS,
England.
Telephone: 01 980 4811 x778

tx:l

H.J.Zell,
New Huxley Building,
Imperial College,
University of London,
London SW7 2AZ,
England.
Telephone: 01 589 5111

Libraries: Source Library facility available under GEORGE 3 & 4.
Efforts are to be made to develop a PASCAL version of the NAG

1(b). Distribution

library (which would be applicable to ~ machine, not just rCL).
No facilities for separate compilation or for inclusion of semicompiled routines "ri tten in any other lan[;Uage.

The Pascal compiler will be distributed as a standard ICL
product.
Contact should be made to the nearest ICL sales
Failing that, contact the project supervisor shown above.

:::c
c::
::t>
:::c

-<

......
1.0

.......
CO

program
offioe.

2. Machine
The ICL 2900 series machines 2960, 2970 and 2980.
D.A.Joslin
October lOth 1977

3. Operating System
VME/B and VME/K
4. Method of Distribution
As per ICL standard, see 1(b) above.

......
C>

......

5. Documentation

Intel 8080 (Oslo)

Standard ICL manuals will be available:
(a) Pascal Language Manual: operating
Pascal Lan~uage.
(b)

system independent aspects of the

Runnin.~ Pascal
Programs on VME/B and VME/K: information on
run Pascal programs under the operating systems.

David Barron sent us a short piece that appeared in the 17 November 1977 issue of
Computing describing an 8080 implementation distributed by the Norwegian company, Mycron,
of Oslo. The compiler is said to run in 29K bytes. (* We would appreciate receiving any
more information about this implementation that a PUG member could provide. *)

how to

rn
::E:

MITS Altair 8800

en

6. Maintenance Policy
See DEC LSI-ll (San Diego).
Full maintenance will be provided by the implementation group and/or ICL
while the compiler is offered as a standard ICL program product. The
usual ICL procedures for bug reports will be adopted.

Motorola 6800 (St. Paul)

7. Language Standard

Mark Rustad asked (30 October 1977) that we make the following updates to his checklist
printed in Pascal News 119-10.

The compiler implements all features of the language as described in the
User Manual and Report (Jensen and Wirth, 1974).

1. Work phone: 612/376-1143.

8. Translation/Execution Mechanism

2. Developed using a Motorola 6800 Exercizor (48K, dual floppies) and MITS Altair 680b and
SWTP 6800. Should be extremely easy to adapt to any system using the M6800 chip.

The compiler is written in Pascal and produces Object Module Format
(OMF) compatible with all standard ICL compilers. The OMF module may be
directly loaded or linked with other OMF modules.
The source listing is approximately 10000 lines of Pascal and produces
80K bytes of code. Approximately 160K bytes of store are required to
compile the compiler.

3. Requires 32K bytes and an ASCII terminal. Also, a high speed I/O device (floppy disk,
cassette, or data cartridge) is highly recommended to reduce loading time to a reasonable

"rn

amount.

4. The system is being distributed by Computer Depot (3515 West 70th Street; Minneapolis,
MN 55435; (612/927-5601)) for less than $100 for documentation, binary, and interpreter
source.

machine

mapping of reserved words to single case, and separate compilation of procedures.
10. Method of Development
The compiler was bootstrapped usino; the 1900 compiler from the Queen's
University of Belfast, Northern Ireland as e base. , Nothern Ireland as
1 baRf'.

Twenty four

person-months of

effort from experienced

programmers were

requirf"d.

7. The following are not supported: with and goto statements; real arithmetic and the
transcendental functions; pack and unpack. The compiler handles real arithmetic but the
present interpreter does not. The system is designed to make it easy to interface the
interpreter to a floating point package or a hardware floating point chip. The following
extensions have been made: predefined procedure exit and halt. As of 77/10/23, only lower

the
the

9. As of 77/10 the compiler had successfully compiled itself in the 6800. Was released to
two external sites for testing.
lines.

see Ken Bowles' article "Status of the UCSD Pascal Project", and for an

order form see the DEC LSI-II (San Diego) implementation note.

address

-0

:t:>
G')

11. The compiler and interpreter are completely relocatable, may be
information,

<.0
"-..J
00

case is recognized.

10. As of 77/11 about 3 person-months had been invested. The compiler source is about 2400
Intel 8080 (San Diego)
For

......

8. Interpreter requires 4K (with floating point package). No compilation speed was
provided. The interpreter is unbuffered and can keep up with typing speeds of 10cps.
Approximately 2-5K M-code instructions are executed per second. This is at least 5-10
times faster than SWTP BASIC.

11. Libraries
As the compiler produces OMF modules, separate compilation and
inclusion of external procedures
will be possible providing
necessary operating system facilities are present.

:::0

-<

6. Mark guarantees maintenance only to the distributors. They are expected to pass bug
reports, etc., to him. Future plans include full acceptance of upper/lower case with

Current reliability is moderate to good.

=

:t:>

5. Documentation is the responsibility of the distributors. Mark is providing a
retrievable supplement to the Pascal User Manual and Report to the distributors.

9. Reliability

t:>:I
:::0

space

where

located

anywhere

in

sufficient memory exists. Presently this memory must be contiguous,

but it is planned to change this in the future. A crude but usable method for calling
external (assembly code) procedures exists. No direct parameter passing is available this must be done via the stack.

rn

......
o
N

THE UNIVERSITY OF HULL'S PASCAL COMPILER
Prime P-300
FOR PRIME 300 COMPUTER

THE UNIVERSITY OF HULL
1.
IMPLEMENTOR/DISTRIBUTOR/MAINTAINER: Barry Cornelius, Ian Thomas or Dave
Robson; Department of Computer Studies, University of Hull, Hull, HU6 7RX,
England; Hull (0482) 497951.

HULL Hue 7RX. ENGLAND

Telephone: Hull 46311

z
rn

Department of Computer Studies

2.

MACHINE: PRIME 300.

3.
SYSTEM CONFIGURATION: Our own system is currently 48K words running under
PRIMOS-3 Revision 10 (but Revision 14 sometime in 1978).

15th December, 1977

4.
DISTRIBUTION: We hope to have a first release of the compiler completed
by April 1978. No details about distribution have been arranged yet.

Mr. Andy Mickel,
Editor, "Pascal News",
University Computer Centre,
227 Experimental Engineering Building,
University of Minnesota,
MINNEAPOLIS. MN 55455
U.S.A.

5.

DOCUMENTATION: None - see details of PASCAL-P elsewhere in "Pascal News".

6.
MAINTENANCE POLICY: 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 receive the compiler.

Dear Andy,
The main purpose of this letter is to let you have a copy of the enclosed
implementation notes. As we're only about half way through building our PASCAL
compiler for the PRIME 300, we've left some of the details vague. We'll send
you a fuller set of implementation notes sometime in 1978.
We started our compiler because we couldn't find a suitable version of
PASCAL on PRIME 300 computers. The only other implementation that we know of
is an implementation of Per Brinch Hansen's Sequential PASCAL. We did some
work in early 1977 taking bugs out of this implementation and it is now available from PRIME Computer International, Bedford, England. We don't like it
because: (a) Sequential PASCAL doesn't permit nested procedures, (b) it's
We currently teach ALGOL 60 to our Computing s,cience undergraduates.
After much debate within the department, we" will be teaching PASCAL to our
first years from October 1978. For this purpose we'll be using the Belfast
Mk.2 compiler as the University's mainframe is an ICL 1904S.
The conversion to PASCAL would be easier if there was a book which properly teaches programming! We haven't found one yet. Addison Wesley arebringing out a book in early 1978 which we think may be suitable - it's
entitled "Programming in PASCAL" and written by PUG member Peter Grogono.

Yours sincerely,

g"~ 'LM )1~
Barry Cornelius.
Ian Thomas.
Dave Robson.

STANDARD: PASCAL-P subset of Standard PASCAL.

8.

MEASUREMENTS: No details are yet available.

9.

RELIABILITY: No details yet.
f-'
lD

10.
DEVELOPMENT METHOD: The code generation parts of the PASCAL-P4 compiler
are currently being rewritten to generate PMA which can then be assembled. The
first version of the compiler is being tested using the Belfast ~fr.2 ICL 1900
compiler. It will be bootstrapped on to the PRIME by using a P-code interpreter for the PRIME written in CORAL 66. The work has been done on and off
since June 1977 by five people - some have now left and some learnt CORAL 66
and PASCAL during this time!

very slow which makes it useless for teaching purposes.

Finally, we'd like to say what an excellent job you I re doing with "Pascal
News". It stimulated us into implementing PASCAL-P for PRIME 300s and is
keeping us well informed of what's happening elsewhere_ Thanks.

7.

'-J
00

11.
LIBRARY SUPPORT: No facilities for external procedures are currently available but they may be developed in the future.
Univac 1100 (Madison)
A short note appeared in the 24 October 1977 issue of the University of Wisconsin

Academic

Madison

Computer Center newsletter, MACC NEWS, which stated that "The UW-Pascal comp iler

is now fully supported by MACe." Two versio;;:-the relocatable, and the load-and-go,
mentioned.

were

Zilog Z-80 (San Diego)
For

information,

see Ken Bowles' article "Status of the UCSD Pascal Project", and for an

order form see the DEC LS1-11 (San Diego) implementation note.

I NDEXT 0 IMP LEMEN TAT ION NOT ES
computer Automation LSI-2

General Information

119&10: 60.
1111: 70.

Checklist
119&10: 60.
Applications
1111: 70.
Software Tools
119&10: 61.
Portable Pascals

Pascal-P
119&10: 61-62.
1111: 70-72.
Pascal Trunk
#9&10: 62.
Pascal J
119&10: 62.
Pascal Variants
Concurrent Pascal
119&10: 63.
1111: 72-74.
Modula
119&10: 63.
1111: 74.
Pascal-S
119&10: 63.
1111: 72.
Feature Implementation Notes

Set of Char
#9&10: 64-66.
For Statement

119&10: 66-69.
1111: 79-80.

Def ault Cas e
119&10: 69-70.
Variable Parameters
119&10: 71.
Interactive I/O
119&10: 71-72.
Unimplementable Features
1111: 75.
Long Identifiers
1111: 78-79.
Boolean Expressions
1111: 76-78.
Machine Dependent Implementations
Alpha Micro Systems AM-II
See DEC LSI-It.
Amdahl 470
See IBM 360, 370.
Andromeda Systems 11-B
1111: 80.
Burroughs B1700
119&10: 73.
Burroughs B3700, 4700
119&10: 73.
Burroughs B5700
119&10: 74.
1111: 81.
Burroughs B6700, 7700
119&10: 74-75.
1111: 81.
CDC Cyber 18 and 2550
119&10: 75.
1111 : 81-82.
CDC 3200
119&10: 75.
1111 : 82.
CDC 3300
119&10 : 75.
CDC 3600
119&10: 75.
CDC 6000, Cyber 70, Cyber 170
119&10: 76.
1111 : 82-83.
CDC 7600, Cyber 76
119&10: 76.
1111: 83.
CDC Omega 480-1, 480-11
See IBM 360, 370.
CDC Star-100
119&10: 77.
CIl Iris 50
119&10: 77.
Cll 10070, Iris 80
119&10 : 77-78.

119&10: 78.
Cray Research Cray-1
119&10: 78-79.
Data General Eclipse
119&10: 79-80.
1111: 85.
Data General Nova
119&10: 79-82.
1111: 83-85.
DEC PDP-8
119&10: 82.
1111: 85.
DEC LSI-II and PDP-II
119&10: 82-88.
1111: 86-91.
DEC DECSystem-10
119&10: 89-9l.
1111: 91-92.
Dietz MINCAL 621
119&10: 91-92.
Foxboro Fox-1
119&10: 92.
Fujitsu FACOM 230
119&10: 92.
Harris / 4
119&10: 92-93.
Heathkit H-ll
119&10: 93.
Hewlett Packard HP-21MX
119&10: 93.
1111: 92.
Hewlett Packard HP-2100
119&10: 93.
Hewlett Packard HP-3000
119&10: 94.
Hitachi Hitac 8700, 8800
119&10: 94.
Honeywell H316
119&10: 94.
1111: 93.
Honeywell 6000
119&10: 94-95.
#11: 92-93.
IBM Series 1
119&10: 95.
IBM 360, 370
119&10: 95-101.
1111: 93-100.
IBM 1130
119&10: 101.
ICL 1900
119&10: 101-102.
1111: 100-101.
ICL 2900
119&10: 102.
#11: 100,101-102.
Intel 8080, 8080a
119&10: 102-103.
1111: 102.

Interdata 7/16
/19&10: 103.
Interdata 7/32, 8/32
119&10: 103-104.
ITEL AS/4, AS/5
See IBM 360, 370.
Kardios Duo 70
119&10: 104.
Mitsubishi MELCOM 7700
119&10: 104-105.
MITS Altair 680b
See Motorola 6800.
MITS Altair 8800
See DEC LSI-11.
MaS Technology 6502
See DEC LSI-11.
Motorola 6800
119&10: 105.
1111: 102.
Nanodata QM-1
119&10: 105.
NCR Century 200
119&10: 105.
Norsk Data NORD-10
119&10: 106.
Prime P-300
1111: 103.
Prime P-400
119&10: 106.
SEMS T1600, SOLAR 16/05/40/65
119&10: 106.
Siemens 330
119&10: 107-108.
Siemens 4004, 7000.
119&10: 108.
Telefunken TR-440
119&10: 108.
Terak 8510
See DEC LSI-ll.
Texas Instruments TI-ASC
119&10: 109.
Texas Instruments 9900/4
119&10: 109.
Univac 90/30
119&10: 109.
Univac 90/70
119&10: 109.
Univac 1100
119&10: 109-112.
1111: 103.
Univac V-70
119&10: 112.
Varian V-70
See Univac V-70.
Xerox Sigma 6, 9
#9&10: 112.
Xerox Sigma 7
119&10: 112.
Zilog Z-80
119&10: 112.
1111: 103.

=
rn
~
C/)

-n
rn
OJ
;;0

=
;J:>
=

-<

I-'

<.D
'-J
00

POLICY:

PASCAL USER'S GROUP

Purposes:

(77/12/30)

Pascal User1s Group (PUG) tries to promote the use of the programming
language Pascal as well as the ideas behind Pascal. PUG members help
out by sending information to Pascal News, the most important of which
is about implementations (out of the necessity to spread the use of
Pascal).
The increasing availability of Pascal makes it a viable alternative for
software production and justifies its further use. We all strive to
make using Pascal a respectable activity.

Membership:

Anyone can join PUG: particularly the Pascal user, teacher, maintainer,
implementor, distributor, or just plain fan. Memberships from libraries
are also encouraged.
See the ALL PURPOSE COUPON for details.

FACTS ABOUT Pascal, THE PROGRAMMING LANGUAGE:
Pascal is a small, practical, and general purpose (but not all-purpose)
programming language possessing algorithmic and data structures to aid
systematic programming. Pascal was intended to be easy to learn and
read by humans, and efficient to translate by computers.
Pascal has met these design goals and is being used quite widely and
successfully for:
* teaching programming concepts
* developing reliable IIproductionll software
* implementing software efficiently on today1s machines
* writing portable software
Pascal is a leading language in computer science today and is being
used increasingly in the world1s computing industry to save energy and
resources and increase productivity.
Pascal implementations exist for more than 62 different computer systems,
and the number increases every month. The Implementation Notes section
of Pascal News describes how to obtain them.
The standard reference and tutorial manual for Pascal is:
Pascal - User Manual and Report (Second, study edition)
by Kathleen Jensen and Niklaus Wirth
Springer-Verlag Publishers: New York, Heidelberg, Berlin
1975, 167 pages, paperback, $5.90.
Introductory textbooks about Pascal are described in the Here and There
Books section of Pascal News.
The programming language Pascal was named after the mathematician and
religious fanatic Blaise Pascal (1623-1662). Pascal is not an acronym.
Pascal User1s Group is each individual member1s group. We currently have more than
1351 active members in more than 30 countries. This year Pascal News
is averaging more than 150 pages per issue.

~
(.)

-

.o
a.

Return to:
University Computer Center
227 Experimental Engineering Building
208 Southeast Union Street
University of Minnesota
Minneapolis, Minnesota 55455 USA
return postage guaranteed

The University of Minnesota is committed to the policy that all persons shall have equal access
to its programs, facilities, and employment without regard to race,
creed, color, age, sex, national origin, or handicap.



---

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 14:38:54-08:00
Modify Date                     : 2011:06:15 14:49:10-07:00
Metadata Date                   : 2011:06:15 14:49:10-07:00
Producer                        : Adobe Acrobat 9.43 Paper Capture Plug-in
Format                          : application/pdf
Document ID                     : uuid:77760cdf-4caf-44a6-b95f-9f6dccde6c8e
Instance ID                     : uuid:cd98e5e4-58f5-4057-9eef-e166f1de06f9
Page Layout                     : SinglePage
Page Mode                       : UseNone
Page Count                      : 108

EXIF Metadata provided by EXIF.tools