06_Pascal_Newsletter_Nov76 06 Pascal Newsletter Nov76

06_Pascal_Newsletter_Nov76 06_Pascal_Newsletter_Nov76

User Manual: 06_Pascal_Newsletter_Nov76

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

Download06_Pascal_Newsletter_Nov76 06 Pascal Newsletter Nov76
Open PDF In BrowserView PDF
PASCAL USER'S GROUP
USER'S

PASCAL NEWSLETTER

GROUP

NUMBER 6
COMMUNICATIONS ABOUT THE PROGRAMMING LANGUAGE PASCAL BY PASCALERS

NOVEMBER 1976
J

TAB L E OF

#
*
#
*
#
*
if.
*
#
*
#
*
#
*
#
*
#
*
#
*
1/
*

o
1

5
5

8
9
10
11

12
33
33
34

35

36
42
45

48

*

64
64
65

#

70

*

91

#

#

Co

N TE NT S

POLICY
EDITOR's CONTRIBUTION
HERE AND THERE WITH PASCAL
News
Conferences
Books
Errata
Back Issues
Membership Roster
ARTICLES
"Indexed Files"
- S. Knudsen
liThe Need for Hierarchy and Structure in
. Language Management"
- G. Michael Schneider
liOn the Suitability of a Pascal Compiler in
an Undergraduate Teaching Environment"
- A. M. Addyman
"Pascal Potpourri"
- Richard J. Cichelli
liThe Case for Extending Pascal's 1/0"
- Michael Patrick Hagerty
"General Thoughts on Pascal Arising out of
Correspondence Between Southampton and Tasmania"
- Arthur Sale
OPEN FORUM FOR MEMBERS I
IMPLEMENTATION NOTES
Checklist
Portable Pascals
Compilers and Software Tools
ALL PURPOSE COUPON

#
*
#
*
#
*
#
*
#
*
#
*
#
*
#
*
#
*
#
*
#
*
#
*
.#
*
#

POLICY

PASCAL USER'S GROUP

AND

PASCAL NEWSLETTER

USER'S GROUP POLICIES
Purposes - are to promote the use of the programming language Pascal as well as the
ideas behind Pascal. Pascal is a practical language with a small ~ systematic
and general purpose structure being used for:
* teaching programming concepts
* developing reliable IIproductionli software
* implementing software efficiently on today's machines
* writing portable software
Membership - is open to anyone: particularly the Pascal user~ teacher, maintainer,
implementor, distributor, or just plain fan. Institutional memberships,
especially libraries, are encouraged. Membership is per academic year ending
Jun~ 30.
Anyone joining for a particular year will receive all 4 quarterly
i ssuesof PMc..a.t N~ e..tteJt for that year. (In other words, back issues are
sent automatically.) First time members receive a receipt for membershi~;
renewers do not to save PUG postage.
Cost of membership per academic year is $4 and may be sent to:
Pascal User's Group/ %Andy Mickel/University Computer Center/ University of
Minnesota/Minneapolis, MN 55455 USAf phone: (612) 376-7290
In the United Kingdom, send t2.50 to:
Pasca 1 Users I Group/ %Judy Mull i ns/Mathemati cs Department/The Uni versity/
SOUTHAMPTON/S09 5NH/United Kingdom/ (telephone 0703-559122 x2387)
NEWSLETTER POLICIES
The PMc..at N0W6letteJt the official but informal publication of the User's Group. It
is produced quarterly (usually September, November, February~ and May). A
complete membership list is printed in the November issue. Single back
issues are available for $1 each. Out of print: #s 1~2,3
#4 available from George Richmond/Computing Center/U of Colorado/Boulder/80309

>l)

-

.....I

o0...

The contribution by PUG members of ideas, queries, articles, letters, and opinions for
the N0W6letteJt is important. Articles and notices concern: Pascal
philosophy, the use of Pascal as a teaching tool, uses of Pascal at different
computer installations, portable (applications) program exchange, how to
promote Pascal usage, and important events (meetings, publications,etc.):
Implementation information for the programming language Pascal on different computer
systems is provided in the NW.6letteJt out of the necessity to spread the use
of Pascal. This includes contacts formaintainers, documentors, and
distributors of a given implementation as well as where to send bug reports.
Both qualitative and quantitative descriptions for a given implementation are
publicized. Proposed extensions to Standard Pascal for users of a given ~
implementation are aired. Announcements are made of the availability of new
program writing tools for a Pascal environment.
Miscellaneous features include bibliographies, questionaires, and membership lists.
Editor's notes are in Pascal style comments (**).

WR ITTEN I NFOR~1AT I ON FOR THE Ne.w.6le.tte.Jt IS EAS I ~R TO PR I NT I F YOU TYPE
ALL MATERIAL l~ OR DOUBLE SPACED SO THAT IT IS IN 'CAMERA-READY" AND
"PHOTO-REDUCIBLE" FORM FOR THE PRINTER. REMEMBER~ ALL LETTERS TO US WILL
BE PRINTED IN THE Ne.w.6le.tte.Jt UNLESS THEY CONTAIN A REQUEST TO THE CONTRARY.
AN OVERRIDING GUIDE SEEN IN AN OLD MAO MAGAZINE APPLIES: "alR.the. nW.6that
6~,

we.

~!"

- Andy Mickel, editor, Jonn-P. Strait, associate editor. Nov. 10, 1976.

UNIVERSITY OF MINNESOTA
TWIN CITIES

University Computer Center
227 Experimental Engineering Building
Minneapolis, Minnesota 55455

(612) 376-7290

PART I - Standards
Wow! It took only one issue of PUG's Pascal Newsletter to bring on an avalanche
\ of "Where do we go from here?"s! It was first put clearly in print with a short note
in PUGN #3 by George Poonen who noted that various implementations had diverged and
that a standard was necessary. Now we have: Tony Addyman, Frank Brewster, Charles
Hedrick, and Willett Kempton (see News in HERE AND THERE); Mike Schneider, Rich
Cichelli, and Arthur Sale (see ARTICLES); and Steve Young, Tony Addyman (again),
Duke Haiduk, Judy Mullins, Arthur Sale (again), and Tim Bonham (see OPEN FORUM) all
discussing the topic of standards. The concern, I believe, is out of our desire to
see Pascal succeed. We are in a computing environment which is not altogether
friendly to Pascal. We want to be able to respectably use Pascal in the future.
I have been very confused on the subject of Pascal standards in the past. Mike
Schneider and Rich Cichelli have (I think) straightened me out. You see, I thought
we already had a Standard Pascal, with the Revised Report and the Axiomatic
gefinition. These two concise and elegant (although not perfect - but yet what do you
want?) documents were produced by Niklaus Wirth and his associates and coworkers.
And I believe that Pascal has merit because it was produced by a single man of the
calibre of Niklaus Wirth, who (as evident from his work) profoundly understands
programming language design, from linguistics to implementation. This one person
could decide what to meld when meeting ~ of the design goals set out from the start.
I wanted to do what I could to call for adherence to what Niklaus Wirth called
"Standard Pascal". Because with time, I i ncreas i ngly appreci ated what he had wri tten
in several articles. He pointed out for example that certain "favorite features" had
to be omitted in order to meet the design goals of a small and efficient system. Also
that some aspects were be~ left undefined. And that other features were omitted with
good reason to achieve the goal of providing a tool with which to produce reliable
software (okay - you could call it: "protect the error-prone human programmer from
himself or herself." It may not be pleasant, but el::1

m
:::0

HERE AND THERE WITH PASCAL
(NEWS FROM

~[MBERS.

CONFERENCES. NEW BOOKS. APPLICATIONS PROGRAMS. ETC,)

Willett Kempton, 2512 San Gabriel St., Austin, TX 78705 (PUG member):
for the nevls1etters. '"

K. Frankowski, Computer Science Dept., 114 Lind Hall, University of Minnesota,
Mi nneapo 1 is, MN 55455 (PUG member):

"If one wants to have formatted reads,

simply read several integers (if they are run together) as one integer and use
div and/or mod to extract the values desired."

(*10/15/76*)

will be implemented in CDC Pascal; this is clearly an extremely important
feature, and I would urge that it become a feature of the standard language,
rather than an extention available in some implementations (and not others).
"Keep after those i mpl ementers to accept standard Pascal programs!!" (*10/27/76*)

Dennis Graham, Amdahl Corp., 1250 E. Arques Ave., Sunnyvale, CA 94086 (PUG member):
\

C. A. ~, Cambridge University Press, Pitt Building, Trumpington St.,

"I am interested in running Pascal on an Amdahl-470 V/6 system and am contacting

Cambridge CB2 lRP, United Kingdom (PUG member):

the University of Manitoba about thei r compil er."

publishing books concerned with Pascal."

(*10/26/76*)

David J. Griffiths, Academic Computer Centre, Tyler Hall, University of Rhode
Island, West Warwick, RI 02881 (PUG member): "I am investigating the possibility
of implementing Pascal on our lBM360-370.

"Thanks

1 was delighted to see that dynamic array parameters

Concurrent Pascal would be the ideal,

"He are interested in

(*10/26/76*)

of Technology, Rochester, NY 14623 (PUG member): " ... 1 would also appreciate
any information you might have on Pascal implementations for the Xerox
(Honeywell) Sigma 5 - 9 and PDP 11 computers.

PDP 11/T34 (with 48K words of memory) here at R.l.T., and we are interested

E. Grimes, 90 Sylvia Street, Arlington, MA 02174 (PUG member):

"Congratulations on a timely Newsletter #5, and thanks for your efforts in
establishing PUG."

(*10/8/7~*)

(PUG member):

"When considering operational definitions of portability maybe

" ... We plan to bring up Pascal on the
(*10/18/76*)

Judy Mullins, Computer Studies Group, Department of Mathematics, The University,

-machine independent

happy in Southampton.

" ... Pascal is alive and

One hundred nineteen-year-01ds are pushing in programs

-semi-machine dependent and concepts universal

by the hundreds ... and doing amazingly well.

-machine dependent and site independent

that is so friendly that increases their interest and output ...

Carl Henry, Computer Center, Carleton College, Northfield, MN 55057 (PUG member)
" ... We are using ... the University of Illinois version (Mickunas, et a1) and
runs under DOS V4 on an 11/20, (very 1 ittl e use has been made of it so far.).
"A brief description of our facilities:

6 PDP-8s - home brewed version of

TSS/8 and 05/8; PDP 11/20 - 005, RT-11, RSTS V4; PDP-ll/40 - RSTS V6, UNIX V6."
(*10/15/76*)

"currently modifyi ng P2 vers i on of Janus compil er for readabil ity, fi xi ng bugs,
expanding subset processed, and improving portability.

I do believe it is the language

" ... I was wondering if it wou1 d be appropri ate to have a section of PUGN for
exchange of.course ideas, examples etc. This would have to be firmly
controlled space-wise, but could prove very informative expecially for
universities who have Pascal but don't teach it yet.
use of Pascal in teaching would be of great interest.

Later on a survey on the
Addyman's survey

showed Pascal is growing and therefore its growth should be monitored every
year.
"Another thought was for book reviews.

Mark Hersey, 323 Village Drive Apt. 534, East Lansing, Ml 48823 (PUG member):

Pascal primers are beginning to

proliferate and we have strong views on the ones we've seen.

Once again, to

have the right effect this section would need to be controlled, and I'm not
sure that we want to start issuing PUG marks of approval or anything like that.

"All work being done on Michigan State University's CDC 6500."

(*10/4/76*)

HO\~ever, reviews in normal journals are only opinions and it does seem fitting

Bri an W. Johnson, 1525 Wes t1 ake, P1 ano, TX 75075 (PUG member):

"I am

for optnions of Pasca1ers on Pascal books to be in the Pascal Newsletter."
(*11/3/76* )

particularly interested in p processor versions.
and PDP-II at UT Dallas."

(*11/4/76*)

We have it on the PDP-10

en

(*10/27/76*)

CRAY-I, probably using the P-code compiler to bootstrap."
Southampton 509 5NH, United Kingdom (PUG member):

(*10/15/76*)

rn

John Montague, Los A1 amos Sci enti fi c Laboratory, Group Cll - Mai 1 Stop 296,

it is useful to distinguish among versions that are:

"The last choice may not be so bad for Pascal to shoot for."

rn
--f
--f

We have both a Sigma 9 and a

in obtaining Pascal for use in our courses .... "

Los Alamos, NM 87545 (PUG member):

Charles Hedrick, 183 Commerce West, University of Illinois, Urbana, IL 61801

r-

Mi chael Lutz, School of Computer Science and Technology, Rochester Institute

prepared to settle for less."
Donald

rn
U')

;;0

since we wish to investigate more advanced operating systems, however, we are
(*10/3/76*)

z
:.;:

C>

<
rn
t:C

rn
;;0

"0

APPLICATIONS PROGRAMS
Fred Powell, Computer Center, Mary Baldwin College, Staunton, VA 24401 (PUG
member); "We have Pascal P2 and are interested in implementing Pascal on an
IBM 1130 and possibly a System 3. Other possibilites include investigating
data bases and disk access techniques wi th Pascal." (*9/24/76*)
Douglas H. Quebbeman, 2235 Lombardy Drive, Jeffersonville, IN 47130, (PUG
member); " ... Having seen the article in the June '76 Random Bits (Indiana
University's Computing Center Newsletter) on the Pascal User's Group, I
decided to join. I am a student and part-time operator - programming
consultant and have only recently begun using Pascal, but 1 am quite enthusetl
about its flexibility (especially considering my wrestling bouts with Fortran)
and hope to become more proficient in it. So, thanks (for forming the User
Group) and 1 hope to hear from you soon." (*9/24/76*)
Peter A. Rigsbee, Code 5494, Naval Research Laboratory, Washington, DC 20375
(PUG member); " ... My connection with Pascal is that my group is trying to get
Per Brinch Hansen's SOLO operating system to run on a PDP 11/40, and once this
is done, will be using Pascal as a primary systems programming language .... "
(*8/25/76*)
Sergio de Mello ichneider, Departamento de Computa~ao, Univ. Federal de S.
Carlos, C.P. 384, 13560 S. Carlos SP, Brazil (PUG member); "We have a
HP 2100A at our installation (32K words core, 2 disks, 1 tape, DOS) and we
are looking for a Pascal compiler. There is no way we can produce one in
the next 3 years. Caul d you hel pus?" (*10/21/76*)
Stephen C. Schwarm, E. I. du Pont de Nemours Co., 101 Beech St., Wilmington,
DE 19898 (PUG member): "1 am chairman of OEGUS SIG Pascal and I will be glad
to help with distribution any systems on DEC PDP-ll's." (*10/29/76*)
Dave Tarabar, Data General Corp., Field Engineering, 235 Old Connecticut Path,
Framingham, MA 01701 (PUG member); "1 was very pleased to receive and read
the first PUG 'Pascal Newsletter. It was full of interesting information.
The newsletter will be very useful in publishing the correspondence with
Zurich and other implementors and your summar.Y of all known implementations
was great. Keep up the good work.
(*10/18/76*)
U

William P. Taylor, L-315, University of California, PO Box 808, Livermore, CA
94550 (PUG member); "I am interested in obtaining information about
implementations of Pascal on I6-bit mini-computers. I am especially interested
in implementations for the PDP-II as we will be getting one soon. Also, some
of m.Y fellow employees here at lawrence livermore laboratory wish to implement
a structured programming language like Pascal for system development on a new
mini-computer."

(*10/3/76*)

»

en

STANFORD UNIVERSITY

n

»
M.1:1 AJ.fUII
SLAC. p, O. Box 4349
S[J;nlocd. Cali£orniJ 94305

STA"FORD LINEAR ACCELERATOR CENTER

r-

1? Octoher, 1976

Request for Prograns

Pacal Users:
I am presently doing research on Pascal to determin~
how various parts of the language are used an~ w~at patterns
of execution occur in actual prORrans. This will he similar
to a study done by Knuth on Fortran (1).
In this regard 1 am interested in obtainin7, a saMple of
programs ·ro~ a wide range of users in hopes that the results
of this st'trly might be representative of the actual use of
Pascal.
If you have or know of prORraMS which can he lent to t~is
effort, I would very much 1 ike to hear frOM you.
I can be
contacted by mail at
11all Drop 88
Stanford linear Accelerator Center
P. O. flox 4349
Stanford, CA. 94305
or by phone at
(415)

854-3~On

X2e02.

John Banning
(1)

O. E. r.nuth, "~n EMpirical Study of FOPTPMI Pror,rams",
Softl'/are Pract.cf' anrl Exnerience, Vol. 1 (971), l()S-13'.

(*Note; John also enclosed a note which said; "With regards to the enclosed
request, 1 expect that the mentioned study will complete sometime in the
first quarter of 1977. I would be most happy at that time to provide a
summary of the results for the Newsletter if 'you are interested - ... Does
there exist some formal mechanism for Pascal program interchange (between
users), and, if so. who is runni ng it and how can I contact them?"*)

2

o
-<
,."

PAGE 8

NOVEMBER. 1976

PASCAL NEWSLETTER #6

THIRD ANNUAL COMPUTER STUDIES SYMPOSIUM
UNIVERSITY

OF

SOUTHAMPTON

A

AIMS

AA
A A
A A A A
A
A
A A
. A A
A
A
A
A
AAAAAAAA

~

*.

~

A~

-_."

A~

A
A
A
A
A A A A
A " A "
A
A
"
A
AA
AA
AA
AA
AAAAAAAA
A A A A A A A A A A A A A A A A

'-'

A

A

A

A A

A A

PASCAL

A

A A A A
A

A

IMPLEMENTATION
A

A A
'A
A
AAAA

A "
A
A
AAAA

A

A

A

In the tradition of the Southampton symposium,
speakers will be allowed ample time for their
presentations, together with provision for a discussion
at the end of each lecture. Attendance will be kept
to 100 and it may be necessary to limit applications
from each institution. Applicants are expected to
have a working knowledge of PASCAL.

A

A A
A A
A
A
A
A
AAAAAAAA

AND

APPLICATIONS

A

A

A

~he purpose of this symposium is to explore
"what's going on" in PASCAL at the present time.
Leading authorities will describe new implementations
and applications in systems programming, research and
education. The symposium will end with an open
discussion about the future of PASCAL.

A A A A

A

A A
A A
A
A
A
A
AAAAAAAA

A

Few languages since FORTRAN have had the same
run-away success as Niklaus Wirth's PASCAL, which shows
signs of becoming a de facto standard for Computer
Science teaching and research, as well as pointing
the way to a new generation of sparse, simple languages.

A

A

A A
A
A
AAAA

A A
A
A
AAAA

A

A

A

A

AA
'AA
AA
AA
AA
AA
AA
AA
AAAAAAAAAAAAAAAA
A A A A A A A A'A A A A A A.A A A A A A A A A A A A A A A A A A

24

AND

Full preprints of the Proceedings will be
available on registration; the Proceedings will
subsequently be. published in book form.

25 MARCH 1977

SYMPOSIUM CHAIRMAN
PROFESSOR D,W. BARRON

SYMPOSIUM ORGANIZER
MISS J.M. MULLINS

SPEAKERS
Dr.Urs Ammann
Techn-i-sche Hachschule
Zurich
Swr.TZERLANO

***
Prof.David Barron
Mathematics Department
The 'University
SOUTII..AMPTON

Dr.Mike Rees
Computer Studies Group
The Uuiversity
SOUTHAMPTON

PROGRAMME
IMPLEMENTATION

*-10*
Dr.David Watt
Computer Science Department
University
GLASGOW

Dr.U.Ammann

The Zurich Compilers

Dr.J.Welsh

Two ICL 1900 Compilers

Dr.D.A.Watt

A Diagnostic System

Dr.M.J.Rees

PASCAL on an Advanced Architecture
A PASCAL Machine?

Miss J.M.Mullins.
Dr.Per Brinch Hansen
Computer Science Program
University of Southern
California
LOS ANGELES

Dr.Graham Webster
Computer Science Department
Teesside POlytechnic
Middlesborough,
CLEVELAND.

Dr.Barry Hood
Electronics Department
The University
SOUTHAMPTON

Dr.Jim Welsh
Computer Science Department
Queen's University
BELFAST

Miss Judy Mullins
Computer Studies Group
The University
SOUTHAMPTON

APPL"ICATION
Dr.P.• Brinch Hansen Concurrent PASCAL
Dr.G.Webster
PASCAL in Education
Dr.B.Hood
PASCAL in Research
THE FUTURE

Panel Discussion introduced by Prof.D.W.Barron

-0
:l:>

BOOKS

AND

(/)

ARTICLES

(*There has been no news of new books on Pascal. In future issues of the
Newsletter, we should also list current articles appearing in journals and
other computer science literature. fpologies for the void in this section
in this issue.*)

>
n

'"

~
H

(*Last issue there were a couple mistakes in the list of books; these are
corrected below.*)
A Primer on PASCAL by Richard Conway, David Gries, and E. C. Zimmerman,
Winthrop Publishers, 1976, 448 pages, paperbound, $9.95.
Introduction to Problem Solving and Programming with Pascal, by G. Michael
Schneider, Steven \~. Weingart, and David M. Perlman, Wiley. to
be published in late 1977. (*A complete soft cover manuscript
will be available March 1. 1977 and may be ordered from Michael
Schneider, Computer Science Department, 114 Lind Hall. University
of Minnesota, Minneapolis, MN 55455. Such copies may be
duplicated(once received) for local use.*)
PASCAL User Manual and Report, by Kathleen Jensen and Niklaus Wirth,
Spri nger-Verl ag, 1974, 1975, 167 pages. paperbound, $5.90.
Second (study) edition. (*This book is selling well; it's in
its third printing which now incorporates the errata that
appears on the next page as reproduced from Newsletter #4. In
Newsletter #5 we printed out of date errata because no one
kindly informed us of anything more up to date. So like the
implementation 'notes, we are only as good as what people send
us to print. Note that this errata includes the change to the
language Pascal - namely the generalization of the read and
write procedures to perform I/O on files of any type, not just
text files. *)

I~

II

~
~

6

g "0m:~.
lJ>'

.,.

......
.. "
"''" ......
I» toi
rt ..

...

II>

...

"

0

IT

II> '"

"0
rt 0

... rt
.. 0
II>

.. .. ...'"
~

~",

Z

".

.......

...rt"'OO
" '"

I

I

I

:.:",>
n:.: t">
o ;:::I'tJ a CD c::: n

0

;U)~-9~~g



..

...,

"'II>

..... ru

'< " tJo
.. n

rt '< II>

p.. ..... "

0'" II>

..

ID

In
II>

...
0>

"

...

Qq

IU .....

II> "

"

C

(J

a
a

CA

A-

P"

0

~

...
II>

'0

'"

0

II>

..

IT

"

...

IT

II>

0

II>
'"

0>

0

... n.

I>

H"O

.. 0

0> '" ..

rt

...

"'II>

'<

'<
'" p,
•. ....
II>

I>

II>

I>

W .....

td p..
'" II>
'0 " (1)
rt 0

II> 0

II>

0-,) II>

II>

fIl

Pi

~::s
II>

0-,)

"00'0

II>

II>

IT'"
'< 0

",0>"
"

"

"'00

~

(1)

0 .....

WID'"

0

b'"

......... to

..

n.rt

'" ... ID

.....,~l1rt

~

H

n
~
H

=

0

0"

".

,

[""'

,z
I

" <
'"" ...... " ....'" .........:os .."...a
. ...
i':::
...
..'" '" .....t1..cc:: "
.:1 .......
. '" " ..... '"'"" "'<
'" ",s :os ..
...... ::snj:l.
o ...... '"
\'". '"
" <
n
'" ... ""'"
... ...
"",n o ...
...
,,'"
" ...
..
"'''''''
.....
~ ~
o ....
'<
"''''" .. ... m
.... '"
...
'"
...
"...." ..... .......
......
'<
"' ... " .... . o .... no " ::s
"
".... "''" . o
<
..
'"
.
" .. tIl
".... ~ ..... "
" . ::s'" "
". .....
" ... ...........
n" '"
.... "'''
......'" " ,z~ ..a. ......
"
......
....
"o .,."
'"
"...... ...'" ::r
C '"
..., .....
~ IT
It>

..... n
cr .... fD'CS

.....,

~
....

0

,z

VI ...
NUl ,.. ......

A. M. Addyman and H. R. Addyman, "Which Language?", Computer Bulletin,
June, 1976. pp 31-33. [an article which surveys the language
used at various institutions teaching computer science]

~
....

n

0

rt'<

~

rt ...

0",
n.
0
"
... " 0-,)1>
II>

.....,.

.....
lJ>

"....n
"....
"'"
II>

0

t-h

II> "

o-j1)'1~

rt

0

II>

0

'"

"

:::;:Jg'~

"''''

-t
-t

=
rn
rn
=
Gl

rn

3:

AI

-t

'""

(/)

0"1

l'a
P!
t-<:"d n
Otb

...S

'< 0

"".ID

ttl
.... Q.,

'0
...

'"'"
'"

'< "

hj

"'n"

",0>'"

rn

::0
::0

t-t. ....... C"'ha

,<

'< '"

II> 0

~

;J>

o ....

".

::r'11
ID

'"'"

> ...
O'i<'"

'<

rt .....

CD .... ~ t-J
m;:::lPoo::r

OQ

:; e
".'"

"

~

,...." I'zj t1

0

11>00

~

" "'"" ......

til

II>

.

'

o "
"0

oS

,

~

n

0

"0 ~ rt 0
PJt:::Tt-1'I

","'0>

'"d 1-'0 ell
'"" to

.. ..

n
n

rn
::c

til

:z
0

-<

00

rn

rt

3:

II>

In

tx:l

rt

rn
::0

..r::-

'-l
0'1
O'l

.....

><

......

-

-i

rn
rrn

-t

:z

-t

rn

..r::..r::-

:z

'-l
0

-t

I

\.N
I

::0
~

0

:z
~

V1
V1
1.0

.r-

N

rn
,rn

.....
N

rrI

X
-I

'J
\.N
\.N

-i
-0

»

0

:;<:

0

::r:

\.N

:z

."

0

;0

I

V1
V1

t.O

-0 ......
»
N
en N

n
»
r

rrI

X
4

(/)

=

:;: \.N

rn

-0

en '-l

::r:
0

rn
rrn

-<

'-l

."

\.N

0

en

c

:;:
(/)

rrI

0

rn

;J>

t.O

rrn

'-l
0'1

r-

r~"~»
0:1:»»

=m4en
-i
:I: n
==1'1
:t>z:;:r

:z
ID

c::

- -

3: - »
,
-0< 4
(/)
- i 1'1
-<

o ;0 n
z'" en
-I

(/) -<

0'"
1.0

»
;0
4

::r:

0

~en

rrI
."

V1

Z

:;:

."

;::0

rn
en

-i
0

C

:;:

...

:;:
1'1
Z

4

"

-0
~

n

Gl

m
4
»

rn

;0

;0

-<

1.0

PASCAL NEWSLETTER #6
Errata to
PASCAL
User Manual
and Report
Second Edition.

NOVEMBER, 1976
I:J

I

PAGE 10

c

13 -3 r
45 -18 l'
51 16 l'
56 -6 1'"
63
2 l'

''If'' by "If"
"" by ""
"(output)" by "(output);"
"fl" by "f{i)". "g{i+1)" by "r:j{j+1)", "!=Ii" by "!=I{j)"
.e 1" by n "., .. 2'" by" n -1 ", tt 3 I. by"n -2
lot

lot .,

"(n-1)"' by "'2", "n" by "1"

69
70

KEY:
p = page number
1 = line number
(blank lines
are ; gnored
and negative
1i ne numbers
are counted
from the
bottom)
c = code
( that is:
r = replace
i = insert)

23 l'
7 l'
77 1.'3 l'
78 -14 l'
81
2 l'
84 -~5 l'
86
B 1.

"stricly" by "strictlY"
"l,j"' by "'i"

!te.stio. inorder(pT .11ink);" by ".tr..e.s..iJl inorder{pT .111nk):"
<'fern,sl'" by

It l'

H:

=", """ by "<>"
"neither be formal nor "non local" by
"not be declared on intermediate level"
177: assi~nment to function identifier not allowed here
178: multidefined record variant
179: X-opt of actual proc/ful'lc does not. match formal decleration
180: control variable must not be formal
181: constant part of address out of ranQe

21l5:

zero strinQ not allowed
integer part of real constant exceeds TanQe
260:
too many exit labels
'° 14 ... by "15";'
2136:

121 -8
124 -15 l'
124 -14 l'
127 27 l'
133
3 l'
135 w 5 r
135 30 r
140 11 r
161 -17 r"

"'4" by "15"'
"18.A" by "4.A
14

twO

'G

by "to"

Kalthought- by -although"
"subtstitutc

K

by "SUbstitute"

"structure type;' by "structured type"
whole 1 im, by
"addi tior!

161 -16 l'

k

to

the

162

·"6 1

D:U and

JlJ.Lt, The tex I:file9 the se

must

not necessarily represent"

H

",ho) e line by
"star,dare! prOCedUT"eS

162
3 r
162 -1 ~. i

procedure 9
apply

lo

"J:nd".Ilf ~ine"' by ".!.tnd Uf ~jlle"
The
procedure read can 8150 be used to read from a file f which
is not a
textf'ile. I'ead{r,x) is in thi.s case equivalent to
)( : .. f'T: gel{f).
The
procedure w~ite can also be u~ed to write onto a fil~ f
which is not a.tBxtflle. write(f,x) 1s in this case equivalent
to fT : .. x: puler).

PAST

ISSUES OF

PASCAL NEWSLETTER

Reproduced below is a complete description of ~ewsletters I, 2, 3. and 4.
Numbers I, 2. and 3 are out of orin~, but they did appear in issues of SIGPLAN
Notices, the ACM Special Interest Group on Programming LANguages monthly
journal. Number 4 is available for $1.00 from George H. Richmond. Computing
Center. 3645 Marine Street, University of Colorado, Boulder, CO 80309.
#1 January, 1974 (also SIGPLAN Notices Vol. 9 No.3 1974 March) 8 pages.
Table of Contents
1 From the Editor
Current CDC Pascal Compiler
5 Cost of the CDC Compiler
5 Forthcoming Versions of the CDC Compiler
6 Other Pascal Compilers
7 Modifications to CDC Pascal
7 Other Documentation
#2 May,1974 (also SIGPLAN Notices Vol. 9 No. 11 1974 November) 18 pages.
Table of Contents
1 From the Editor
1 Hi story of Pascal
2 Pascal for non-CDC machines
6 Pascal 6~OO-3.4 - N. Wirth
18 Pascal and Portability - N. Wirth
#3 February. 1975 (also SIGPLAN Notices Vol. 11 No.2 1976 February) 19 pages.
Table of Contents
1 From the Editor
1 Pascal User Manual and Report
3 Pascal Questionaire Results
4 History of Pascal. Revised - G. Richmond
8 Bibl iography
10 Portable Pascal
11 A Generalization of the Read and Write Procedures - N. Wirth
12 Corrections to Pascal 6000 - 3.4
13 Pascal 6000 - 3.4 Interactive Operation
13 Letters to the Editor

#4 July, 1976 (copies may be obtained for $1.00 from George Richmond.
the editor. as explained on the previous page) 103 pages.
Table of Contents
o From the Editor
Co"rrespondence
(altogether 36 letters and notices including much
implementation information)
81 A New Release of the Pascal-P System - Ch. Jacobi
86 Errata. PASCAL User Manual and Report (Second Edition)
88 Pascal User's Group
90 Pascal Implementors List
100 Bibliography (Literature about the Programming Language
Pascal)

=
rn
:c
C/)

r
rn
-I
-I

rn
;::0

ROSTER 11/1'4/76

\

For our mutual benefit 1n
communication, here is the 516
member PUG roster spanning 22
countries and 43 states. It is
sorted (intelligently, we think)
by zip (mail) codes (U.S. tirst)
and then alphabetically by country.
You can see at a glance who is at
a well known organization at a
well known place or who is in your
area (or on your street!). Now,
if you need an index by last name,
there is one at the end, crossreferencing with zip (mail) code.

*

~

* ** * * * * *

JEANNE FERRANTE
125 ANTRIM ST.
MA 02139
CAMBRIDGE
(617) 876-8635

EDWARD STEEN
119 SHERMAN STREET
MA 01852
LOWELL
(617) 454-9320

LLOYD DICKMAN
25 HAWTHORNE VILLAGE
MA 01742
CONCORD

AARON SAWYER
DEPT 330
THE FOXBORO COMPANY
MA 02035
FOXBORO
(617) 543-8750 X2029

R. STERLING EANES
SOFTECH
460 TOTTEN POND ROAD
MA 02154
WAL THAM
(61 7) 890-6900

rr1

ATTN: LIBRARY
ML5-4/A20
DIGITAL EQUIPMENT CORPORATION
MA 01754
MAYNARD

WARREN R. BROWN
D.330
THE FOXBORO COMPANY
38 NEPONSET AVE.
MA 02038
FOXBORO
(617) 543-8750 X2023

R. KRASIN
FIRST DATA CORP.
400 TOTTEN POND ROAD
WALTHAM
MA 02154
(617) 890-6701

::0

RONALD F. BRENDER
BLISS LANGUAGE DEVELOPMENT
ML3-5/E82
DIG ITAL EQU IPI~ENT CORP.
146 MAIN STREET
MA 01754
MAYNARD
(617) 897-5111 X2520

VICTOR S. MILLER
DEPT OF MATHEMATICS
BLDG 2
U OF MASSACHUSETTS
HARBOR CAMPUS
BOSTON
MA 02125
(617) 287-1900 X3170/X3161

DAV ID SOLOM)NT
COMPUTER SERVICES
MI LLER HALL
TUFTS UN IVERS ITY
MA 02155
MEDFORD
(617) 628-2943

:1:>
(/)

n
:1:>

r:z

PETER COLBY
289 MILL ST.
MA 02160
NEWTONV ILLE
(617) 527-2394

ALBERT S. BROWN
PK3-1/MI2
DIGITAL EQUIPMENT CORP.
146 MAIN STREET
MA 01754
MAYNARD
(617) 897-5111 X2391

MICHAEL MEEHAN
WINTHROP PUBLISHERS
17 DUNSTER STREET
MA 02138
CAMBRIDGE
(617) 868-1750

NORMAN E. SONDAK
COMP. SCI. DEPT.
\~ORCESTER POL YTECHN I C INST I TUTE
MA 01609
WORCESTER
(617l 753-1411

N. AM)S GILEADI
APPLIED SYSTEMS GROUP
ML 21-4 E-20
DIGITAL EQUIPMENT CORP.
146 MAIN STREET
MA 01754
MAYNARD
(617) 897-5111 X4402/X3888/X6472

ATTN: READING ROOM
INFORMATION PROCESSING CENTER
39-430
MIT
MA 02139
CAMBRIDGE

CHRISTOPHER K. JOHANSEN
FREEKSHOW ELECTONWORKS
176 GROVE STREET
AUBURNDALE
MA 02166
(61 7l 969-2399

HANK EDWARDS
2C BRACKETT ROAD
MA 01701
FRAMINGHAM
(617) 620-1066 (HOME)
(617) 897-5111 X6809

RONALD J. HAM
ML5-5/E40
DIGITAL EQUIPMENT CORPORATION
146 MA I N STREET
MA 01754
MAYNARD
(617) 897-5111

GABR IEL CHANG
TECHNOLOGY SQUARE
575
HONEYWELL INFORMATION SYSTEMS
MA 02139
CAMBRIDGE
(617) 491-6300

GEORGE POONEN
15 ORCHARD AVE.
MA 02168
WABAN
(617) 969-4684

BERN IE ROSMAN
MATH/CS DEPT.
FRAMINGHAM STATE COLLEGE
MA 01701
FRAMINGHAM
(617) 872-3501

WILLIAM F. SHAW
ML5-5/E40
DIGITAL EQUIPMENT CORPORATION
146 MAIN STREET
MA 01754
MAYNARD
(617l 897-5111

DONALD E. GRIMES
F. J. CORBATO
90 SYLVIA STREET
NE43-514
MA 02174
MASSACHUSETTS INSTITUTE OF TECHNOLOGY ARLINGTON
( 617) 646-4129
545 TECHNOLOGY SQUARE
MA 02139
CAMBRIDGE
(617) 253-6001

HENRY F. LEDGARD
COMPUTER AND INFO. SCI.
U OF MASSACHUSETTES
MA 01002
AMHERST
(413) 545-2744

-u

DAVID TARABAR
FIELD ENGINEERING
DATA GENERAL CORPORATION
235 OLD CONNECTICUT PATH
MA 01701
FRAMI NGHAM
(617) 620-1200

::c
(/)

rrr1
--i
--i
rr1

't!;
(J')

:z
0

-<
rn
3;

ttl
tTl
::0

......
t.O

'J

en

-u
:1:>
~

rn

......
N

MICHAEL HAGERTY
18 HAMILTON ROAD
ARLINGTON
MA 02174
(617) 492-7100

RICHARD D. SPILLANE
DEPT OF MATH/C.S.
WILLIAM PATTERSON COL.
WAYNE
NJ 07470
(201) 881-2158

T. A. D'AURIA
CENTER FOR COMPUTING ACTIVITIES
COLUMBIA UNIVERSITY
NEW YORK
NY 10027

NEWTON J. ~1UNSON
COMPU riNG CeNTER
CLARKSON COLLEGE
NY 13676
POTSDAM
(315) 258-7721

"
»
(/)

n

»
r

WILLIAM BARABASH
DEPT. OF COMP. SCI.
SUNY STONY BROOK
STONY BROOK
NY 11794
(516) 246-7146

TED TENNY
COWUTER SCIENCE DEPT.
SUNY - POTSDAM
NY 13676
POTSDAM
(315) 268-2954

:z
rn

TERRENCE M. COLLIGAN
RIVERSIDE OFFICE PARK
MANAGEMENT DECISION SYSTEMS INC.
RIVERSIDE ROAD
WESTON
MA 02193
(617) 891-0335

RON PRICE
PERKIN-ELMER DATA SYSTEMS
106 APPL E ST.
TINTON FALLS NJ 07726

DAVID J. GRIFFITHS
ACADEMIC COMPUTER CENTER
TYLER HALL
UNIVERSITY OF RHODE ISLAND
WEST WARWICK RI 02881
(401) 792-2701

RON OLSEN
ROOM 3E207
BELL LABORATORIES
HOLMDEL
NJ 07733
(201) 949-5537

GARRY MEYER
COMPUTING CENTER
SUNY STONY BROOK
STONY BROOK
NY 11794
(516) 246-7047

WILLIAM C. HOPKINS
207 RIDGEWOOD DRIVE
AMHERST
NY 14226
(716) 634-6346

Q)

ANDRIES VAN DAM
BROWN UNIVERSITY
BOX F
PROVIDENCE
RI 02912
(401) 863-3088

STEVE LEGENHAUSEN
12 BARNARD STREET
HIGHLAND PARK NJ 08904
(201) 572-6585

M. ELIZABETH IBARRA
DEPT. OF APPLIED MATH
BROOKHAVEN NATIONAL LABORATORY
UPTON
NY 11973
(516) 345-4162

G. FRIEDER
DEPT. OF COMPUTER SCIENCE
SUNY BUFFALO
4226 RIDGE LEA RD.
BUFFALO
NY 14226
(716) 831-1351

o

::0;:
(/)

r
rn
-l
-l

rn
::0

"It:

z

-<
ATTENTION: R. D. BERGERON
DEPARTMENT OF MATHEf4ATICS
KINGSBURY HALL
U OF NEW HAMPSHIRE
DURHAM
NH 03824
(603) 862-2321

WILLIAM HENRY
117 E. TENTH ST.
NEW YORK
NY 10003

WILLIAM J. VASILIOU JR.
COMPUTER SERVICES
KINGSBURY HAL L
U OF NEW HAf4PSH IRE
DURHAM
NH 03824
(603) 862-2323

EDlvARD R. FR I EDMAN
CIMslCS DEPT.
NEW YORK UNIVERSITY
NEW YORK
NY 10012
(212) 460-7100

J. SCOTT MERR I TT
36 OAKWOOD AVE.
TROY
NY 12180
(518) 271-7553

JAME S MOLONEY
DEPT. OF COMPo SCI.
SUNY BROCKPORT
BROCKPORT
NY 14420
(716) 395-2384

......
to

JAMES P. SHORES
344 GLENWOOD AVE.
NEW LONDON
CT 06320
(203) 442~0771 X2126

ROSEMARY HOWBRIGG
36 MENUNKETESUCK DRIVE
CLINTON
CT 06413
(203) 669-5812 (HOME)
(203) 442-0771 X2963 (WORK)

PETER PAWELCZAK
UNIVERSITY COMPUTER CENTER
CIO LIBRARY
. CUNY
555 W. 57TH ST.
NEW YORK
NY 10019
HOWARD D. ESKIN
CENTER FOR COMPUTING ACTIVITIES
ROOM 712
COLUMBIA UNIVERSITY
612 W. 115TH ST.
NEW YORK
NY 10025
(212) 280-2874

GEORGE H. WILLIAMS
EEICS DEPT.
UNION COLLEGE
SCHENECTADY
NY 12308
(518) 370-6273

MICHAEL J. LUTZ
SCHOOL OF COMPUTER SCIENCE
ROCHESTER INSTITUTE OF TECHNOLOGY
ROCHESTER
NY 14623
(716) 464-2995

J. L. POSDAMER
SCHOOL OF COMPo AND INFO. SCI.
313
L INK HALL
SYRACUSE U
SYRACUSE
NY 13210
<31 5) 423-4679

RICHARD CONWAY
DEPT. OF COMPUTER SCIENCE
CORNELL UNIVERSITY
ITHACA
NY 14850
(607) 256-3456

MICHAEL N. CONDICT
JOHN H. WILLIAMS
PATTERN ANALYSIS AND RECOGNITION CORP OCS
ON THE MALL
418
UPSON HALL
ROME
NY 13440
CORNELL U
(315) 336-8400 X36
ITHACA
NY 14850
(607) 256-5033

'J

en

MIKE LEMON
782
WEBSTER HALL
4415 FIFTH AVENUE
PITTSBURGH
PA 15213
(4 i 2) 624-6454

S. L. GULDEN
DEPT. OF MATH
LEHIGH UNIVERSITY
BETHLEHEM
PA 18015
(215) 691-7000 X341

RICHARD J. CICHELLI
901 WHITTIER DRIVE
ALLENTOWN
PA 18103
(215) 797-9690

C. E. BRIDGE
ENGINEERING DEVELOPMENT LAB
E. I. DU PONT DE NEMOURS AND CO.
101 BEECH STREET
WILMINGTON
DE 19898
(302) 774-1731

GARY LINDSTROM
COMPUTER SC IENCE DEPT.
U OF PITTSBURGH
PITTSBURGH
PA 15260
(412) 624-6455

V. LALITA RAO
506 W. THIRD STREET APT. 4
BETHLEHEr~
PA 18015
(215) 865-6448

CHESTER J. SALWACH
2124 DIAMOND STREET
SELLERSVILLE PA 18960
(215) 723-8301

STEPHEN C. SCHWARM
E.I. DU PONT DE NEMOURS CO.
101 BEECH ST.
WILMINGTON
DE 19898
(302) 774-1669

MARY LOU SOFFA
COMPUTER SCI. DEPT.
335
ALUMNI HALL
UNIVERSITY OF PITTSBURGH
PITTSBURGH
PA 15260
(412) 624-6454

RAMON TAN
P.O. BOX 2
BETHLEHEM
PA 18016
(215) 866-7195

ROBERT KEZELL
UN IVERS ITY COMPUTER ACT IVITY
TEMPLE UNIVERSITY
PHILADELPHIA PA 19122
(215) 787-8527

MIKE FRAME
FIRST DATA CORP.
2011 EYE ST. NW
WASH INGTON
DC 20006
(202) 872-0580

HOWARD E. TOMPKINS
COMPUTER SCIENCE DEPT
INDIANA UNIVERSITY OF PA
INDIANA
PA 15701
(415) 357-2524

STEPHEN TITCOMB
1111 NORTH BLVD.
BETHLEHEM
PA 18017

FRANK RYB ICK I
COMPUTER ACTIVITY
TEMPLE UNIVERSITY
BROAD AND MONTGOMERY
PHILADELPHIA PA 19122

TERRY P. MEDLIN
SCIENTIFIC RESEARCH UNIT - DPSA
NATIONAL INSTITUTE OF DENTAL HEALTH
BETHESDA
MD 20014

0

::z

\

rn
~

,

(/)

rn
-i
-i

rn
::c

::z:
o

<

rn
ATTENTION: RUTH DROZIN
FREAS-ROOKE COMPUTER CENTER
BUCKNELL UNIVERSITY
LEWISBURG
PA 17837
(717) 524-1436

RANCE J. DELONG
MORAVIAN COLLEGE
BETHLEHEM
PA 18018

JOHN T. LYNCH
BURROUGHS CORP.
P.O. BOX 517
PAOLI
PA 19301

WAYNE RASBAND
BLDG 36 ROOM 2A-03
NATIONAL INSTITUTES OF HEALTH
BETHESDA
MD 20014
(301) 496-4957

DANIEL C. HYDE
COMPUTER SCIENCE PROGRAM
BUCKNELL UNIVERSITY
LEWISBURG
PA 17837
(717) 524-1392

MAR lLYN HOFFMAN
531 W. UNION BLVD.
BETHLEHEM
PA 18018
(215) 865-6937

E. L. ROWE
BURROUGHS CORP.
BOX 517
PAOLI
PA 19301
(215) 648-2218

DAVID A. GOMBERG
DEPT. OF MATH. STAT. AND COMPo SCI.
AMERICAN UNIVERSITY
MASSACHUSETTS & NEBRASKA AVES.
WASHINGTON
DC 20016
(202) 686-2393

JOHN W. ADAMS
DEPT. OF I. E.
19
PACKARD LAB
LEHIGH UNIV.
BETHLEHEM
PA 18015.

JOHN A. WEAVER
2112 PENNSYLVANIA AVE. F-6
BETHLEHEM
PA 18018
(215) 867-1085

JOHN D. EISENBERG
COMPUTING CENTRE
SMITH HALL
U OF DELAWARE
NEWARK
DE 19711
(302) 738-8441 X57 (OFFICE)
(302) 453-9059 (HOME)

ARTHUR A. BROWN
1101 NEW HAMPSHIRE AVE. NW APT.l002
WASHINGTON
DC 20037
(202) 785-0716

DAVE ENGLANDER
302 SUMMIT STREET
BETHLEHEM
PA 18015
(215) 865-9027

JOSEPH A. MEZZAR08A
BOX 164
E. GREENVILLE PA 18041
(215) 691-7000 (OFFICE)
(215) 679-9900 (HOME)

WILLIAM Q. GRAHAM
COMPUTING CENTER
U. OF DELAWARE
13 SMI TH HALL
NEWARK
DE 19711
(302) 738-8441

PETER A. RIGSBEE
CODE 5494
NAVAL RESEARCH LABORATORY
WASHINGTON
DC 20375
(202) 767-3181

::s:
t:x::1

rn
::c

GREGORY J. WI NTERHALTER
DIGITAL COMMUNICATIONS
135 TECHNOLOGY PARK
NORCROSS
GA 30092
(404) 448-1400

ATT:,: 0 IRECTOR
NORTHEAST REGIONAL DATA CENTER
253
SSRB
U OF FLORIDA
GAINESVILLE
FL 32611
(904) 392-2061

ATTN: J. F. MCINTYRE - LIBRARIAN
COMPUTING CENTER
GILMER HALL
U OF 'II RG INIA
CHARLOTTESVIL VA 22903
(804) 924-3731

ATTENTION: JERRY W. SEGERS
OFF ICE OF COt~PUT ING SERV ICES
GEORGIA INSTITUTE OF TECHNOLOGY
ATLANTA
GA 30332
(404) 894-4676

ATTN: LIBRARIAN
CIRCA
411
WElL
U OF FLORIDA
GAINESVILLE
FL 32611
(904) 392-0907

BEN SHNEIDERMAN
DEPT. OF INFO. SYS. MGMT.
U OF MARYLAND
COLLEGE PARK MD 20742

STEPHEN J. HARTLEY
113 FERNCLIFF DR.
WILLIAMSBURG VA 23185
(804) 229-0337 (HOME)
(804) 827-2897 (WORK)

GERALD N. CEDERQUIST
ELECTRONICS RESEARCH BLDG
EES STL/ASD
GEORGIA INSTITUTE OF TECHNOLOGY
ATLANTA
GA 30332
(404) 894-3417

FRED L. SCOTT
BROWARD COI~MUN ITY COLLEGE
3501 DAVIE ROAD
FT. LAUDERDAL FL 33314
(305) 581-8700

JACOB C. Y. WU
SYSTEM SCIENCES DIVISION
COMPUTER SCIENCES CORPORATION
8728 COLESVILLE ROAD
SILVER SPRING MD 20910
(301) 589-1545 X276

ANN D. DAVIES
UNIVERSITY COMPUTER CENTER
VI RG INIA COMMOIJWEALTH UN IVERS ITY
1015 FLOYD AVE.
RICHMOND
VA 23284'
(804) 770-6339

PHILLIP H. ENSLOW JR.
SCHOOL OF INFO. AND COMPo SCI.
GEORGIA TECH
ATLANTA
GA 30332
(404) 894-3152

DONALD B. CROUCH
DEPT.OF COMPUTER SCIENCE
U. OF ALABAMA
P.O. BOX 6316
UNIVERSITY
AL 35486
(205) 348-6363

CAROL A. OGDIN
THOMAS A. KEENAN
DIVISION OF MATHEMATICAL AND COMPUTER SOFTWARE TECHNIQUE INC.
100 POMMANDER WALK
I0:
(/)

r
rn
-l
-l

rn
;;:0

o

-<

rn
PHILIP N. BERGESTESSER
128 JACKSON AVE.
MADISON
AL 35758
(205) 837-2400

RA INER F. MCCOWN
MCCOWN COMPUTER SERVICES
9537 LONG LOOK LANE
COLUMBIA
MD 21045

DAVID A. HOUGH
529 HELM DRIVE
NEWPORT NEWS VA 23602
(804) 874";3387

JAMES N. FARMER
OFFICE OF COMPUTING SERVICES
GEORGIA TECH
225 NORTH AVE. NW
ATLANTA
GA 30332
(404) 894-4660

JOE C. ROBERTS
613 MARKET STREET
POCOMOKE CITY MD 21851
(804) 824-3411 X641

J. C. KNIGHT
LANGLEY RESEARCH CENTER
MIS 125A
NASA
HAMPTON
VA 23665

ATTENTION: DAVID MADISON
JOHN J. GODA JR.
SCHOOL OF INFORMATION AND COMPUTER SCI ADVANCED SOFTWARE TECHNOLOGY DEPT.
GEORGIA TECH
TEXAS INSTRUMENTS INC.
ATLANTA
GA 30332
304 \~YNN DR IVE
(404) 894-3131
HUNTSVILLE
AL 35806
(205) 837-7510

ANDREW S. PUCHRIK
11623 CHARTER OAKS #202
RESTON
VA 22090

FRED W. POWELL
COMPUTER CENTER
MARY BALDWIN COLLEGE
STAUNTON
V,~ 24401
(703) 885-0811

JOHN P. WEST
OFFICE OF COMPUTING SERVICES
GEORGIA TECH
225 NORTH AVE. N.W.
ATLANTA
GA 30332
(404) 894-4676

SAMUEL T. BAKER
1310 STONEWALL BLVD.
MURFREESBORO TN 37130
(615) 896-3362 (HOME)
(615) 741-3531 (OFFICE)

FRANK BREWSTER
4701 KENMORE AVE #1009
ALEXANDRIA
VA 22304
(703) 370-6645

STEVEN M. BELLOVIN
DEPT. OF COMP. SC I .
U OF NORTH CAROLINA
CHAPEL HILL
NC 27514
(919) 933-5698

T. P. BAKER

ATTENTION: GORDON R. SHERMAN
COMPUTER CENTER
STOKEL Y ~!3MT. CENTER
200
U OF TENNESSEE
TN 37916
KNOXVILLE

DEPT. OF }·1ATH
225
LOVE BUILDING
FLOR IDA STATE U
FL 32304
TALLAHASSEE
(904) 644-2580

'"0

J>
Cl

rn
I-'

\Jl

CHARLES PFLEEGER
COI.f'. SC I. DEPT.
U OF TENNESSEE
KNOXVILLE
TN 37916
(615) 974-5067

E. C. ZIMMERMAN
COMPUTER CENTER
THE COLLEGE OF WOOSTER
WOOSTER
OH 44691
(216) 264-1234 X304

DAVID S. WISE
101
LINDLEY HALL
INDIANA U
GLOOMI NGTOI~
IN ;'7401
(812) 337-4866

RONALD G. MOSIER
17596 WILDEMERE
DETROIT
MI 48221
(313) 956-2417

ATTN: DEPT. OF COMPUTER SC IENCE
U OF MISSISSIPPI
UNIVERSITY
MS 38677

PATRICIA VAN DERZEE
PROCESS CONTROLS DIVISION
CINCINNATI MILACRON INC.
LEBANON
OH 45036
(513) 494-5320

STEPHEN W. YOUNG
WRUBEL COMPUTER CENTER
HPER BUILDING
INDIANA UNIVERSITY
BLOOMINGTON
IN 47401
(812) 337-1911

R. NEIL FAIMAN JR.
8235 APPOLI NE
DETROIT
MI 48228

:z
rn
::;:
(/")

r
rn
-i
-i

rn
\

GAY THOMAS
COMPUTER SCIENCE DEPT.
DRAWER CC
MISS. STATE MS 39762
(601) 325-2942

ROBERT J. SNYDER
GR.FL. UNION BUILDING DATA CENTER
INDIANA U - PURDUE U AT INDIANAPOLIS
1100 WEST MICHIGAN STREET
INDIANAPOLIS IN 46202

JAMES R. MILLER
425-21 SOUTH RIVER ROAD
W. LAFAYETTE IN 47906
(317) 494-8232 (OFFICE)

MARK HERSEY
323 VILLAGE DRIVE APT. 534
EAST LANSING MI 48823
(517) 351-5703 (HOME)
(517) 355-1764 (OFFICE)

LAVINE THRAILKILL
COMPUTING CENTER
U OF KENTUCKY
LEXINGTON
KY 40506
(606) 258-2916

ATTN: DOCUMENTS ROOM LIBRARIAN
COMPUT I NG CENTER
U OF NOTRE DAME
NOTRE DAME
IN 46637
(219) 283-7784

EDWARD F, GEHR INGER
DEPT. OF COMPUTER SCIENCE
MATH SCIENCES BUILDING
PURDUE UNIVERSITY
LAFAYETTE
IN 47907

THOMAS C. SOCOLOFSKY
SYSTEMS RESEARCH INC
241 E. SAGINAW
EAST LANSING MI 48823
(517) 351-2530 (OFFICE)
(517) 351~2530 (HOME)

;:0

:z
C>

-<

rn

ROY F. REEVES
1640 SUSSEX COURT
COLUMBUS
OH 43220
(614) 422-4843

DOUGLAS H. QUEBBEMAN
2235 LOMBARDY DRIVE
JEFFERSONVILL IN 47130
(812) 945-2731

JOSEPH H. FASEL I II
COMPUTER SCIENCES
442
MATH SCIENCES BUILDING
PURDUE UNIVERSITY
W. LAFAYETTE IN 47907
(317) 494-8566

JOHN B. EULENBERG
COMPo SCI. DEPT.
MICHIGAN STATE U
EAST LANSING MI 48824
(517l 353-0831

R. B. LAKE
BIOMETRY
WEARN BUILOING
UNIVERSITY HOSPITALS
CLEVELAND
OH 44106
(216) 791-7300

GEORGE COHN I I I
316 N. WASHINGTON
BLOOMINGTON
IN 47401
(812) 337-9255
(812) 337-1911

ALAN A. KORTESOJA
701 W. DAVIS
ANN ARBOR
MI 48103
(313) 995-6124
(313) 995-6000

STEVEN L. HUYSER
COMPUTER LABORATORY
MICHIGAN STATE U
EAST LANSING MI 48824
(517l 353-1800

T. S. HEINES
DEPT. OF COMPUTER SCIENCE
CLEVELAND STATE UNIVERSITY
CLEVELAND
OH 44115
(216) 687-4762
(216) 687-4760

HAL STEIN
BOX 102 WRIGHT QUAD
INDIANA UNIVERSITY
BLOOMINGTON
IN 47401
(812) 337-7081

l. RICHARD LEWI S
5806 COOLIDGE ROAD
OEARBORN
MI 48127
(313) 274-6871

MARK RIORDAN
USER SERVICES
COMPUTER LABORATORY
MICHIGAN STATE UNIVERSITY
EAST LANSING MI 48824
(517) 353-1800

ROBERT L. BRIECHLE
THE COMPUTER CENTER
U OF AKRON
302 E. BUCHTEL AVE.
AKRON
OH 44325
(216) 375-7172

ALFRED I. TOWELL
WRUBEL COMPUTER CENTER
INDIANA UNIVERSITY
BLOOMINGTON
IN 47401
(812) 337-1911

WI Lli AM GROSKY
MATH DEPT - COMPo SCI. SECTION
WAYNE STATE UNIVERSITY
DETROIT
MI 48202

H. G. HEDGES
DEPT. OF COMPo SCI.
MICHIGAN STATE U
E. LANSING
MI 48824
(517) 353-6484

3:
tx:I

rn
;:0

GORDON A. STEG INK
COMPUTER CENTER
325
MANITOU HALL
GRAND VALLEY STATE COLLEGE
ALLEND~H
~il 49401
(616) 895-6611 X571
GEORGE O. STRAWN
DEPT. OF COMPUTER SCIENCE
IOWA STATE U
AMES
I.A 50011
(515) 294-2259

ATTfj: SER IALS DEPT.
UNIVERSITY LIBRARIES
UNIVERSITY OF IOWA
IOWA CITY
IA 52242

ATTN: UCC LIBRARIAN
UNIVERSITY COMPUTER CENTER
LCM
UNIVERSITY OF IOWA
IOWA CITY
IA 52242
(319) 353-3170

CHARLES N. FISCHER
MACC
U OF WISCONSIN
1210 WEST DAYTON ST.
MADISON
WI 53706
(608) 262-7870
FRANK H. HORN
ACADEI~IC CO~iPUTER

CENTER

U OF WISCONSIN
1210 WEST DAYTON STREET
MADISON
WI 53706
(608) 262-9841
ED GLASER

COMPUTING SERVICES
U OF WISCONSIN - GREEN BAY
GREEN BAY
WI 54302
(414) 465-2309

DAVID A. NUESSE
DEPARTMENT OF COMPUTER SCIENCE
U OF WISCONSIN - EAU CLAIRE
EAU CLAIRE
WI 54701
(715) 836-2526

GLENN MI LLER
2317 N. HENRY ST.
N. ST. PAUL
MN 55109
(612) 777-2483

MARK RUST.A.D
525 HARRIET AVE #213
ST. PAUL
MN 55112

PAUL CHRISTOPHERSON
M.S. ~INll-1611
HONEYWELL INC.
600 SECOND STREET N.
HOPKINS
MN 55343
(612) 542-6438
BILODE AU
ENGINEERING SYSTEMS 4TH FLOOR
NORTHERN STATES POWER
414 NICOLLET t~ALL
MINNEAPOLIS
MN 55401
(612) 330-6749
(612) 330-5899

I~ARK

ROBERT D. VAVRA
741 TERRACE DRIVE
ROSEVILLE
MN 55113
(612) 483-6123

CHRIS EASTLUND
ENGINEERING SYSTEMS 4TH FLOOR
NORTHERN STATES POWER
414 NICOLLET MALL
MINNEAPOLIS
MN 55401
(612) 330-6749
(612) 330-5899

STEVE M. WEINGART
MS 4953
SPERRY-UNIVAC
2276 HIGHCREST DRIVE
ROSEVILLE
MN 55113

JOHN URBAN SK I
1929 FREMONT AVE. S. APT. 23
MINNEAPOLIS
MN 55403
(612) 377-3198

:z
rn
~
(/)

r
rn
-I
-I

rn

=

:z

o
<:

m

W. A: HINTON
S.AN W 570 C
U OF WISCONSIN - MILWAUKEE
P.O. BOX 413
MILWAUKEE
WI 53201
(414) 963-4005

RUDOLPH C. POLENZ
PETER H. ZECHMEISTER
INFORMATION SYSTEMS AND COMPUTING SERV 926 W. MONTANA AVE.
ST. PAUL
MI, 55117
U OF WISCONSIN - EAU CLAIRE
EAU CLAIRE
WI 54701
(612) 489-5166
(715) 836-4428

SCOTT BERTILSON
2929 42ND AVE. S.
MINNEAPOLIS
MN 55406
(612) 729-0059

BROOKS DAVID SMITH
4473 N. NEWHALL ST.
SHOREWOOD
WI 53211
(414) 332-6646

BKUCE A. PUMPLIN
DEPT OF COMPUTER SCIENCE
U OF WISCONSIN - EAU CLAIRE
EAU CLAIRE
WI 54701
(715) 836-2315

ATTENTION: ROBERT E. NOVAK
DSPL DEVELOPMENT GROUP
SPERRY UN I VAC
UNIVAC PARK I P.O. BOX 3525
ST. PAUL
MN 55165
(612) 456-5551

iNDULIS VALTERS
2810 E 22ND AVE.
I~I NNEAPOL I S
MN 55406
(612) 341-4430

HERMAN BERG
108 E. DAYTON STREET
MADISON
WI 53703

CARL HENRY
COI~PUTER CENTER
CARLETON COLLEGE
NORTHFIELD
MN 55057
(507) 645-4431 X504

LEO J. SLECHTA
DSD
SPERRY UNIVAC
BOX 3525 MS U1U25
ST. PAUL
MN 55165
(612) 456-2743

DON HAMNES
4215 PLEASANT AVE. SO.
MINNEAPOLIS
MN 55409
(612) 823-3030

ATTN: FRIEDA S. COHEN
ACADEMIC COMPUTING CENTER
U OF WISCONSIN
1210 W. DAYTON ST.
MADISON
WI 53706

TIMOTHY W. HOEL
ACADEMIC COMPUTER CENTER
ST. OLAF COLLEGE
NORTHFIELD
MN 55057
( 507) 663-3096

OAVID HELFINSTINE
1136 5TH AVENUE SOUTH
ANOKA
MN 55303
(612) 421-8964

JOHN FUNG
425 13TH AVE S.E. #406
~INNEAPOLIS
MN 55414
(612) 376-5464 (OFFICE)
(612) 378-0427 (HOME)

3
t:d

rn

=

WALT PERKO
727 15TH AVE. S.E.
MINNEAPOLIS
MN 55414
(612) 331-6984

TIM BONHAM
0605/1630 S. 6TH ST.
MINNEAPOLIS MN 55454
(612) 339-4405

JOHN T. EASTON
SSRFC
25G
BLEGEN HALL
U OF MINNESOTA
WEST BANK
MINNEAPOLIS MN 55455
(612) 373-9917

TIMOTHY J. HOFFMANN
364
FRONTIER HALL
U OF MINNESOTA
EAST BANK
MINNEAPOLIS MN 55455
(612) 373-6957

GEOFF WATTLES
407 ERIE STREET
MINNEAPOLIS MN 55414
(612) 331-7087

R. K. NORDIN
1615 SOUTH 4TH ST. APT.M3607
MINNEAPOLIS MN 55454
(612) 339-5232 (HOME)
(612) 482-3751 (OFFICE)

LINCOLN FETCHER
UNIVERSITY COMPUTER CENTER
227
EXPERIMENTAL ENGINEERING
UNIVERSITY OF MINNESOTA
MINNEAPOLIS MN 55455
(612) 376-1637

GEORGE D. JELATIS
BOX 15 MAYO
U OF MINNESOTA
EAST BANK
MINNEAPOLIS MN 55455
(612) 373-8941

KEITH HAUER-LOWE
4819 COLUMBUS AVE. SO.
MINNEAPOLIS
MN 55417
(612) 633-6170 X3362 (WORK)
(612) 824-8026 (HOME)

KEVIN FJELSTEO
ATTENTION: PAUL C. SMITH
CONSULTING GROUP ON INSTRUCTIONAL DESI UNIVERSITY COMPUTER CENTER
227
EXP ENGR
205
ELLIOTT HALL
U OF MINNESOTA
U OF MINNESOTA
EAST BANK
EAST BANK
MINNEAPOLIS MN 55455
MINNEAPOLIS MN 55455
(612) 373-4181
(612) 373-5352

DAN LALI BERTE
UNIVERSITY ,COMPUTER CENTER
227
EXP. ENGR.
U OF MINNESOTA
EAST BANK
MINNEAPOLIS MN 55455
(612) 373-4181

JONATHON R. GROSS
DIGITAL EQUIPMENT CORP.
8030 CEDAR AVENUE SOUTH
MINNEAPOLIS MN 55420
(612) 854-6562

ATTENTION: STEVE REISMAN
SCH. OF DENTISTRY/CLINICAL SYS. DIV.
8-440 HEALTH SCIENCE UNIT A
U OF MINNESOTA
EAST BANK
MINNEAPOLIS MN 55455
(612) 376-4131

K. FRANKOWSK I
COMPUTER SCIENCE DEPARTMENT
110H LIND HALL
U OF MINNESOTA
EAST BANK
r~1 NNEAPOLI S
MN 55455
(612) 373-7591'

LAWRENCE A. LIDDIARD
UNIVERSITY COMPUTER CENTER
227
EXP. ENG. BLDG.
U OF MINNESOTA
EAST BANK
MI NNEAPOL'I S MN 55455
(612) 373-5239

ROBERT A. STRYK
5441 HALIFAX LANE
EDINA
MN 55424
(612) 920-5434 (HOME)
(612) 887-4356 (OFFICE)

ATTN: COMPUTER SCIENCE DEPT.
114
II NO HALL
U OF MINNESOTA
EAST BANK
MINNEAPOLIS MN 55455
(612) 373-0132

KRISTINA GREACEN
C.SCI. DEPT.
114
LIND HALL
U OF MINNESOTA
EAST BANK
MINNEAPOLIS MN 55455

DENNIS R. LIENKE
UNIVERSITY COMPUTER CENTER
214
EXP. ENGR.
U OF MINNESOTA
EAST BANK
MINNEAPOLIS MN 55455
(612) 373-1572

RON THOMAS
7725 WASHINGTON AVE. S.
MINNEAPOLIS MN 55425
(612) 941-6500

ATTN: REFERENCE ROOM
UNIVERSITY COMPUTER CENTER
227
EXP ENGR
U OF MINNESOTA
EAST BANK
MINNEAPOLIS MN 55455
(612) 373-7744

JOEL M. HALPERN
UNIVERSITY COMPUTER CENTER
227
EXP. ENGR.
U OF MINNESOTA
EAST BANK
MINNEAPOLIS MN 55455
(612) 373-4181

SHIHTA LIN
UNIVERSITY COMPUTER CENTER
227
EXP ENGR
U OF MINNESOTA
EAST BANK
MINNEAPOLIS MN 55455
(612) 373-4886

HUGO MEISSER
3021 WISCONSIN AVE. N.
MINNEAPOLIS MN 55427
(612) 544-2349

KEN BORGENDALE
C.SCI. DEPT.
114
LIND HALL
U OF MINNESOTA
EAST BANK
MINNEAPOLIS MN 55455
(612) 824-3389

BRIAN HANSON
UNiVERSITY COMPUTER CENTER
227
EXP. ENGR.
U OF MINNESOTA
EAST BANK
MINNEAPOLIS MN 55455
(612) 376-5262 (OFFICE)

JOHN E. LIND
139
TERRITORIAL HALL
UNIVERSITY OF MINNESOTA
EAST BANK
MINNEAPOLIS MN 55455

RANDALL W. WARREN
HQS06B
CONTROL DATA CORPORATION
P.O. BOX 0
MINNEAPOLIS MN 55440

JEFFREY J. DRUMMOND
UNIVERSITY COMPUTER CENTER
LAUDERDALE
U OF MINNESOTA
MINNEAPOLIS MN 55455
(612) 373-4573

THEA D. HOOGE
UNIVERSITY COMPUTER CENTER
227
EXP. ENGR.
U OF MINNESOTA
EAST BANK
MINNEAPOLIS MN 55455
(612) 373-4599

MICHAEL ROBERT MEISSNER
1541
PIONEER HALL
U OF MINNESOTA
EAST BANK
MINNEAPOLIS MN 55455

,

:z

o
-<
rn
:3:
t:x:I

rn
;;0

.....
00

DAVID C. MESSER
UN Ivms ITY COI~PUTER CENTER
227
EXPERIMENTAL ENGINEERING
UNIVERSITY OF :~INNESOTA
EAST BANK
I,ll NNE.~POL IS MN 55455
(612) 376-2787

G. MICHAEL SCHNEIDER
C.SCI. DEPT.
114
LIND HALL
U OF MI NNESOTA
EAST BANK
MINNEAPOLIS
MN 55455
(612) 373-7582

L. W. YOUNGREN
1505 N.W. 41ST Sf. APT. 18F
ROCHESiER
MN 55901
(507l 285-9696

ALBERT STE INER
VOGELBACK COMPUTING CENTER
NORTHWESTERN U
2129 SHERIDAN ROAD
EVANSTON
IL 60201
(312) 492-3682

ANDY MICKEL
UN IVERS I TY COf~PUTER CENTER
227
EXP. ENGR.
U OF t~INNESOTA
EAST BANK
MINNEAPOLIS
MN 55455
(612) 376-7290

JOHN P. STRAIT
UNIVERSITY COMPUTER CENTER
227
EXP. ENGR.
U OF MINNESOTA
EAST BANK
MINNEAPOLIS
MN 55455
(612) 376-7290

JAMES F. MARTINSON
1210 WILLMAR AVE
WILLMAR
MN 56201
(612) 796-2342

BRIT J. BARTTER
850A FOREST AVENUE
EVANSTON
IL 60202

JAMES F. MINER
SSRFC
25
BLEGEN HALL
U OF MINNESOTA
WEST BANK
MINNEAPOLIS
MN 55455
(612) 373-9916

BILL WOOD
C.SCI. DEPT.
114
LIND HALL
U OF MINNESOTA
EAST BANK
MINNEAPOLIS
MN 55455
(612) 373-7746

R. WARREN JOHNSON
DEPT. OF MATH AND COMPo SCI.
ST. CLOUD STATE U
ST. CLOUD
MN 56301
(612) 255-2147

JONATHAN SACHS
TRANS UNION SYSTEMS CORPORATION
111 WEST JACKSON BLVD
CHICAGO
IL 60604
(312) 431-3330

JOHN NAUMAN
901
MIDDLEBROOK HALL
U OF MINNESOTA
WEST BANK
141 NNEAPOLI S MN 55455
(612) 376-6596

ATTN: SSRFC LIBRARY
SSRFC
25
BLEGEN HALL
U OF MINNESOTA
WEST BANK
MINNEPOLIS
MN 55455
(612) 373-5599

HAROLD DE VORE
BOX 7161 UNIVERSITY STATION
GRAND FORKS
NO 58202
(701) 746-6977

DAVID E. CARLTON
DEPT. OF INFO. SCI.
NORTHEASTERN ILLINOIS U
5500 N. ST. LOUIS AVE.
CHICAGO
IL 60625

DAVID PERLMAN
COMPUTER SCIENCE DEPARTMENT
114
LIND HALL
UNIVERSITY OF I~INNESOTA
EAST BANK
MINNEAPOLIS
MN 55455
(612) 373-7581

MITCHELL R. JOELSON
SSRFC
25
BLEGEN HALL
U OF MINNESOTA
WEST BANK
f~PLS.
MN 55455
(612) 781-7323 (HOME)

R. I. JOHNSON
COMP. SC I. DEPT.
U OF NORTH DAKOTA
BOX 181 UNIVERSITY STATION
GRAND FORKS
NO 58202
(701) 777-4107

TED FISHMAN
6049 KIMBALL
CHICAGO

HERBERT RUBENSTE II~
UNIVERSITY COMPUTER CENTER
227
EXP. ENGR.
U OF MINNESOTA
EAST BANK
MINNEAPOLIS
MN 55455
(612) 373-4181

DAV ID SARANEN
117 7TH ST. SO.
VIRGINIA
MN 55792
(218) 741-1378

GARY J. BOOS
517 N. 7TH STREET
BISMARK
ND 58501
(701) 223-0441 (WORK)

ATTN: CONSULTING OFFICE
COMPUTING SERVICES OFFICE
116
DIGITAL COMPUTER LAB
U OF ILLINOIS
URBANA
I L 61801
(217l 333-6133

TII-1OTHY J SALO
UNIVERSITY COMPUTER CENTER
LAUDERDALE
U OF MINNESOTA
MINNEAPOLIS
MN 55455
(612) 376-5607

ATTENTION: DAN BURROWS
UMO COMPUTER CENTER
178
M.W.ALWORTH HALL
U OF MINNESOTA
DULUTH
MN 55812
DULUTH

ATTENTION: KYU LEE
DEPARTMENT OF COMPUTER SCIENCE
UNIVERSITY OF MONTANA
MISSOULA
MT 59801
(406) 243-2883

RICHARD BALOCCA
1146 DIGITAL COMPUTER LAB
U OF ILLINOIS
URBANA
I L 61801
(217l 344-5284

BOB SCARLETT
PHYS ICS DEPT.
148
PHYSICS
U OF MINNESOTA
EAST BANK
MiNNEAPOLIS
MN 55455
(612) 373-0243

MARK LUKER
f~A TH SC IENCES DEPT.
U OF MINNESOTA
DULUTH
MN 55812
DULUTH
(218) 726-8240

MARK S. NIEMCZYK
HEWITT ASSOCIATES
102 WI LMOT ROAD
DEERFIELD
IL 60015
(312) 945-8000

ROGER GULBRANSON
PHYSICS DEPT.
U OF ILLINOIS
URBANA
IL 61801
(217) 367-8470 (HOME)
(217) 333-3191 (OFFICE)

rn

o

-<

rn

:3

to

IL 60659

rn
::0

\

CHARLES rlEDR ICK
183
COMMERCE WEST
U OF ILLINOIS
URBANA
IL 61801
(217) 333-4515
(217) 356-8425

OEN,~

ISS. ANDREWS
INFORMAT: ON PROCESS I NG
SOUTHERN ILLINOIS UNIVERSITY
CARBONDALE
IL 62901

D. B. KILLEEN
Cor·1PUTER LAB
RICHARDSON OLDG.
TULANE UNIVERSITY
NEW ORLEANS LA 70118

JOHN NUNNALL Y
HARDING COLLEGE
BOX 744
SEARCY
AR 72143
(501) 268-6161 X257

M. D. ~IICKUNAS
297
DCL
U OF ILLINOIS
URBANA
IL 61801
(217) 333-6351

LARRY D. LANDIS
UNITED COMPUTING SYSTEMS
2525 ItASH INGTON
KANSAS CITY MO 64108
(816) 942-6063

FREDERICK A. HOSCH
COMPUTER RESEARC>i CENTER
U OF NEW ORLEANS
NEW ORLEANS LA 70122

RICHARD V. ANDREE
MATH DEPT.
U OF OKLAHOMA
NORMAN
OK 73019
(405) 325-3410

CARLTON MILLS
MILLS INTERNATIONAL
203 NORTH GREGORY
URBANA
IL 61801
(217) 328-2436 (HOME)
(217) 333-6971

JEFFERY M. RAZAFSKY
UNITED COMPUTING SYSTEMS INC.
500 W. 26TH STREET
KANSAS CITY MO 64108
(816) 221-9700

WARREN JOHNSON
U OF SOUTHWESTERN LOUISIANA
BOX 4-2770 USL STATION
LAFAYETTE
LA 70504
(318) 234-7349

RALPH HOWENST INE
2313 CRESTMONT #208
NORMAN
OK 73069

ATTN: RECEIVING CLERK
CERL - SOC
U.S. ARMY
P.O. BOX 4005
CHAMPAIGN
IL 61820
(217) 352-6511

HOWARD D. PYRON
MATH - C.SCI.
U OF MISSOURI - ROLLA
ROLLA
t40 65401
(314) 341-4491

ED KATZ
COMPUTER SCIENCE DEPT.
U OF SOUTHWESTERN LOUISIANA
BOX 4-4330 USL STATION
LAFAYETTE
LA 70504

STEPHEN A. PITTS
305 EAST JARMAN DRIVE
MIDWEST CITY OK 73110
(405) 732-4060

FRED P. BAKER
302 E. GREGORY
CHAMPAIGN
IL 61820
(217) 344-7511

STEVEN S. MUCHNICK
DEPARTMENT OF COMPUTER SCIENCE
U OF KANSAS
LAWRENCE
KS 66045

STEVE LANDRY
COMPUTER CENTER
U OF SOUTHWESTERN LOUISIANA
P.O. BOX 4-2770
LAFAYETTE
LA 70504
(318) 234-7349

GILBERT J. HANSEN
3104 BONNIEBROOK DRIVE
PLANO
TX 75075
(214) 423-7837

AVRUM ITZKOw ITZ
505 E. CLARK APT. 22
CHAMPAIGN
IL 61820
(217) 359-9644 (HOME)
(217) 352-6511 (WORK)

LYNNE J. BALDWIN
DEPT. OF MATH/COMP. SCI.
U OF NEBRASKA
BOX 688
OMAHA
NE 68101
(402) 554-2836

DAV ID LANDSKOV
U OF SOUTHWESTERN LOUISIANA
USL BOX 4-4154
LAFAYETTE
LA 70504
(318) 234-7640

BR IAN W. JOHNSON
1525 WESTLAKE
PLANO
TX 75075
(214) 690-2885

DANIEL M. O'BRIEN
601 E. CLARK #10
CHAMPAIGN
IL 61820
(217) 356-2718

TERRY E. WEYMOUTH
CIO J. W. WEYMOUTH
6110 MEADOWBROOK LANE
LINCOLN
NE 68510

A. I. STOCKS
P.O. BOX 4-1039
USL STATION
LAFAYETTE
LA 70504
(318) 233-3850 X538

DENNIS J. FRAILEY
COMP. SCI. DEPT.
SOUTHERN METHODIST UNIY.
DALLAS
TX 75222

JACK THOMPSON
MID. ILLINOIS COMPUTER CO-OP
COTTONWOOD ROAD
EDWARDSVILLE IL 62025
(618) 288-7268

SHARAD C. SETH
DEPT. OF COMPo SCI.
U OF NEBRASKA
LINCOLN
NE 68588
(402) 472-3488

TERRY M. WALKER
COMPUTER SCIENCE DEPT.
U OF SOUTHWESTERN LOU I SIAt-IA
P.O. BOX 4-4330
LAFAYETTE
LA 70504
(318) 234-7640

W. J. MEYERS
4-214S THE TIMBERS
13447 N. CENTRAL EXPR.
DALLAS
TX 75243
(214) 231-4869

Cl

-<

rn

N
Cl

GARY CEDEROU 1ST
SOUTHERN METHODIST UNIV.
BOX 2112
DALLAS
TX 75275

RICHARD HUBER
DEPT. OF INDUSTRIAL ENGINEERING
TEXAS MM Ut'j IVERS ITY
COLL. STATION TX 77843
(713) 845-5531 X2~6

WILLIAM L. COHAGAN
SU ITE 211
S/B/P & C ASSOCIATES
8705 SHOAL CREEK BLVD.
AUSTIN
TX 78758
(512) 458-2276

WILLIAM M. WAITE
ELECTRICAL ENGINEERING DEPT.
SOFTWARE ENGINEERING GROUP
UNIVERSITY OF COLORADO
BOULDER
CO 80302

JANET TAYLOR
USER SERVICES
COMPUTING LABORATORY
SOUTHERN METHODIST UNIVERSITY
DALLAS
TX 75275
(214) 692-2900

MIKE GREEN
DATAPOINT CORPORATION
9725 DATAPOINT DRIVE
SAN ANTONIO
TX 78284
(512) 690-7345

HARRY P. HAIDUK
DEPT. OF COMP. INFO. SYSTH1S
WEST TEXAS STATE U
CANYON
TX 79015
(806) 656-3966

LLOYD D. FOSDICK
DEPARTMENT OF COI~UTER SC IENCE
ECOT 7-7
U OF COLORADO
BOULDER
CO 80309
(303) 492-7514

JESSE D. MIXON
DEPT. OF COMPUTER SCIENCE
STEPHEN F. AUSTIN STATE U
P.O. BOX 6167 SFA STATION
NACOGDOCHES
TX 75961
(713) 569-2508

WILLETT KEMPTON
2512 SAN GABRIEL ST.
AUSTIN
TX 78705

cm~PUTER

MAURICE BALLEW
SERV ICES
TEXAS TECH UNIVERSITY
BOX 4519
LUBBOCK
TX 79409
(806) 742-2900

GEORGE H. RICHMOND
COMPUTING CENTER
UNIVERSITY OF COLORADO
3645 MARINE STREET
BOULDER
CO 80309
(303) 492-6934

GINGER KELLY
ICSA
RICE UNIVERSITY
HOUSTON
TX 77001
(713) 527- ....

ATTN: DOROTHY SMITH- REFERENCE LI BRAR
COMPUTATION CENTER
U OF TEXAS AUSTIN
TX 78712
AUSTIN
(512) 471-3242

LEONARD H. WE INER
DEPT. OF I~ATH AND COMP. SCI.
TEXAS TECH. U
P.O. BOX 4319
LUBBOCK
TX 79409
(806) 742-2571

ATTN: USER SERVICES GROUP
UNIVERSITY COMPUTER CENTER
COLORADO STATE U
FORT COLLINS CO 80523
(303) 491-5133

o

<
m

JOHN EARL CRIDER
7201 BROMPTON ROAD HA114
HOUSTON
TX 77025
(713) 665-3016

WILHELM BURGER
DEPT. OF COMPUTER SCIENCES
328
PAINTER HALL
U OF TEXAS AUSTIN
AUSTIN
TX 78712
(512) 471-4088
(512) 471-7316

D. A. CAUGHFIELD
609 E. N. 21ST
ABILENE
TX 79601
(915) 672-1604

DALE H. GRIT
DEPARTMENT OF COMPUTER SCIENCE
COLORADO STATE U
FT. COLLINS
CO 80523
(303) 491-7033

JAMES A. KENDALL
MHMR/TRI MS
TEXAS MEDICAL CENTER
HOUSTON
TX 77030
(713) 797-1976

WAYNE SEIPEL
COMPUTATION CENTER
U OF TEXAS
AUSTIN
TX 78712

RICHARD TAYLOR
2425 RALE IGH ST.
DENVER
CO 80212
(303) 477-7995

ATTN: B1700 PROTEUS PROJECT
COMPUTER SCIENCE DEPT.
3160
MEB
U OF UTAH
SALT LAKE CIT UT 84112
(801) 581-8224

SCOTT K. WARREN
ROSETTA ALGORITHMS
2414 BRANARD HD
HOUSTON
TX 77098

WALLY WEDEL
COMPUTATION CENTER
U OF TEXAS AUSTIN
TX 78712
AUSTIN
(512) 471-3242

ATTN: LIBRARY
67
DENVER FEDERAL CENTER
BUREAU OF RECLAMATION
DENVER
CO 80225

MARTIN L GRISS
Cor~PUTER SC I ENCE DEPT
U OF UTAH
SALT LAKE CIT UT 84112
(801) 581-6542

RUSSELL W ZEARS
BIOMETRY LAB
449
ADMINISTRATION BLDG R7
UNIVERSITY OF TEXAS MEDICAL BRANCH
GALVESTON
TX 77550
(713) 765-1813

DAVID W. HOGAN
4104 AVENUE F
AUSTIN
TX 78751

HOWARD BUSSEY JR.
M. A. KLEINERT
NATIONAL OCEANIC AND ATMOSPHERIC ADMIN COMP. SC I. DEPT.
BLDG. 1 RM 4557
3160
MERRILL ENG. BLDG.
U.S. DEPARTMENT OF COMMERCE
U OF UTAH
SALT LAKE CIT UT 84112
BOULDER
CO 80302

ED SHARP
COMPUTER CENTER
U OF UTAH
SALT LAKE CIT UT 84112
(8011 581-6802

BILL BUZBEE
LOS ALAMOS SCIENTIFIC LABORATORY
C-DO MS-260
UN IVERS ITY OF CALI FORN IA
P.O. BOX 1663
LOS ALAMOS
NM~87545

ATTN: PROGRAMMING ADVISOR
UNS COMPUTING CENTER
22
WR
U OFNEVAOA
RENO
NV 89507

MICHAEL TEENER
TECHNOLOGY SERVICE CORP.
2811 WILSHIRE BLVD.
SANTA MONICA CA 90403
(213) 829-7411 X244

THEODORE A. NORMAN
COMP. SC I. DEPT.
BRIGHAM YOUNG UNIVERSITY
PROVO
UT 84602
(801) 374-1211 X3027

ROBERT T. JOHNSON
C-l1
MAIL STOP 296
LOS ALAMOS SCIENTIFIC LABORATORY
P.O. BOX 1663
LOS ALAMOS
NM 87545
(505) 667-5014

GARY CARTER
SEISMOLOGY DEPT.
MACKAY SCHOOL OF MINES
U OF NEVADA RENO
RENO
NV 89507

PHYLLIS A. REILLY
19711 GALWAY AVENUE
CARSON
CA 90746
(213) 321-5215

RICHARD OHRAN
ELECTICAL ENGINEERING DEPT
459
ESTB
BRIGHAM YOUNG UNIVERSITY
PROVO
UT 84602
(801) 374-1211 X4012

JOHN MONTAGUE
GROUP Cll
MAIL STOP 296
LOS ALAMOS SCIENTIFIC LABORATORY
LOS ALAMOS
N~' 87545

ATTN: ACADEMIC SERVICES
UNIVERSITY COMPUTER CENTER
U OF SOUTHERN CALIFORNIA
1020 W. JEFFERSON BLVD.
LOS ANGELES CA 90007
(213) 746-2957

PAUL L. MCCULLOUGH
911 GENOA ST.
~ONROVIA
CA 91016
(213) 447-3202

PATRICK PECORARO
UNIVERSITY COMPUTER CENTER
U OF ARIZONA
TUCSON
AZ 85721
(602) 884-2901

JAMES DARL ING
NEW MEXICO TECH
BOX 2139 CAMPUS STATION
SOCORRO
NM 87801
(505) 835-5374

STEVEN BARRYTE
6620 W. 5TH STREET
LOS ANGELES CA 90048
(213) 653-8697

CLARK M. ROBERTS
219 VIOLET AVENUE
MONROVIA
CA 91016
(213) 456-3858 (HOME)
(213) 658~2405 (WORK)

R. W. MILKEY
KITT PEAK NATIONAL OBSERVATORY
P.O. BOX 26732
TUCSON
AZ 85726
(602) 327,..5511

T. A. NARTKER
ERWIN BOOK
NEW MEXICO INSTITUTE OF MINING AND TEC 3169 COLBY AVENUE
SOCORRO
NM 87801
LOS ANGELES CA 90066
(505) 835-5126

TOM SANDERSON
617 NORTH FOURTH
BELEN
NM 87002

J. MACK ADAMS
COMP. SC I. DEPT.
NEW MEXICO STATE U
BOX 3CU
LAS CRUCES
NM 88003
(505) 646-3723

HOWARD H. METCALF
2590 GLEN GREEN #4
HOLLYWOOD
CA 90068

WILLIAM C. PRICE
480 PEMBROOK DRIVE
PASADENA
CA 91107
(213:) 351-6551 X219

NANCY RUIZ
ORG. 5166
SANDIA LABS
ALBUQUERQUE NM 87115
(505) 264-3690

ATTN: USER SERVICES LIBRARIAN
UNIVERSITY COMPUTER CENTER
NEW MEXICO STATE UNIVERSITY
BOX 3AT
LAS CRUCES.
NM 88003
(505) 644-4433

DENNIS HEIMBIGNER
2500 CARNEGIE LANE #B
REDONDO BEACH CA 90278
(213) 374-9936

GERALD BRYAN
SEAVER COMPUTER CENTER
CLAREMONT COLLEGES
CLAREMONT
CA 91711
(714) 626-8511 X3228

HARRY M. MURPHY JR.
AIR FORCE WEAPONS LABORATORY
KIRTLAND AFB NM 87117
(505) 264-9317

JOHN WERTH
DEPT. OF MATH
U OF NEVADA LAS VEGAS
LAS VEGAS
NV 89154
(702) 739-3715

RALPH L. LONDON
INFORMATION SCIENCES INSTITUTE
U OF SOUTHERN·CALIFORNIA
4676 ADMIRALTY WAY
MARINA DEL RA CA 90291

MARK J. KAUFMAN
916 E WASHINGTON APT. lOB
ESCONDIDO
CA 92025
(714) 743-591 t

:z

a
-<
rn

3:
CHARLES L. LAWSON
JET PROPULS ION LABORATORY
t:I:1
MS 125/128
~
CALIFORNIA INSTITUTE OF TECHNOLOGY
4800 OAK GROVE DR.
PASADENA
CA 91103
(213) 354-4321
CTl

N
N

MARK OVERGAARD
APIS DEPT.
C-014
U OF CALIFORNIA - SAN DIEGO
LA JOLLA
CA 92093
(714) 452-2728

ATTENTION: EDWARD E. BALKOVICH
SCIENCE AND TECHNOLOGY DIVISION
GENERAL RESEARCH CORP.
5383 HOLLISTER AVE.
SANTA BARBARA CA 93105
(805) 964-7724

DENN IS GRAHAM
AMD~.HL CORP.
1250 E. ARQUES AVE.
SUNNYVALE
CA 94086
(408) 735-4602

JOHN C. BEATTY
L-73
LAWRENCE LIVERMORE LAB
BOX 808
L I VER~!ORE
cr, 94550
(415) 447-1100 X3114

MICH.~EL S. BALL
CODE 2
NAVAL UNDERSEA CENTER
SAN DIEGO
CA 92132

ROBERT ALAN DOLAI~
SPEECH COMMUNICATIONS RESEARCH LAB
800A MI RAMJIHE DR IVE
SANTA BARBARA CA 93109
(805) 965-3011

M. H. MACDOUGALL
AMDAHL CORP.
1250 EAST ARQUES AVE.
SUNNYVALE
CA 94086
(408) 736-4856

WILLIAM P. TAYLOR
L-315
UNIVERSITY OF CALIFORNIA
P.O. BOX 808
LIVERMORE
CA 94550
(415) 455-6729

ATTN: COMPUTER SC IENCES INST ITUTE
U OF CALIFORNIA
RIVERSIDE
CA 92507

NEIL W. WEBRE
DEPT. OF COMPo SCI. AND STAT.
CALIF. POLY. STATE UNIV.
SAN LUIS 081S CA 93401
(805) 546-2986

GARY W. WINIGER
P.O. BOX 60835
SUNNYVALE
CA 94088
(415) 964-6982

BRYAN L. HIGGINS
SCIENCE APPLICATIONS INC.
8201 CAPWELL DRIVE
OAKLAND
CA 94621
(415) 562-9163

KURT COCKRUM
3398 UTAH
RIVERSIDE

JAMES L. BEUG
DEPT. OF COMPo SCI.
CALIFORNIA POLYTECHNIC STATE U
SAN LUIS OBIS CA 93407
(805) 546-i 255

NIKLAUS WIRTH
XEROX RESEARCH CENTER
3333 COYOTE HILL ROAD
PALO ALTO
CA 94304

JEFFREY BARTH
COMPo SCI. DIVISION
573
EVANS HALL
U OF CALIFORNIA
BERKELEY
CA 94720
(415) 642-4948

CA 92507

en

C>

<
rn

PAUL HECKEL
INTERACTIVE SYSTEMS CONSULTANTS
P.O. BOX 2345
PALO ALTO
CA 94305
(415) 965-0237

BLAND EWING
DEPT. OF ENTYMOLOGY
137
GIANNINI HALL
U OF CALIFORNIA
BERKELEY
CA 94720
(415) 642-6660

JON F. HUERAS
DAV ID ELL IOT SHA\~
DEPT. OF INFORMATION AND COMPUTER SCIE STRUCTURED SYSTEMS
U OF CALIFORNIA IRVINE
200 THIRD STREET -SUITE 207
IRVINE
CA 92717
LOS ALTOS
CA 94022
(415) 966-2082
(415) 948-0877

JOHN BANN ING
MAIL DROP 88
STANFORD LINEAR ACCELERATOR CENTER
P.O. BOX 4349
STANFORD
CA 94305
(415) 854-3300 X2802 (OFFICE)
(415) 325-9226 (HOME)

ED FOURT
C/O LBL LIBRARY
134
BLDG 50
LAWRENCE BERKELEY LAB
BERKELEY
CA 94720
(415) 843-2740 X5293

WILLIAM L. COOPER
ORG 4400
INTERSTATE ELECTRONICS
707 E. VERMONT
ANAHEIM
CA 92805
(714) 772-2811

APR I L ~11 LLER CONVERSE
SEISMIC ENGINEERING BRANCH
U.S .G.S.
345 MIDDLEFIELD ROAD
MENLO PARK
CA 94025

DAVID C. LUCKHAM
COMPo SCI. DEPT.
A. I. LABORATORY
STANFORD UN IVERS ITY
STANFORD
CA 94305
(415) 497-4971

SUSAN L. GRAHAM
COMPo SCI. DIVISION-EECS
511
EVANS HALL
U OF CALI FORN IA
BERKELEY
CA 94720

DAVID W. GIEDT
5421 WILLOWICK CIR.
ANAHEIM
CA 92807
(714) 772-2811

GLENN T. EDENS
DACONICS DIV.
XEROX
350 POTRERO AVENUE
SUNNYVALE
CA 94086
(408) 738-4800 (DACONICS)
(415) 494-4464 (XEROX/PARC)

BRIAN MCGUIRE
P.O. BOX 1371
FREMONT
CA 94538

G. CARRICK
MS970
FOUR-PHASE SYSTEMS INC.
19333 VALLCO PARKWAY
CUPERTINO
CA 95014
(408) 255-0900 X281

JOHN M. GRAM
COMPUTING FACILITY
U OF CALIFORNIA
IRVINE
CA 92717
(714) 833-6844

GARY BABCOCK
110-E RICHMOND ROAD
CHINA LAKE
CA 93555
(714) 446-6733

:3
txl

rn
;:0

ROD STEEL
MS 60-456
TEKTRONIX INC.
P.O. BOX 500
BEAVERTON
OR 97077
(503) 638-3411 X2523

ERIC SCHNELLMAN
HONEYWELL MARINE SYSTEMS
5303 SHILSHOLo NW
SEATfLE
WA 98117

ATTN: PROGRAM LIBRARIAN
COMPUTING CENTRE
UNIVERSITY OF ADELAIDE
BOX 498 G.P.O.
ADELAIDE
S.A.
5001
AUSTRALIA
61 822 34333 X2720!X2099

R. GREINER
MS970
FOUR-PHASE SYSTEMS INC.
19333 VALLCO PARKWAY
CUPERTINO
CA 95014
(408) 255-0900 X231

BOB PH ILLI PS
2009 N. E. BRAZEE
PORTLAND
OR 97212
(503) 284-8369

ATTN: BOE ING COMPANY
87-67 KENT TECHNICAL LIBRARY
P.O. BOX 3999
SEATTLE
WA 98124

C. D. MARLI N
DEPT OF COMPUTING SCIENCE
UNIVERSITY OF ADELAIDE
ADELAIDE
S.A.
5001
AUSTRALIA
223 4333

P. LI AO
MS970
FOUR-PHASE SYSTEMS INC.
19333 VALLCO PARKWAY
CUPERTINO
CA 95014
(408) 255-0900 X302

BARRY SMITH
OMSI COMPUTING
4015 SW CANYON ROAD
PORTLAND
OR 97221
(503) 248-5923

HELLMUT GOLDE
DEPT. OF COMPo SCI.
FR-35
U OF WASHINGTON
SEATTLE
WA 98195
(206) 543-9264

B. KIDMAN
DEPT OF COMPUTER SCIENCE
UNIVERSITY OF ADELAIDE
ADELA IDE
S.A.
5066
AUSTRAL IA
23 4333

RONALD L DANIELSON
DEPARTMENT OF EECS
UNIVERSITY OF SANTA CLARA
SANTA CLARA CA 95051
(408) 984-4181

DAV ID ROWLAND
ELECTRO SCIENTIFIC INDUSTRIES
13900 N.W. SCIENCE PARK DRIVE
PORTLAND
OR 97229

A. J. GERBER
BASSER DEPT. OF COMPUTER SCIENCE
UNIVERSITY OF SYDNEY
SYDNEY
N.S.W.
2006
AUSTRALIA

ATTN: SECRETARY
DEPARTMENT OF INFORMATION SCIENCE
UNIVERSITY OF TASMANIA
GPO BOX 252C
HOBART
TASMANIA 7001
AUSTRALIA

DADO BANATAO
3060 BILBO DRIVE
SAN JOSE
CA 95121
(408) 227-9027

ATTN: COMPUTER CENTER
OREGON STATE U
CORVALLIS
OR 97331

CARROLL MORGAN
BASSER DEPT. OF COMPUTER SCIENCE
U OF SYDNEY
SYDNEY
N.S.W.
2006
AUSTRALIA

A. H. J. SALE
DEPT. OF INFORMATION SCIENCE
UNIVERSITY OF TASMANIA
BOX 252C
HOBART
TASMANIA 7001
AUSTRALIA
23 0561

GARY LOWELL
2625 HIDDEN VALLEY
SANTA ROSA
CA 95404
(707) 544-6373

ATTN: DOCUMENTS ROOM
COMPUTER SCIENCE DEPARTMENT
U OF OREGON
EUGENE
OR 97403
(503) 686-4394

BRIAN G. ROWSWELL
UNIVERSITY COMPUTER CENTRE
UNIVERSITY OF SYDNEY
SYDNEY
N.S.W.
2006
AUSTRALI A
692 3491

O. BEAUFAYS
MATHEMATIQUES APPLIQUEES
UNIVERSITE LIBRE DE BRUXELLES
AVENUE F.-D. ROOSEVELT 50
BRUXELLES
1050
BELGIUM

W. W. PETERSON
DEPT OF ICS
U OF HAWAII
2565 THE MALL
HONOLULU
HI 96822
(808) 948-7420

LESLIE R. KERR
DAVID L. JOHNSON AND ASSOCIATES INC.
10545 WOODHAVEN LANE
BELLEVUE
WA 98004

KEN ROB INSON
DEPT. OF COMPUTER SCIENCE
UNIVERSITY OF NEW SOUTH WALES
P.O. BOX 1
KENSINGTON
N.S.W.
2033
AUSTRAL IA
663 0351

ALAIN PIROTTE
MBLE/RESEARCH LABORATORY
AVENUE EM. VAN BECELAERE 2
BRUSSELS
B-1170
BELG IUM
673.41.90
673.41.99

ROY CARLSON
(50-454)
TEKTRONIX
P.O. BOX 500
BEAVERTON
OR 97077

JOHN D. WOOLLEY
6722 128TH AVE. SE
BELLEVUE
WA 98006
(206) 641-3443

ANTHONY P. KYNE
DEPT. OF COMPUTER SCIENCE
UNIVERSITY OF MELBaJRNE
PARKV ILLE
VICTOR IA 3052
AUSTRALIA
345 1844

SERGIO DE MELLO SCHNEIDER
DEPARTAMENTO DE COMPUTACAO
UNIVERSIDADE FEDERAL DE SAO CARLOS
SAO CARLOS
SP
13560
BRAZil

FAY CHONG
10405 DEMPSTER AVENUE
CUPERT INO
CA 95014
(408) 987-1655

0

\

=

rr1

x:

,en
rn
-i
-i

rn
:;;0

::z
o
<:

rn
::s:
0::1

rn
:;;0

F. CELLINI
DEPT. OF COt~PUTER SC I ENCE
UNIVERSITY OF WESTERN ONTARIO
LONDON
ONTARIO
CANADA
(519) 679-6051

FRANKLIN B. DE GRAAF
6 CARMICHAEL COURT
K,~NATA

ONTARIO

K2K 1K2

CANADA

W. MORVEN GENTLEMAN
MATHEMATICS COMPUTING FACILITY
UNIVERSITY OF WATERLOO
WATERLOO
ONTARIO
N2L 3Gl
CANADA
(519) 885-1211

ATTN: LIBRARY
PERIODICALS SECTION
UN I VERS I TY OF ALBERTA
EDMONTON
ALBERTA
CANADA

ATTN: PROGRAM LIBRARY
COMPUTING CENTER
223
NATURAL SCIENCE CENTER
U OF WESTERN ONTARIO
LONDON
ONTARIO
N6A 5B7
CANADA
(519) 679-2151

BARY W. POLLACK
DEPT. OF COMPo SCI.
U OF BRITISH COLUMBIA
2075 WESBROOK PLACE
VANCOUVER
BC
CANADA
(604) 228-6794

ATTN: M. OOHERTY
128 TECHNICAL REFERENCE CENTER
UNIVERSITY OF TORONTO COMPUTER CENTER
10 KINGS COLLEGE ROAD
TORONTO
ONTARIO
CANADA
(416) 978-8995

ATTN: REFERENCE ROOM
COMPUTING AND INF. SCI.
QUEEN'S UNIVERSITY
KINGSTON
ONTARIO
CANADA

F. G. PAGAN
COMPUTER SC I ENCE
MEMORIAL UNIVERSITY
ST. JOHN'S
NElvFOUNDLA A1 C 5S7
CANADA

R. D. TENNENT
L. C. PORTIL
DEPT. OF COMPUTING AND INFORMATION SCI COMPUTER CENTRE
QUEENS UNIVERSITY
U OF WINDSOR
KINGSTON
ONTARIO
K7L 3N6
ONTARIO
WINDSOR
CANADA
CANADA
(519) 253-4232 X645

j. W. ATWOOD
DEPT OF COMPo SCI.:H963-10
CONCORDIA UNIVERSITY
1455 DE MAISONNEUVE BLVD. WEST
MONTREAL
QUEBEC
H3G 1M8
CANADA
(514) 879-8130

N. SOLNTSEFF
DEPT. OF APPLI ED ~~ATH.
MCt~ASTER UN I VERS I TY
HAMILTON
ONTARIO
CANADA
(416) 525-9140 X4689

D. B. COLDRICK
COMPUTATION CENTRE
BLDG. M-60
NATIONAL RESEARCH COUNCIL
MONTREAL ROAD
OTTAWA
ONTARIO
K1A OR6
CANADA

MIKE KIMBER
DATA CENTRE
THE GLOBE AND MAIL
444 FRONT ST. WEST
TORONTO
ONTARIO
CANADA

LUIGI LOGRIPPO
COMPo SCI. DEPT.
U OF OTTAWA
OTTAWA
ONTARIO
CANADA

HENRY SPENCER
SP SYSTEMS
BOX 5255 STATION A
TORONTO
ONTARIO
CANADA

H. TAYLOR
COMPUTING CENTRE
APPLICATIONS DEPT.
U OF OTTAWA
OTTAWA
ONTARIO
CANADA

K1N 6N5

K1N 6N5

ATTENTION: DONALD LINDSAY
DYNALOGIC CORPORATION LIMITED
141 BENTLEY AVENUE
OTTAlvA
ONTARIO
K2E 6T7
CANADA
(613) 226-1383

ANNE STOCCO
COMPo AND INFO. SCIENCE
108
I.C .S.
UNIVERSITY OF GUELPH
GEULPH
ONTARIO
CANADA
..•...... X2259
CHARLES H. FORSYTH
APT. 2-304
300 REGINA ST. N.
WATERLOO
ONTARIO
CAI,ADA
(519) 884-7531

K7L 3N6

L8S 4K1

M5V 2S9

M5W 1N5

N1G 2Wl

N2J 4T2

G. D. DERHAK
COMPUTER CENTRE
U OF MANITOBA
WINNIPEG
MANITOBA
CANADA

N9B 3P4

R3T 2N2

T6G 2J8

DOUG DYMENT
6442 IMPERIAL AVE.
W, VANCOUVER B.C.
CANADA
(604) 921-7954

(/)

rV6T 1W5

:;;0

V7W 2J6

ATTN: DATALOGISK INSTITUT
COPENHAGEN UNIVERSITY
S IGURDSGADE 41
COPENHAGEN N DK-2200
DENMARK

LARS CHRISTENSEN
ALDERSHVILEVEJ 16
BAGSVAERD
DK-2880
DENMARK
009 45 2 98 20 09

STEPHEN SOULE
DEPT. OF COMP. SC I .
U OF CALGARY
CALGARY
ALBERTA
CANADA
(403) 284-6780

T2N lN4

PRE BEN TAAST!
COMPUTER CENTER
UNIVERSITY OF AALBORG
STRANDVEJEN 19
AALBORG
DK-9000
DENMARK
(08) 138 788

T2N lN4

L. BRANDT
DET REGIONALE EDB-CENTER
AARHUS UNIVERSITET
AARHUS
C.
8000
DENMARK
06 - 12 83 55

B. VENKATESAN
DEPT. OF COMPUTER SERVICES
U OF CALGARY
2920 24TH AVE. N.W.
CALGARY
ALBERTA
T2N lN4
CANADA
(403) 284-5207

ANTTI SALAVA
DEPT. OF COMPUTER SCIENCE
UNIVERSITY OF HELSINKI
TOOLONKATU 11
HELSINKI 10
SF-00100
FINLAND

-I
-I

rn

W. BRUCE FOULKES
DEPARTMENT OF COMPUTER SCIENCE
THE UNIVERSITY OF MANITOBA
WINNIPEG
MANITOBA R3T 2N2
CANADA
(204) 474-8466

BRIAN W. UNGER
COMPUTER SCIENCE DEPT.
UNIVERSITY OF CALGARY
CALGARY
ALBERTA
CANADA
(403) 284-6316

rn

JUHA HEINANEN
DEPARTMENT OF COMPUTER SCIENCE
UNIVERSITY OF TAMPERE
BOX 607
TAMPERE 10
SF-33101
FINLAND

LUCIEN FEIEREISEN
EDELSHEIMSTR. 4
KARLSRUHE 1 0-7500
GERMANY

ATTENTION: N. V. KOTESWARA RAO
COMPUTER TRG. UNIT
ELECTRONICS CORPORATION OF INDIA
HYDERABAD
(AP)
500762
INDIA
71611

TERUO HI KITA
DEPT.' OF INFO. SCI.
U OF TOKYO
TOKYO
113
JAPAN
03-812-2111 X2947
:z
tTl

O. LECARr~E
I.M.A.N.
UNIVERSITE DE NICE
PARC VALROSE
CEDEX
NICE
FRANCE
\

GERHARD GOOS
INSTITUT FUER INFORMATIK II
UNIVERSITAT KARLSRUHE
POSTFACH 6380
KARLSRUHE 1 0-7500
GERMANY
0721/608-3970

MICHAEL Z. HANAN I
COMPUTATION CENTER
BEN GURIAN UNIVERSITY OF THE NEGEV
BEER-SHEVA
ISRAEL

P. I~AURICE
INFORMATIQUE
UNIVERSITE PAUL SABATIER
118 ROUTE DE NARBONNE
31077
TOULOUSE
CEDEX
FRANCE

ATTENTION: JAN WITT
ZFE FL SAR
S IEMENS AG
HOFMANNSTR. 51
MUNCHEN 70
0-8000
GERMANY
(089) 722-22651

RUTH WEINBERG
COMPUTATION CENTER
HEBREW UNIVERSITY OF JERUSALEM
JERUSALEM
ISRAEL
02-32011/280

JEAN-PIERRE FAUCHE
DEPARTMENT INFORMATIQUE
IREP
BOlTE POSTALE 47
CEDEX
GRENOBLE
FRANCE

ALBRECHT BIEDL
GIDEON YUVAL
INSTITUT FUR SOFTWARETECHNIK UND THEOR COMPUTER SCIENCE
DV-GRUNDAUSBILDUNG
THE HEBREW UNIVERSITY
TECHNISCHE UNIVERSITAT BERLIN
JERUSALEM
OTTO-SUHR-ALLEE 18/20
ISRAEL
1000 BERLIN 10
VSH 419
GERMANY

06034

38040

EIITA WADA
DEPARTMENT OF
UNIVERSITY OF
BUNKYOKU
JAPAN
(03) 812-2111

~

MATHEMATICAL ENGINEERING ~
TOKYO
rTOKYO
113
tTl
~

X7486

~

tTl

;;;c

TOSHIAKI SAISHO
1-25-7 KITAMAGOME
OOTA-KU
TOKYO
JAPAN

MASARU WATANABE
9-16 SHINOHARADAI
KOHOKU-KU
YOKOHAMA
JAPAN

143

222
:2

o

<
tTl

ALA INTI SSERANT
DEPARTEMENT INFORMATIQUE
ECOLE OES MINES
PARC DE SAURUPT
CEDEX
54042
NANCY
FRANCE

GERHARD FRIESLAND
INSTITUT FUR INFORMATIK
UNIVERSITAT HAMBURG
SCHLUETERSTRASSE 70
HAMBURG 13
2
GERMANY

IRVING N. RABINOWITZ
MAKOTO ARISAWA
DEPT. OF COMPo SCI.
COMPUTER SCIENCE DEPARTMENT
TECHNION-ISRAEL INSTITUTE OF TECHNOlOG YAMANASHI UNIVERSITY
TECHNION CITY HAIFA
4-3-11 TAKEDA KOFU
ISRAEL
YAMANASHI
400
JAPAN
(0552) 52-1111

HORST SANTO
GESELLSCHAFT FUER MATHEMATIK UNO DATEN
INSTITUT FUER PLANUNGS UNO ENTSCHEIDUN
POSTFACH 1240 SCHLOSS BIRLINGHOVEN
ST.AUGUSTIN 1 0-5202
GERMANY

H.-H. NAGEL
INSTITUT FUER INFORMATIK
UNIVERSITAT HAMBURG
SCHLUTERSTRASSE 66-72
HAMBURG 13
2
GERMANY

MARCO SOMMANI
C/O CNUCE
VIA SANTA MARIA 36
PISA
1-56100
ITALY
(050) 45245

NOBUKI TOKURA
en
DEPT. OF INFORMATION AND COMPUTER SCIE
OSAKA UNIVERSITY
1-1 MACHIKANEYAMA
TOKONAKA
500
JAPAN

H. -J. HOFFMANN
FACHBEREICH INFORMATIK
TECHNISCHE HOCHSHULE
STEUBENPLATZ 12
DARMSTADT
0-6100
GERMANY

CARSTEN KOCH
DISTRIKT NORD
CONTROL DATA GMBH
UBERSEERING 13
HAMBURG 39
2000
GERMANY
630 80 21 - 25

MAURO MONTES I
TEMA SPA
VIA MARCON I 29/1
BOLOGNA
40122
ITALY
051-267285

CHARLES E. MURPHY
COMPUTER SCIENCE GROUP
UNIVERSITY OF TRIPOLI
P.O. BOX 656
TRIPOLI
LIBYA

ASHOK N. ULLAL
KARLSTR. 1
JETTENBURG
0-7401
GERMANY

W. WEHINGER
LANGUAGES AND PROCESSORS GROUP
RECHENZENTRUM
UNIVERSITAT STUTTGART
STUTTGART 80 7000
GERMANY
(0711) 784/1

GUISEPPE SELVE
TEMA S.P.A.
VIA MARCONI 29/1
BOLOGNA
40122
ITALY
051-267285

ATTN: DEPARTMENT OF INFORMATION SCIENC
VICTORIA UNIVERSITY OF WELLINGTON
PRIVATE BAG
WELLINGTON
NEW ZEALAND

"0

l>
C0
tTl

~

CTl

J. J. VAN AMSTEL
COMPUT ING CENTRE
EINDHOVEN UNIVERSITY OF TECHNOLOGY
P.O. BOX 513
EINDHOVEN
THE NETHERLANDS
(040) 474547

C. J. COPELAND
SCHOOL OF COMPUTER SCIENCE
ULSTER COLLEGE
JOROANSTOWN
NEWTOWNABBEY N. IRELAND
UN ITEf) KINGDOM

ATTENTION: E. N. VAN DE VENTER
URS AMMANN
COMPUT ING CENTRE
INSTITUT FUER INFORMATIK
NATIONAL RESEARCH INSTITUTE FOR MATHEM ZUERICH
CH-8092
P J BOX 395
SWITZERLAND
PRETORIA
0001
(CH ZUERICH) 3262 11 X2214
SOUTH AFRICA
74-9111

ATTN: DSI,
CENTRAL LIBRARY
P.O. BOX 18
GELEEN
THE NETHERL ANDS

R. G. DICKERSON
SCHOOL OF INFORMATION SCIENCES
THE HATFIELD POLYTECHNIC
PO BOX 109 COLLEGE LANE
HATFIELD
HERTS
AL10 9AB
UN I TED KINGDOM
HATFIELD 68100

STEN LJUNGKV IS
GUSTAF CLASONS GATA 61
NORRKOPING
S-603 78
SWEDEN

SVEN ERIK KNUDSEN
INSTITUT FUER INFORMATIK
ETH - ZENTRUM
ZUERICH
CH-8092
SWI TZERLAND

D. D. DE VRIES
LANDLEVEN 1
REKENCENTRUM R.U.G.
P.O. BOX 800
GRONINGEN
THE NETHERLANDS

MAURICE O'FLAHERTY
444 MEVILLE GARDEN VILLAGE
NEWTOWNABBEY N. IRELAND ANTRIM
UNITED KINGDOM

STAFFEN Ror~BERGER
COMPUTER SCIENCE
ROYAL INSTITUTE OF TECHNOLOGY
STOCKHOU·1
S-100 44
SWEDEN

ATTN: RZ - BIBLIOTHEK
ETH - ZENTRUM
ZURICH
CH-8092
SWITZERLAND

H. VAN LOON
ACADEI~ I SCH Cm~PUTER CENTRUI~ UTRECHT
BUDAPESTLAAN 6
DE UITHOF
UTRECHT
THE NETHERLANDS
030-531436

C. A. LANG
PITT BUILDING
CAMBRIDGE UNIVERSITY PRESS
TRUMP INGTON ST.
CAMBRIDGE
ENGLAND
CB2 1RP
UNITED KINGDOM
CAMBRIDGE 58331

IVAR LABERG
COMPUTER DEPARTMENT
UNIVERSITY HOSPITAL OSLO
RIKSHOSP ITALET
OSLO
1
NORWAY

R. MOREL
CENTRE DE CALCUL ELECTRONIQUE
COLLEGE DE GENEVE
1211 GENEVE 3
SWI TZERLAND
27 22 28

(02) 20 10 50

ATTN: BOEKHANDEL VERWI JS EN STAM B.V.
PRINSESSEGRACHT 2
'S-GRAVENHAGE 2005
THE NETHERLANDS

LENNART OSKARSSON
TELEFONAKTIEBOLAGET L M ERICSSON
FACK
MOLNDAL
5-431 20
SWEDEN

J. A. ALANEN
VAKGROEP INFORMATICA R.U.
BUDAPESTLAAN 6
UTRECT
2506
THE NETHERLANDS

BILL FINDLEY
COMPUTING SCIENCE DEPARTMENT
UNIVERSITY OF GLASGOW
GLASGOW
SCOTLAND
G12800
UNITED KINGDOM
339 8855 X7391

T. J. VAN WEERT

A. M. ADDYMAN
DEPARTMENT OF COMPUTER SCIENCE
THE UNIVERSITY
MANCHESTER
ENGLAND
M13 9PL
UN ITED KINGDOM
061-273 5466

KURT FREDR IKSSON
RINGLEKEN 7
MOLNDAL
S-431 39
SWEDEN
4631-41 05 14 (HOME)
4631-27 50 00-491 (OFFICE)

S. BALASUBRAMAN I AN
DEPART~~ENT ~1SE

A. C. W. LEYEN
DEPARTMENT MSE
C/O KON INKLI JKE
SHELL-LABORATORIUM
P.O. BOX 3003

ELZENLAAN 28
PEIZE
8131
THE NETHERLANDS

Ar~STERDAM

b:1

rn
;:u

EH1 2HW

THE NETHERLANDS
DAVID BATES
12
CHEMIN DE TAVERNAY
1218 GRAND SACONNEX
GENEVA
S,iI TZERLAND

ANDREW S. TANENBAUM
WISKUNDIG SEMINARIUM
VRIJE UNIVERSITEIT
DE BOELELAAN 1081
AMSTERDAM
THE NETHERLANDS
020 548 24 10

ATTN: THE LIBRARIAN
DEPT. OF COMPUTER STUDIES
U OF LANCASTER
BAILRIGG
LANCASTER
UNITED KINGDOM
LANCASTER 65201 X4133

JOHN REYNOLDS
31 BARRINGTON ROAD
LONDON
ENGLAND
UNITED KINGDOM

<:
fTl

3:

LARS-ERIK THORELLI
CHRI ST I AN JACOBI
DEPT. OF TELECOMMUNICATION NETWORKS & INSTITUT FUER INFORMATIK
THE ROYAL INSTITUTE OF TECHNOLOGY
ETH
STOCKHOLM 70 S-100 44
ZURICH
CH-8092
SWEDEN
SWITZERLAND
SWEDEN-08-236520
01 326277 2217

KON INKL IJKE/SHELL -LABORATOR I UM
PO BOX 3003
AM.STERDAM
THE NETHERLANDS
(020) 202694

A. BALFOUR
cm,PUTER CENTRE
HERIOT-WATT UNIVERSITY
37-39 GRASSMARKET
EDINBURGH
SCOTLAND
UN ITED KINGDOM

:z
o

N8

D. W. BARRON
COMPUTER STUDIES GROUP
THE UNIVERSITY
ENGLAND
SOUTHAMPTON
UNITED KINGDOM
0703-559122 X700

-0

:l>

S09 5NH

J. GOODSON
DEPARTMENT OF MATHEMATICS
THE UNIVERSITY
ENGLAND
SOUTHAMPTON
S09 5NH
UN ITED KINGDm~
\

JUDY MULLI NS
DEPARTMENT OF MATHEMATICS
THE UNIVERSITY OF SOUTHAMPTON
S09 5NH
SOUTHAMPTON
ENGLAND
UNITED KINGDOM
0703 559122 X2387
CHRIS MARTIN
COMPUTING SERVICES
THE HICKS BUILDING
UNIVERSITY OF SHEFFIELD
ENGLAND
S10 2TN
SHEFFI ELD
UN ITED KINGDOM
78555 X263
ROY EDWARDS
DEPT. OF STAT. AND COMPo SCI.
HOLLOWAY COLLEGE
EGHAM HILL
TW20 OEX
EGHAM
SURREY
UN ITED KINGDOM
EGHAM 4455
ATTENTION: C. LAZOU
COMPUTER CENTRE
UNIVERSITY OF LONDON
20 GUILFORD STREET
ENGLAND
LONDON
UN ITED KINGDOM
01-405-8400
ATTN: LIBRARIAN
PO BOX 4SE
LOGICA LIMITED
64 NEWMAN STREET
ENGLAND
LONDON
UNITED KINGDOM
(01) 580 8361
ROBERT REINHARDT
FABI AN IJEVA 39
LJUBLJANA
61 000
YUGOSLAVIA

WCl

WIA 4SE

JOHN W. ADAMS
J. MAO< ADAMS
A. M. ADDYI~AN
J. A. ALANEN
URS AMMANN
RICHARD V. ANDREE
DENN ISS. ANDREWS
MAKOTO AR I SAWA
ATTENTION: C. LAZOU
ATTENTION: DAN BURROWS
ATTENTION: DAVID MADISON
ATTENTION: DONALD LINDSAY
ATTENTION: EDWARD E. BALKOVICH
ATTENTION: E. N. VAN DEVENTER
ATTENT ION: GORDON R. SHERMAN
ATTENTION: JAN WITT
ATTENTION: JERRY W. SEGERS
ATTENTION: KYU LEE
ATTENTION: N. V. KOTESWARA RAO
ATTENTION: PAUL C. SMITH
ATTENTION: ROBERT E. NOVAK
ATTENTION: RUTH DROZIN
ATTENTION: R. D. iBERGERON
ATTENTION: STEVE REISMAN
ATTN: ACADEMIC SERVICES
ATTN: BOEING COMPANY
ATTN: BOEKHANDEL VERWIJS EN STAM B.V.
ATTN: B1700 PROTEUS PROJECT
ATTN: COMPUTER CENTER
ATTN: COMPUTER SCIENCE DEPT.
ATTN: COMPUTER SCIENCES INSTITUTE
ATTN: CONSULTING OFFICE
ATTN: DATALOGISK INSTITUT
ATTN: DEPARTMENT OF INFORMATION SCIENCE
ATTN: DEPT. OF COMPUTER SCIENCE
ATTN: DIRECTOR
ATTN: DOCUMENTS ROOM
ATTN: DOCUMENTS ROOM LIBRARIAN
ATTN: DOROTHY SMITH - REFERENCE LIBRARIAN
ATTN: DSM
ATTN: FRIEDA S. COHEN
ATTN: J. F. MCINTYRE - LIBRARIAN
ATTN: LI BRAR IAN
ATTN: LIBRARIAN
ATTN: LIBRARY
ATTN: LIBRARY
ATTN: LIBRARY
ATTN: M. DOHERTY
ATTN: PROGRAM LIBRARIAN
ATTN: PROGRAM LIBRARY
ATTN: PROGRAMMING ADV I SOR
ATTN: READING ROOM
ATTN: RECEIVING CLERK
ATTN: REFERENCE ROOM
ATTN: REFERENCE ROOM
ATTN: RZ - BIBLIOTHEK
ATTN: SECRETARY
ATTN: SERIALS DEPT.
ATTN: SSRFC LIBRARY
ATTN: THE LIBRARIAN

18015
88003
tA13 9PL
2506
CH-8092
73019
62901
400
WCl
55812
35806
K2E 6T7
93105
0001
37916
D-8000
30332
59801
500762
55455
55165
17837
03824
55455
90007
98124
2005
84112
97331
55455
92507
61801
DK-2200

(.I')

n

UN ITED KINGDOM
THE NETHERLANDS
SWITZERLAND

:l>

r:z:
(T1

JAPAN
UNITED KINGDOM

=E:

CANADA

-i
-i

(.I')

r(T1

SOUTH AFRICA
GERMANY

(T1

;;0
~

en

INDIA

THE NETHERLANDS

z
Cl

-<
(T1

3
ttl

DENMARK
NEW ZEALAND

38677
32611
97403
46637
78712

(T1

;;0

I-'-'
to

'.J

THE NETHERLANDS
53706
22903
32611
WIA 4SE UNITED KINGDOM
80225
01754
T6G 2J8 CANADA
CANAOA
5001 AUSTRALIA
N6A 5B7 CANAOA
89507
02139
61820
K7L 3N6 CANADA
55455
CH-8092 SWITZERLAND
7001 AUSTRALIA
52242
55455
UNITED KINGDOM

en

-0

:l>

cn
fT1
N

CO

-0

>ATTN: uce LIBRARIAN
ATTN: USER SERVICES GROUP
ATTN: USER SERVICES LIBRARIAN
J. W. ATWOOD
GARY BABCOCK
FRED P. BAKER
SAMUEL T. BAKER
T. P. BAKER
S. BALASUBRAM~,N IAN
LYNNE J. BALDWI N
A. BALFOUR
MICHAEL S. BALL
MAUR ICE BALLEW
RICHARD BALOCCA
DADO BANATAO
JOHN BANNING
WILLIAM BARABASH
D. W. BARRON
STEVEN BARRYTE
JEFFREY BARTH
BRIT J. BARTTER
DAVID BATES
JOHN C. BEATTY
O. BEAUFAYS
STEVEN M. BELLOVIN
HERMAN BERG
PHILIP N. BERGESTESSER
SCOTT BERT ILSON
JAMES L. BEUG
ALBRECHT BIEDL
MARK BI LODEAU
TIM BONHAM
ERWIN BOOK
GARY J. BOOS
KEN BORGENDALE
L. BRANDT
RONALD F. BRENDER
FRANK BREWSTER
C. E. BRIDGE
ROBERT L. BRIECHLE
ALBERT S. BROWN
ARTHUR A. BROWN
WARREN R. BROWN
GERALD BRYAN
WI LHEU~ BURGER
HOWARD BUSSEY JR.
BILL BUZBEE
ROY CARLSON
DAVID E. CARLTON
G. CARRICK
GARY CARTER
D. A. CAUGHFIELD
GARY CEDERQU I5T
GERALD N. CEDERQUIST
F. CELLINI
GABR I EL CHANG
FAY CHONG
LARS CHRISTENSEN
PAUL CHRISTOPHERSON
RICHARD J. CICHELLI

52242
80523
88003
H3G 1M8 CANADA
93555
61820
37130
32304
THE NETHERLANDS
68101
EHI 2HW UN ITED KINGDOM
92132
79409
61801
95121
94305
11794
S09 5NH UNITED KINGDOM
90048
94720
60202
SWI TZERL,~ND
94550
BELG IUM
27514
53703
35758
55406
93407
VSH 419 GERt4ANY
55401
55454
90066
58501
55455
8000 DENMARK
01754
22304
19898
44325
01754
20037
02038
91711
78712
80302
87545
97077
60625
95014
89507
79601
75275
30332
CANADA
02139
95014
DK-2880 DENt~ARK
'):1)4 "

18103

KURT COCKRUM
92507
78758
WILLIAM L. COHAGAN
47401
GEORGE COHN I I I
PETER COLBY
02160
D. B. COLDRICK KIA OR6
02193
TERRENCE M. COLLIGAN
MICHAEL N. CONDICT
13440
APRIL MILLER CONVERSE
94025
RICHARD CONWAY
14850
WILLIAM L. COOPER
92805
C. J. COPELAND
02139
F. J. CORBATO
JOHN EARL CRIDER
77025
DONALD B. CROUCH
35486
RONALD L DANIELSON
95051
JAMES DARLING
87801
ANN D. DAVIES
23284
FRANKLIN B. DE GRAAF K2K 1K2
HAROLD DE VORE
58202
D. D. DE VRIES
RANCE J. DELONG
18018
G. D. DERHAK R3T 2N2
R. G. DICKERSON AL10 9AB
01742
LLOYD 0 ICK~'lAN
ROBERT ALAN DOLAN
93109
JEFFREY J. DRUMMOND
55455
DOUG DYMENT V7W 2J6
T. A. 0' AURIA
10027
R. STERLING EANES
02154
CHRIS EASTLUND
55401
JOHN T. EASTON
55455
GLENN T. EDENS
94086
HANK EDWARDS
01701
ROY EDWARDS TW20 OEX
JOHN D. EISENBERG
19711
DAVE ENGLANDER
18015
PHILLIP H. ENSLOW JR.
30332
HOWARD D. ESK I N
10025
JOHN B. EULENBERG
48824
BLAND EW ING
94720
R. NEil FAIMAN JR.
48228
JAMES N. FARMER
30332
JOSEPH H. FASEL II I
47907
JEAN-PIERRE FAUCHE
38040
LUCIEN FEIEREISEN
0-7500
JEANNE FERRANTE
02139
LINCOLN FETCHER
55455
BILL FINDLEY G12 8QQ
CHARLES N. FISCHER
53706
TED FI SHMAN
60659
KEVIN FJELSTED
55455
CHARLES H. FORSYTH N2J 4T2
LLOYD D. FOSDICK
80309
W. BRUCE FOULKES R3T 2N2
ED FOURT
94720
DENNIS J. FRAILEY
75222
MIKE FRAME
20006
K. FRANKOWSKI
55455
:,JRT FREDRIKSSON S-431 39
G. FRI EDER
14226

U"l

n

>,.
CANADA

z
m
:>::

,.
U"l

UNITED KINGDOM

rn
-l
-l

rn
;:0

~

CANADA

CYl

THE NETHERLANDS
CANADA
UNITED KINGDOM

CANADA

:z
0

<:

rn
3:

to

rn
UNITED KINGDOM

;;0

~

LD

'I

en

FRANCE
GERMANY
UNITED KINGDOM

CANADA
CANADA

-0

>G"l

fT1

SWEDEN

N
l.D

EDWARD R. FRIEDMAN
10012
GERHARD FRIESLAND
2 GERMANY
JOHN FUNG
55414
EOWARD F. GEHRINGER
47907
W. MORVEN GENTLEMAN N2L 3Gl CANADA
A. J. GERBER
2006 AUSTRALIA
DAVID W. GIEDT
92807
N. A~10S GILEADI
01754
ED GLASER
54302
JOHN J. GODA JR.
30332
HELlMUT GOLDE
98195
DAVID A. GOMBERG
20016
J. GOODSON S09 5NH UNITED KINGDOM
GERHARD GOOS 0-7500 GERMANY
DENN IS GRAHAt~
94086
SUSAN l. GRAHAM
94720
WILLIAM O. GRAHAM
19711
JOHN M. GRAM
92717
KRISTINA GREACEN
55455
MIKE GREEN
78284
R. GREINER
95014
DAVID J. GRIFFITHS
02881
DONAl.D E. GR IMES
02174
MARTIN L GRISS
84112
DALE H. GRIT
80523
WILLI AM GROSKY
48202
JONATHON R. GROSS
55420
ROGER GULBRANSON
61801
S. L. GULDEN
18015
MICHAEL HAGERTY
02174
HARRY P. HAIDUK
79015
JOEL M. HALPERN
55455
RONALD J. HAM
01754
DON HAMNES
55409
MICHAEL Z. HANAN I
ISRAEL
GILBERT J. HANSEN
75075
BRIAN HANSON
55455
STEPHEN J. HARTLEY
23185
KEITH HAUER-LOWE
55417
PAUL HECKEL
94305
H. G. HEDGES
48824
CHARLES HEDRICK
61801
DENNIS HE It~BIGNER
90278
JUHA HEINANEN SF-33101 FINLAND
T. S. HEINES
44115
DAVID HELFINSTINE
55303
CARL HENRY
55057
WILLIAM HENRY
10003
MARK HERSEY
48823
BRYAN L. HIGGINS
94621
TERUO HIKITA
113 JAPAN
W. A. HINTON
53201
THEA D. HODGE
55455
TIMOTHY W. HOEL
55057
MARILYN HOFFMAN
18018
H.-J. HOFFMANN 0-6100 GERMANY
TIMOTHY J. HOFFMANN
55455
DAVID W. HOGAN
78751
WILLIAM C. HOPKINS
14226
FRANK H. HORN
53706

FREDERICK A. HOSCH
DAVID A. HOUGH
ROSEMARY HOWBRIGG
RALPH HOWENST INE
RICHARD HUBER
JON F. HU ERAS
STEVEN L. HUYSER
DAN IEL C. HYDE
M. ELIZABETH IBARRA
AVRUr~ ITZKOW ITZ
CHRISTIAN JACOBI
GEORGE D. JELATIS
MITCHELL R. JOELSON
CHRISTOPHER K. JOHANSEN
BR IAN W. JOHNSON
ROBERT T. JOHNSON
R. I. JOHNSON
R. WARREN JOHNSON
WARREN JOHNSON
ED KATZ
MARK J. KAUFMAN
THOMAS A. KEENAN
GINGER KELLY
WILLETT KEWTON
JAr~ES A. KENDALL
LESLIE R. KERR
ROBERT KEZELL
B. KIDMAN
D. B. KILLEEN
MIKE KIMBER
M. A. KLEINERT
J. C. KNIGHT
SVEN ERIK KNUDSEN
CARSTEN KOCH
ALAN A. KORTE SOJA
R. KRASIN
ANTHONY P. KYNE
IVAR LABERG
R. B. LAKE
DAN LALIBERTE
LARRY D. LANDIS
STEVE LANDRY
DAV ID LANDSKOV
C. A. LANG
CHARLES L. LAWSON
O. LECARME
HENRY F. LEDGARD
STEVE LEGENHAUSEN
MIKE LEMON
L. RICHARD LEWIS
A. C. W. LEYEN
P. LIAO
LAWRENCE A. LIDDIARD
DENNIS R. LlENKE
SHIHTA LIN
JOHN E. LIND
GARY LI NDSTROM
STEN LJ UNGK VI S
LUIGI LOGRIPPO
RALPH L. LONDON

70122
23602
06413
73069
77843
92717
48824
17837
11973
61820
CH-8092
55455
55455
02166
75075
87545
58202
56301
70504
70504
92025
20550
77001
78705
77030
98004
19122
5066
70118
M5V 2S9
84112
23665
CH-8092
2000
48103
02154
3052
1
44106
55455
64108
70504
70504
CB2 lRP
91103
06034
01002
08904
15213
48127

=

,

(/")

SWITZERLAND

rn
-i
-i

rn
:;0

AUSTRALIA
CANADA

=
o
-<
rn
to

SWITZERLAND
GERMANY
AUSTRALIA
NORWAY

UNITED KINGDOM
FRANCE

THE NETHERLANDS
95014
55455
55455
55455
55455
15260
SWEDEN
KIN 6N5 CANADA
90291

rn
:;0

-u
J::>

GARY LOWELL
95404
DAVID C. LUCKHAM
94305
MARK LUKER
55812
MICHAEL J. LUTZ
14623
JOHN T. LYNCH
19301
M. H. MACDOUGALL
94086
C. D. MARLIN
5001
CHR IS MART IN S10 2TN
JAMES F. MARTINSON
56201
P. t~AUR ICE
31077
RA I NER F. ~1CCOWN
21045
PAUL L. MCCULLOUGH
91016
BRIAN MCGUIRE
94538
TERRY P. MEDL I N
20014
MICHAEL MEEHAN
02138
HUGO ME ISSER
55427
MICHAEL ROBERT MEISSNER
55455
J. SCOTT MERR ITT
12180
DAVID C. t~ESSER
55455
HOWARD H. METCALF
90068
GARRY MEYER
11794
W. J. t~EYERS
75243
JOSEPH A. MEZZAR08A
18041
ANDY MICKEL
55455
M. D. t~ICKUNAS
61801
R. W. MILKEY
85726
GLENN t~1 LLER
55109
JAMES R. MILLER
47906
VICTOR S. MILLER
02125
CARLTON MILLS
61801
JAMES F. MINER
55455
JESSE D. MIXON
75961
JAMES MOLONEY
14420
JOHN MONTAGUE
87545
MAURO tjONTE S I
40122
R. MOREL
CARROLL MORGAN
2006
RONALD G. MOS IER
48221
STEVEN S. MUCHNICK
66045
JUDY t~ULLI NS S09 5NH
NEWTON J. t~UNSON
13676
CHARLES E. MLRPHY
HARRY I~. t~URPHY JR.
87117
H.-H. NAGEL
2
T. A. NARTKER
87801
JOHN NAUMAN
55455
MARK S. NIEMCZYK
60015
R. K. NORD IN
55454
THEODORE A. NORMAN
84602
DAVID A. NUESSE
54701
JOHN NUNNALLY
72143
CAROL A. OGDIN
22314
RICHARD OHRAN
84602
RON OLSEN
07733
LENNART OSKARSSON S-431 20
MARK OVERGAARD
92093
DANIEL M. O'BRIEN
61820
MAURICE O'FLAHERTY
ANTRIM
F. G. PAGAN A1C 5S7
PETER PAWELCZAK
10019

AUSTRALIA
UN ITEO KINGDOM
FRANCE

ITALY
SW I TZERLAND
AUSTRALIA
UNITED KINGDOM
LIBYA
GERMANY

SWEDEN
UNITED KINGDOM
CANADA

PATRICK PECORARO
SHMUEL PELEG
WAL T PERKO
DAV ID PERU~AN
W. W. PETERSON
CHARLES PFLEEGER
80B PHILLIPS
ALAIN PIROTTE
STEPHEN A. PITTS
RUDOLPH C. POLENZ
BARY W. POLLACK
GEORGE POONEN
L. C. PORTIL
J. L. POSD~,MER
FRED W. POWELL
RON PRICE
WILLIAM C. PRICE
ANDREW S. PUCHR1K
BRUCE A. PUMPLIN
HOWARD D. PYRON
DOUGLAS H. QUEBBE~1AN
IRVING N. RABINOWITZ
V. LALITA RAO
WAYNE RASBAND
JEFFERY M. RAZAFSKY
ROY F. REEVES
PHYLLIS A. REILLY
ROBERT REINHARDT
JOHN REYt,OLDS
GEORGE H. RICHMOND
PETER A. RIGSBEE
MARK RIORDAN
CLARK M. R08ERTS
JOE C. ROBERTS
KEN ROB I ',SON
STAFFEN ROMBERGER
BERNIE ROSMAN
E. L. ROWE
DAVID ROWLAND
BRIJ\N G. ROWSWELL
HERBERT RUBENSTEIN
NANCY RUJ Z
MARK RUSTAD
FRANK RYB i CK I
JONATHAN SACHS
TOSHIAKI SAISHO
ANTTI SALAVA
A. H. J. SALE
TIMOTHY J SALO
CHESTER J. SALWACH
TOM SANDERSON
HORST SANTO
DAVID SARANEN
AARON SAWYER
B08 SCARLETT
G. MICHAEL SCHNEIDER
SERGIO DE MELLO SCHNEIDER
ERIC SCHNELLMAN
STEPHEN C. SCHWARM
FRED L. SCOTT

85721
20742
55414
55455
96822
37916
97212
B-1170 BELGIUM
73110
54701
V6T 1W5 CANADA
02168
N9B 3P4 CANADA
13210
24401
07726
91107
22090
54701
65401
47130
ISRAEL
1S015
20014
64108
43220
90746
51 000 YUGOSLAVIA
N8 UNITED KINGDOM
80309
20375
48824
91016
21851
2033 AUSTRALIA
S-100 44 SWEDEN
01701
19301
97229
2006 AUSTRALI A
55455
87115
55112
19122
60604
143 JAPAN
SF-00100 FINLAND
7001 AUSTRAL I A
55455
18960
87002
0-5202 GERMANY
55792
02035
55455
55455
13560 BRAZ IL
98117
19898
35314

(/)

n

,J::>
:z

rn
::£

,

(/)

rn
-I
-I

rn
:::0

'10::

m

:z:
0

<:

rn
3:

to

rn
:::0

........
<.D

'-J

m

-u
J::>
G>

rn
\.N

........

-0
:J;>

WAYNE SEIPEL
GU ISEPPE SEL VE
SHARAD C. SETH
ED SHARP
DAVID ELLIOT SHAW
wiLLIAM F. SHAW
BEN SHNEIDERMAN
JAMES P. SHORES
LEO J. SLECHTA
BARRY SMITH
BROOKS DAVID SMITH
ROBERT J. SNYDER
THOMAS C. SOCOLOFSKY
MARY LOU SOFFA
N. SOLNTSEFF
DAVID SOLOMONT
MARCO SOMMANI
NORMAN E. SONDAK
STEPHEN SOULE
HENRY SPENCER
RICHARD D. SPILLANE
ROD STEEL
EDWARD STEEN
GORDON A. STEGINK
HAL STEIN
ALBERT STEINER
ANNE STOCCO
A. I. STOCKS
JOHN P. STRA iT
GEORGE O. STRAWN
ROBERT A. STRYK
PREBEN TAASTI
RAMeN TAN
ANDREW S. TANENBAUM
DAVID TARABAR
H. TAYLOR
JANET TAYLOR
RICHARD TAYLOR
WILLIAM P. TAYLOR
MICHAEL TEENER
R. D. TENNENT
TED TENNY
GAY THOMAS
RON THOMAS
JACK THOMPSON
LARS-ERIK THORELL I
LAVINE THRAILKILL
ALAIN TISSERANT
STEPHEN TI TCOMS
NOBUKI TOKURA
HOWARD E. TOMPKINS
ALFRED I. TOWELL
ASHOK N. ULLAL
BR IAN'll. UNGER
JOHN URBANSKI
INDUL IS VAL TERS
J. J. VAN AMSTEL
ANDRIES VAN DAM
PATRICIA VAN DERZEE
H. VAN LOON

78712
40122
68588
84112
94022
01754
20742
06320
55165
97221
53211
46202
48823
15260
L8S 4K 1
02155
1-56100
01609
T2N 1N4
M5W 1N5
07470
97077
01852
49401
47401
60201
Nl G 2'111
70504
55455
50011
55424
DK-9000
18016

ITALY

CANADA
ITALY
CANADA
CANADA

CANADA

DENMARK
THE NETHERLANDS

01701
KIN 6N5 CANADA
75275
80212
94550
90403
K7L 3N6 CANADA
13676
39762
55425
62025
S-100 44 SWEDEN
40506
54042 FRANCE
18017
500 JAPAN
15701
47401
0-7401 GERMANY
T2N lN4 CANADA
55403
55406
THE NETHERL ANDS
02912
45036
THE NETHERLANDS

T. J. VAN WEERT
8131 THE NETHERLANDS
J. VASILIOU JR.
03324
ROBERT D. VAVRA
55113
B. VENKATESAN T2N 1N4 CANADA
EI iTA WAOA
113 JAPAN
WILLIAM M. WAITE
80302
TERRY M. WALKER
70504
RANDALL W. WARREN
55440
SCOTT K. WARREN
77098
M.ASARU WATANABE
222 JAPAN
GEOFF WATTLES
55414
JOHN A. WEAVER
18018
NEIL W. WEBRE
93401
WALL Y WEDEL
78712
W. WEH INGER
7000 GERMANY
RUTH WEINBERG
ISRAEL
LEONARD H. WEINER
79409
STEVE M. WEINGART
55113
JOHN WERTH
89154
JOHN P. \~EST
30332
TERRY E. WEYMeUTH
68510
GEORGE H. WILLIAMS
12308
JOHN H. WILLIAMS
14850
GARY'll. WI NIGER
94088
GREGORY J. wiNTERHALTER
30092
NIKLAUS WIRTH
94304
DAVID S. WISE
47401
BILL WOOD
55455
JOHN D. WOOLLEY
98006
JACOB C. Y. WU
20910
STEPHEN W. YOUNG
47401
L. W. YOUNGREN
55901
GIDEON YUVAL
ISRAEL
RU SSEL L 'II ZEARS
77550
PETER H. ZECHMEISTER
55117
E. C. ZIMMERMAN
44691
WILLlAi~

C/)
("'")

:J;>

r:z:

rn
::E:
C/)

r-

rn

-I
-I

rn
;:0
~

en

:z
0

<
rn
3:
tJ;::!

rn
;:0

.......
<.D
""-J
O'l

-0
:J;>

GO>

m
v.a
N

Indexed Fi

les~

by

s~ Knlldsen, Institllt fur TnfnrfTl;-ltik
E. T. 11., !'urich

trilnslated hy

J~

H. Loesch,

f1niversity of

i~ called to initialize the rC'"',m('nt~rl
file tl ) ,
it
is ai<)o possihle
to
c:onRtruct,
r(>aci,
nnd modify indexed files. This featnre corrl."
in COr. SCOPE tcrl'1inol:1~y_ Tn contrast to sC7,rnenteri files in
'''hieh il se(~r.lent can he Incaten throu~h the uSC" of
se~~rncnt
numher
relative to t!lC previons scg''1('nt, a se(~r.1ent of an inrlE'xed file. cnn he
found
through
the use of a specific s~r.lent reference adrircss (a
so-ca1l.ed r,qnrlon index), which is returned from the systen durinr, the
·.vrite operatinn.

!1ccL':trilt ion:
 ::= inoexcrl fil(>.!2.f 
Example:
ift.

!.YE£

=

indexed file

~

.1re

not

positions f at the be~innim~~ T~is 311mvs the fin';t of the
deserihen hy the file to he rean ..

se~Ments

RE\1HITE(f) initiali.zes the writins; of a new se~rnent
file f .. T!H~ new s(~~['1('nt
i~
thcrefor~
not

the enn of the
\Jritten
at the

;"It

h(>'~ i:1nin\~ ~
f"lliSt

location is returned in

~

lodex:
i, k:

arr~y

[1

intC';~er;

•• n] !2i t;
p: hoolean;

Uritc an indexed file f \-Jith n se~rlents; the reference
of eaeh se~Ment is f~aintainerl in an Rrr~v of indiccs_

address

rcwrite(f);

LQLi:= 1!!2

n

1£

heg in
while p no
he~ln
(* fUl fT *);
put.e~(f. index[i])
~

put(f) cnd;

=

re\']Tite(f) ;

while p Q..Q..
(* fill fT *);

k~

Scqllcntially rend an i.ndexen

enn;

fi!c~

resct(f) ;
\-111i1e !l0.! cof (f) ,QQ
hcgi:l
"hile ~ cos(f) '.!2
he?,in
(* inspect fT *);
,\ets",,(f)

p,et(f)

enn;

end
\.,ri

th index k ..

getse~(ftk) ;
while not eos(f) do
he",ln
(* inspe~ fT *); ~et(fl

REURITF.(f ,k)
initializes for revnitin~ the se(~ment with inricx k. k
r:mst he  n rewrlte operation.
.:if:. If :l segment thA.t i.s 10n~~Qr than the orio,inal se-:!,Jllent
rc\nitten, s(>~~I!lf>nts follmY'im~ it l1.1.y he ovenlTittcn~

rewriter f. k);
Jt.b..ilg p ili1.
he?,ln (* fill fT *);
f'tltsc'1(f)

i~

put(f)

putse,; (f. k)

Read n ser;Mcnt

he called ,,,hen  cannot he- char: tnnexeri textfilcs
irnrlenlented.

RESET(f)

An

ARTICLES

2

(FORnAL SUBnITTED CONTRIBUTIONS)

What I propose is that we (the User's Group members) begin to discuss what is
needed for the proper administration of PASCAL.

The Need for Hierarchy and Structure

I initially suggest that

z:

we adopt the following proposal:

rn

in Language Management

::0;:

by
G. Michael Schneider
Department of Computer Science

r

Standards Committee composed of about 10-15 members.

rn

This committee must initially perform three functions:

--i
--i

rn

University of Minnesota

1)

Attempt to seek formal recognition for itself

2)

Certify an official PASCAL standard.

structure and organization of statements within the PASCAL language but so

the PASCAL report, it should clear up certain

By this I mean that there is currently lacking a formal administrative

hierarchy for the handling of questions relating to language standards,

language management could easily be handled by doing whatever you wanted to or
Disagreements could be

The usage ot" PASCAL has, I bel ieve, now left this embryonic stage of development.
Merely witness trn nearly 500 members of ,he PASCAL Users Group or the dozens
of Universities now using it as their primary language.
Yet while the growth of the language has been phenomenal the administration
I t has remained a loose knit, informal mechanism
This is a

chaotic way to administer any large system and, worst of all, leaves the
language open to chaotic, unstructured growth.

It is also frustrating.

to the language?

To whom do we submit our "beautifully lucid" arguments on
Currently there is no one.

This groundswell of frustra-

tion was clearly demonstrated by the dozens of letters received by the Newsletter
shortly after it began, which described suggesteG improvements or changes.
few of the suggestions I felt were good, most quite bad.
the important point.

A

That, however, is not

What is important is that these letter wri ters had been

searching for a vehicle to formally submit proposals and immediately leaped at
the Users Group and its publication as just that vehicle.

The committee should now accept and consider suggestions
from throughout the user community.

It should solicit

opinions and arguments on the proposal, evaluate all
suggestions in light of the stated philosophy
of the PASCAL language and decide to reject it, accept it
as a new standard, accept it as a standard extension, or

Major decisions could be put to

a vote of the full membership if necessary.
The above proposal omits a "great amount of detail that can be worked out by
the committee and the membership.

:z
C>

<

rn
3:
tJ::I

It would be presumptious of me two impose

any further my own feelings on how such a standards committee should operate.
What I care about are not really the details anyway.

I care about bringing

order and structure to the area of language management -- the same goals that
PASCAL brought to language design.

But, the Users

Group has absolutely no official status as the arbiter of language standards.
The needed administration is still lacking.

standards, and a formal procedure for submitting

postpone any decision.

To

whom do we submit suggestions on changes, deletions, improvements, or extensions

what needs to be done?

philosophy to be used in evaluating proposed
proposals to the committee.

of letters, telephone calls or over coffee.

composed of the creators, users, and maintainers of the language.

(e.g., dispose).

Draw up a "constitution" which spells out the role
of the committee, its term in office, the

When PASCAL usage was small and consisted of only a few installations,

of the language has not.

IIgreyareas"

3)

specifications, and extensions.

settled by simple exchange

Whi Ie this

will probably be the specifications found in

little to the structure and organization of the management of the language

by verbal agreements among all parties concerned.

;:0

with such groups as SIGPLAN, ACM, and ANSI.

1 find it quite ironic that so much concern is being paid problems of

itself.

C/l

The PASCAL User's Group nominate and vote on a PASCAL

(*Received 10/1/76*)

rn
;:0

2.

Un the suitability of a Pascal Compiler in an
Fortran.

ttndergraduate teaching environment

It was bclipved that this henchmark would saturate our

:z

system.

Defore Pascal was adopted by my parent department for leachinu purposes.
it was ner.essary to demonstrate that a suitable' eompill'f was availablc.

rn

The twnchmark consisted of runninu 7fl johs as rapidly as possihle from

15 terminals (5 from ('aeh terminal) with no oth"r users on the machine.

The

::c

,

(/)

We hav(' acress to a CYBER 72 runniny a timesharing service under NOS and

experiment was repeated 4 timps for each languau(~; f'ar.h tim!' with a different

rn

const'que'ntly acquired from Zurich the 60UO -3.4 compiler.

job.

-1
-1

The pl't'formance

The amount of real time elapsed was measun-'d in cach casco

These figures

of thp compiler during installation gave rise to a great deal of optimism and

include the time for terminal I/O which was "xpected to be small by comparison

a few reservations.

with the total time.

The optimism stemmed from the quality of the compiler;

a Zurich Pascal compiler with local mods (but not 2c above)

These problems were almost entirely caused by the change

an FTNTS compiler

in the method of use of the compiler not by defects on the code.

an ALGOL 4 compiler via a procedure file which included utilities

Tile local modifications were all introduced with anr purpose in mind La

for handling the line number problem.

facililate the usc of Pascal for undergraduate teaChing.
Th(! modifirations can I)c roughly divided into two

~atcgories.

;;0

for the cxpcrimpnt we used:

Lhp reservations from a few obvious problems caused by the change from

SCOPE :l.4 to NOS.

and

15 'volunteers', many of whom had never used the system before.

Jobs 1 and 2 involved similar programs.

I. Modifications to ease the use of Pascal

aJ the compiler ignores learling I ine numbers

altered to introduce a compilation faull.

bJ compilation diagnostics are sensible with the L-option

Jobs 3 and 4 are related in a similar way.

cJ post-mortem dump output is re-formatted for 70 character wide devices.

student exercises.

dJ dayfile messages were re-ordered so that the faul t reason appears on

Results

In Joh 1 the program was

Job 2 compiles OK and is executed.
The programs used were genuine

The 'same' program was use<] for each language.

Job

eJ terminal control introduced - a user interrupt will produce a post-mortem

Number

Algol

2

1956

numbers not core addresses
Modifications to improve throughput
a) A G+ option to automatically enter a correctly compiled program

3

il46

4

2.967

*
22.0

unsatisfa. tory.
Modification 2c was included and experiment repeated.
These figures are interesting for two reasons

To minimise store requirements we wish to run Pascal in REDUCE mode,

I.

the improvement from 'l:!6 to 153 for Job

and under NOS the KRONOS 'trick' to avoid field length reduction

2.

the Cacl thal Job 3 look less time that Job

after a relocatable load does

~ot

work.

Fact

c.J Output buffers which aff' on-line to a terminal are not flushed by the
Pascal run-time system at the pnd or a run.
sharing system.

The results

were 153, 155, I'll and 201 seconds res pee t ively.

Note

This is left to the time-

This change was made as the result of a poor benchmark

performance.
To demonstrate that the performance of the compiler was satisfactory
a simple benchmark was designed to compare Pascal with Algol 60 and

::s:
;;0

*The Pascal pxperim(!nt waS terminated as 1.h(' p('rrormanct' was

This reduc.s the possibility of rollouts which may be caused if a

o

<
rn
rn

Time in seconds for
Fortran
Pascal

701

dump.
fJ the post-mortem dump gives tracehack information in terms of line

bJ A IV option. which allows ·the use of blank common for slack + heap.

:z

0:1

the terminal.

memory request for an increase in field length were made.

rn

1 can be 0xplained by thc! introduction of the extra modification which

reduced the core <-> disc traffic by
75 x 4 x 500000 words per benchmark
61.4 million characters
for the benchmark inv()lving compilation errors.

PASCAL Potpourri

3.

Fact 2 can be attributed to the human learning process.

by hichard J. Cichelli

As the

Z
rrt

experiment prO\lressed the volunteers were able to type the commands fastN

Tories ror the PASCAL U3er:

because they wrrp more familiar with th(! system.

In fact the performance of the Pascal compiler is such that the figures
presented for the second experiment can only be regarded as a lowc~!!.':!.'l
on the throughput b,'cause the terminal I/O
proportion of the

tim(~

Il0W

accounts for a significant

Direct access file3
"Standard" PASCAL
Software tools

measured, e.g.

in a faulty compilation benchmark:-

no. oj characters typed by human at a termillal

= 65

Direct Access Files for PASCAL

" system at a terminal = 540

The following is presented as an approach to direct access

assuming typing speeds of 3 and 10 chars/sec. this accounts for 76 seconds
at every terminal.

It seems likely that the system is not being saturated

by this benchmark when using Pascal.

files in PASCAL.

We begin with a discussion of current PASCAL

file facilities.
Sequential Files in PASCAL

Conclusions
I.
2.

The performance of Pascal is satisfactory
These figures represent a lower bound on its performance.

The PASCAL Revised Report defines only sequential files for
More

accurate figures would have required the use of a greater number of
terminals (to saturate the system) and repetition of the experiments.
In the context of the experiments this would have been a waste of time.

PASCAL.

Thus, a file is a sequence of zero or more items of the

same type.
aeflned.

A window, or buffer variable, into the sequence is
I t is referenced by a buffer pointer.

of a file may' be accessea at. any ~ime.

Only one element

A predicate EOF (end of

file) La defined such that when it is true, the operation
A. M. Addyman

WRITE (

 ) or PUT

is false,. READ «
p03sibie.

file item>

«buffer variable'»

during a sequence of READs

(*Received 10/4/76*)

I f EOF

or GET (  ) is

As a ,:,lde effect of the READ and WRITE operations, the

buffer peinter la moved through the sequence.

pointer.

is valid.

~ih'"n

EOF becomes true

no i terns remain beyond the buffer

;'OF rerr..'lins true after a WRITE.

The operations RESET and

REv/RITZ move the buffer pointer to the beginning of the sequence.
PASCAL sequential files look like

tape~.

Cl

<:

3.
"Co

A "lor.g" arra:i

wi~j

be cne which migilt reside on direct access

se .:!onda ry mas:-; s t orabe ..

MJSc JT.a;5s storage based

Clperat;~!1g

"ystems present files to

the user a0 named data sets (i.e. groups

or

associated under a cataloged ;;ame ir. a directory).

The user can

request access to a data set by supplying the system with its

Dame.

ConsequenC€D of the Notatiun

related items

Treating direct access files au arrays requires only relative
r~cord

I/O capao, 11 ties froP, the opprat.ill(; 3ystem.

It seems to me

that this provides the pctentlal for all direct access facilities

PASCAL sequeGtiaL files are easily proifided in most
at the most fundamental level.

operating ,;ysteru.3.

it suggests that such advanced

However, the "ae,t majerity of third generation
not.l.ons as "indexed sequential access" will have to be implemented

operating syscems give the user an alternative to the tape-like
fl1e organization capabilitieil of PASCAL files.

allows data

item~

to be a:cessed directly.

Th~s

a"ternatil1e

by the programmer or as utilities in terms of the above pr:imitives.*
Implementation Details

That Is, if the Ilf'ile"
Direct access files are used in two basically different ways -

cansist3 af 1080

ltems~

the user can access the 439th

wi~hout

as bulk temporary work space and for fast, non-sequential access

passing the 433th or rewinding from the 440th.

to permar.ent data u:;ing Keys based upon content or relationships.

For direct access files there is ,no notion of a buffer
po::'r.tt;r J aed thuS there is no EOF',

may be read cr modified "in place".

P.ESET,

or REV-TRITE.

To serve the first need, the long array can simply be a local

a

array variable.

[T1

Any item

<:

In a 'Jirtual memory enVironment the word "long"

READs and WRITEs can occur
might be ignored oy the compiler.

in any orde r.

As far as the programmer is

concerned, this type of long array 1s equivalent to a (possibly)

The neareoc notion to

t~is

idea that 1s defined in the PASCAL
~lo~

Report 1s tnat of arrays.

access array.

I pro,Jo3e to extend the PASC.ilL arr:lY

concept to provide oirect access

faclllti~s.

F~r

•

the second case, long arrays are global to the program .

I'hey w.lll be named as formal file parameters in the program

To

acc:omodat~

tl:i~

extension to the languagE::,

propose that

headin,,~

just

3S

global files are now.

Their declarations will be

':.he t.ype declara':.ior. for arr-JYs be exter,ded fr0ffi

in tr.e variable declaratLms of the program, or level 0, block.
I!' a long array file doesn't exist when a program declaring

:t is executed, one should be created (and should remain upon
to

program termination).
Thl~

1T,e t;-;.a t ~~Offit,"Jne t.as already iIr.plemeritcd i:-.oE!xed
iG PASCAL. Fro~ my co~versations wlt~l him, 1 de flot
believe I ~~ duplicati~g thi~ eff~r:.

-r--Ar.dy informs
~ile3

If one does exist but is incompatible with

13 quite 2:ffiple. A relative record file (long array) is
usee for the recordS and another is used for tne related index
~hich maps ;rcm ::rimary key de:;ignator to the record number (1.e.
lOng array "ndex).
Both a rrays might be JT.apped into th<; same
sy;:>,::em file by uSing record va riant parts for array elements.

4.
Co.:c lusion
the program definicion, a ratal error should result.

Other fatal

I .ouggest that the concept of "long arrays" is sufficient

error condlt!ons will ari~e if the actual fil~ is sequential or
if it

Is the wrong size (1.e. any type mismatch).

for direct access rile facilities and is consistent with the
design goals of PASCAL in lts simplicity and clarity.

,

(.I)

be used to '-';,:uide the compiier
Scvera"i programmer n'Jtatlons '"o'uld
...

rr1

in

m~ping

the data items into efficient

s~ore.

For example, tne

-;
-;

Standards and the Language PASCAL

declaration "PACKED LONG ARRAY" might cau[;e the compiler to try to
block the records efficiently.

By extending the dollar Sign

rr1
:::0

The standards game is one played by programming language

comment notation, the progralT'Jner might suggest blocking factors

users.

and the number of core resident direct access record areas.

language features.

User Interface

Those with problems in search of solutions look for new
Those with programs searching for customers

with problems look to enforce standardG.

Long arrays will be used exactly like in core arrays.

Of

We PASCALers should

have a total view of the standards problem.

We should realize that

course, a long array of files or a long array of long arrays

no existing

can not be premitted.

stated goals and that no language has succeeded without a

Other than this obvious restriction, a

long array will be like any other array.

Access notation will

be ldentical.

standard.

prograrr~ing

language standard is a success at its

With respect to standares, PASCAL has significant advantages

over the popular poorer languages.

l'here is one glaring disadvantage with this scheme, however.
vmen a programmer wri tes expressionc using long array elements,

the Revised Report and not in some vendor's implementation.
Second, as a language it seems particularly easy to formalize in

he may invoke signU'l cant overhead .,. and it will be almost

a humanly understandable fashion.

completely invisible to him in the code text.

regular syntax.

The phrase

"long array" just doesn 1 t ~uggest long moments of computer tojl

to the programmer,

The best sort for a long array may in nc way

re3cmble the best for an in-core array.
I suspect however, the days of slow access rotating magnet.ic
* storage
a~e limited. Solid state bulk memory seems destined to
overtake disks. Our notation may De more appropriate for the
future than the present.

First, it is defined only in

In short, it has a small and

t us ccnsider the population concerned with PASCAL and

PASCAL standardization:

language deSigners, language implementors,

program writers, and employers of program writers.
Language DeSigners
In our case, this is Dr. Niklaus Wirth.
what he says it is.

'J

m

Do We Need a Formally n;cognized Standard?
Le

.......
LD

He says PASCAL

~

But, in fact, PASCAL is too important and

too widely used to halle its scope defined and limited by one man.

b.

We all h:'.ive a leglt..:imatr:: cay in this and
our rl..'spnns.ibiljty.

WE::

can and should

7·
Usc,rs: Manage rs and Pro!:>ramme rs

~:xtrelse

For 0bvious reasons., organi :3ations ar,d their representatives

I!:: 1;..; important, however, to recugriize that

the CClrrrnt succ,,";<; of PidCAL is based on ics eloquent desigll.

(1.e. managers) want standardizat.ion in a programming language.

We must seek t(,

Every organization has learnrd Whitney's lesson about

p:·,,".~rve

l~s

s:Jupliclty and clarJty above all else.

interchangeability.
Dr. Ur;\ Ammann and his group implemented PASCAL in an efficient
and robust faHhion on the CDC 6ClOO computt:rs.

In prograIl'.rning thL:; means adheref!ce to

*
standards.
Programmers have problems to solve.

Becauae many users

There are things which

confuse a progra!llJl!ing language with it" particular implementations.

could be added to PASCAL that might make one programmer's job

Ammann's fine implem"r.tations have been t:'e wellspring of PASCAL

easier.

user growth.

Frankly, some languages are better than PASCAL for some applications:

BecaCl"e many iml-'lementors have followed Ammann's lead,

The problem is to address the entire user community.

it is likely that the PASCAL compller is the most efficient

use COBOL's Report Writer for reports, use SNOBOL for string

language processor at any shop which has one.

manipulation, etc.

Implementors desire standards to guide their compiler writing.

PASCAL can't be all things to all people and

still be Simple, concise and easily implemented.

Remember the

Frequently however, in order to interface or compete with existing

pL/I syndrome - multi-million dollar compilers won't solve

languages, they stretch or relnterp ret the standards to meet real

anyone's problems.

or imagined user implementation needs.

software as more programmers learn how to do more things Simply.

Implementors and compiler

maintainers snou1d take great care not to let ad rwc patches to an

Getting a Recognized Standard
A standards cOllun.ittee should be set up. (I would particularly

impJementation become de facto changes to the language standard.
Fortunately, no hardware vendor has trh'd to make PASCAL
its own.

But we all know that PASCAL will soon be a vendor product.

This should not be
~nstE::ad

·J.iewt~d

as augurlng potentlai corrupcion, b'..lt.

as a sign Qf maturation.

We should recogniz'! it as such

and provide VerdD1'S with an excellent standard to work from.
pen,onaEy anxicusl.y await th-= day when Seymour Cray, Gene Amdahl,
and Ken Olsen market

PASCA~

machines.

There is a revolution coming in computer

like to see Dr. WaIte as a member.)

This committee would represent

users and designers first, implementors and vendors second.

Its

purpose would be to get a document approved by both PUG members
ana the ANSI-X3J3 committees.
also desirable.
4

International standardization is

Additionally the committee would be charged with

It is the naive manager who thinks hardware vendors desire
standards. As the current efforts with big languages indicate,
all they want to do 1s exclude the competition.

I.N
l.D

8.
certifying that a particular implementation conforms to <:he

PASCAL Compilers

standard.

Currently there exist PASCAL compilers

Only with formal recognition wi 11 PASCAL be adopted by

code (PASCAL-P).

There 1s danger is having a committee for thit; purpose.
When COBOL was being designed two commIttees were formed.

~Ih.ich

produce absolute

cede, relocatable code, macro code (PASCAL-J) and interpreted

large conservative organization" and selfish vendors.

,

9.

Since

Portable ver:'lons exist (PASCAL-P and PASCAL-J).

Compiler trunks exist.

A standard PASCAL subset (PASCAL-a) exists.

For compi1er writers there should be a standard PASCAL

the problem of business data processing was regarded as so big,

language test set.

one committee was asked to deliver a 'luic), interim report to

(,xercise Dew PASCAL compilers and help implementors gain

use to"make do:'

confidence in the correctness of their complIers.

language problem.
was COBOL.

The second committee was to solve the DP
The first committee report is in - its product

We are still waiting for the long range committee's

report.
'The new FORTRAl\ is an

obvious disaster; the PLjr standard is an abomination.
better~

An interactive interpreter should be developed.

We can

We need be ne!.ther upward compatible with previous

errors nor a vendor's puppet.

We can do it right if we get

together and try.

important tools for any shop engaged in language development.
Source Program 'fools
~

reference program.

As PASCAL i3 l. CLEAR EOLN FLAG IF SET
WHILE Ie~CPw DO
(* FIll REMAINDER OF WOR) WITH BLANKS .)
REGI'!

*'

1:=1+11
C HtlUF( I J : =~ _

~1I>:ED

r-

Here is the focus of the survival of
pI'ogrammers to access and

USE!

PASC~,L.

scientific

co~munity

If it is possible for

the vast library of FORTRl'N m3them2tical

routines that have been developed, then

th~r2

is hope that the

(*$T •• P·.t+.U+.xO

HEAO

~NC=

COLUMN ALFA IN FIXED FORNAT.

=

HAGERTy *)

desired.

The inertia and ecological success of FORTRAN is too

great for any naive competitor to survive and thrive.
note many PASCAL compilers produce assembly code for their machine.
IBr~704o!

Still, the approach does allow mixed languages at

~ssembly

1:=1+11

== _

(For those who marvel at this, know that no

be (B6700 integrity relies on softl'Jare), and knolJ that the structure of
the executable code fUe would requi.re an elaborate assernbler to specify
81)

that is necessalY < • • )

EJurrougi1s fUgol is the lowest level of the B6700.

Consequently acelievement of mj XEd languages requires either compilation
into Algol (disregarded!) or' tele construction of structured code-files
that are qui te illcredibJ y cornplex by the standards of monoH thic machines.

1:=01

PEPEAT
I : =I + I ;
CHSUFl Il : =F+:
GETIF);
UNTIL (I=NC) OR EOLN(F);
WHILE IeNCPW DO
(* FILL REMAINDER OF WORO WITH
REGl"J

language exists.

computing centre director would want one for the security risk it would

BEGI"J
IF EOFIF) TrlE'J
BEGIN MESSAGE(~* TRIEO TO READ PAST EOS/EOF~)I HALT END:
IF (Nce 1) DR (.'JC>NCPW) THEN
BEGIN MESSAGE(~· ALFA fIELD WIDTH ERROR~)I HALT E'JOI
IF NOT EOLN(F) ThEN 1* COLLECT ;NC~ CHARACTERS ~)
BEGIN

CHi:'UF [I J :
ENDI
PACK(CHBUF.l.A)
ENO:
END (* FpDA ");

(ii) ease of use of the joint systern.

On the Burroughs 86700, the pI'oblem is rnuch more significant as no
~)

The binder in fact has to be abl8 to re-arrange code (especially in the
outermost block) for own and pre-defined objects; associate names;
r.heck parameter compatibility; and all this for ALGOLf-ORTRAryPLlI/COBOL'BLAN~S

-)

;;0

If this is not possible (to mix languages) then even this slim

hope must fade away.

INTEGE~)I

I~ NUNBER OF CHARACTERS IN A WORD
CONST NCPW
Iv;
liAR I: INTEGE'l;
CHHUF: ARRAYll •• NCPwl OF CHAR:

rn

might be encouraged to transfer their skills and

little cost, but some attention must then be paid to (i) efficiency, and

PROCEDURE FRDA (VAR F: TEXT; VAR A: ALFA; NC:

-i
-i

effort into PASCAL from FoRTRAi'I. A tremendous benefit, and greatly to be

Shades of

END
RDA ") I

(/)

LMJGUl\CES

rn

r

ENOl
PACK(CH8tJF.l.A)
(*

THOUGHTS ON PASCAL

?\R I SIrJG OUT OF

(. NUNBER OF CHARACTERS PER
CO'JST 'JCPw
lui
VAR I: INTEGERI
CHHUF: ARRAYIl •• NCPWl OF CHARI

END

~ENERAL

*)

at least.
Nevertheless, even in this case, t.he Elchievement of mixed-language programming
must be atte;npted.

Even rnore must this be the case in simpler situations;

the only exceptions being rnono-languagE systeiT1S such as Brinch-Hansen I s.
Ami these are nat address(>d to the same purpose as viable general-utility
cOllpilers.

Cl

<::
rn

It is

i~tJ[J:-tsnt

to realize that standardization is nat a good in

its~lT';

INCLU~Im:

OF SOURCE TEXT

The 86700

co~piler

has a featuc2 (as with all 8urroughs compilers) for

including source te:.;t fro:n a named file in the cOi11;Jilation.

th2 preS2i1t j2nefits to computer science of standardization are

The included

(1) tr2n5feI'abilitv of skills bet.ween compilers,

text may be, but is rlClt usually, listed.

(2) portability of programs written in standard languages, and

files, up to nesting depth dEfined by the numb2r of file buffETS reserved

(3)

exchange and development of compa tible compilers is made m:JI'2 easy.

(in the PASCAL com;Jiler: a depth of 6).

It may include further included

In fact this is used as a structuring

aid in the 86700 PASCAL compiler source, which consist of some 2Q-30 files
It must be realized that the semantIcs of the language is quite as important

(some with alternatives) linked into a tree-like structure by inclusion

as the syntax in realizing objective (2), and in this regard there are

references.

any number of difficulties in standard PASCAL.

(in PASCAL source of course) as in special i/o routines, mathematical
routines, graph-plot routines, etc. It may postpone the need for the use

First of these is perhaps character set.

of relocatable binary or linked versions of PASCAL programs •••

Except for those computers that

persist with 6-bit characters, the EBCDIC and

~

character sets must

be regarded as the de facto standards of the industry.

All PASCAL compilers

should have the capability of working in either (preferably both) of these
two character sets.

The facili ty is elso useful for including library routines

Tile B6700 construct is a compHer option: it appears on a single line
which. begins with a $, and has the followi.ng syntax:

The implications are that no-one is justified in

inventing a new character set, nor in allowing any other character set to

_ $ _ INCLUDE --:;.-' filename

be used unless it is a. firm committment by the computer/operating system;

L

sequencenumberrange

=oJ

and that even in CDC and other 6-bit machines an effort should be made to
provIde ASCII and EBCDIC characters.

I can think of no more common

portability trap than that of ignoring character collating order.

Pascal-P

$INClUDE ARTHLIR/STANDARDfTYPE:S

was caught.
Another, not so obvious, is the

practic~

of allowing any-length identifiers,

but permitting only tile first flOwn characters to be significant ignoring
the tail.

Examples;
$INCLUDE PACKAGE1

If a program is compiled on a computer with true any-length

Quit!;? clearly, such

8

30000-60000

constr'uct in PASCAL could also be embedded in the

compiler option Wirth has implemented, i f only it were not so restrictive
in syntax.

I

l~C1uld

commend such a facility to all PASCAL compiler-writers,

identifiers (e.g. 86700), then it is quite on the cards that it will be

preferably adhE!I'ing to the allO\le syntax.

compiled incorrectly "by some other computer without warning, as if the

Ii sUng the included t"xt.

names are TEi!;PATTOPOFKILN, TEMPATTOPOFFLUE.

No, identifiers must be

true any-length, or fixed up to a length n with at the very least a mandatory
warning or better an error thereafter.
There are ;r,any more portabili ty traps ulhi ch act so as to limit the
real portc'Jility of programs written on one computer to quite a long way below
that which is achievable at the present state of knowledge.
more attenti8n in the case of PASCJl.L.

They require

I find it infuriating to receive a

program that the author claims is "portable" only to FInd that he or she
is otiviouslV not aware of the most

obvious·requir~ments

for portabilitV.

The default should be to omit

ST Ai',OARDS

Files are PASC;4L's bigQest problem.
are an an:3chI'unisin.

In a mod!2rn context, PASC.n.L's files

Adherence to the P,C\SCAL standard,

int2r;:::r~ting

defined in the Pascal Report, and the

PASC.o.L should have access to randoT-access files

this to 2c3n th2

axio~3tic definitio~s

12ngua·~e
~ust

thereof,

"Jriter/"'2in~ainer.

as well as seouential; should be able to com.nl.Jnicate with terminal devic23

be a very high priority of any PASCAL compiler

as well as card readers and line printers; should be able to at least

are nevertheless several sticky problems which face any pErson in these

specify file attributes; and should have a record-orieClted i/o SUbsystem.

categories.

There

,

C/)

Let me expose them.

1. There is the question of whether to implement a strict PASCAL, or to

On top of this files do not fall into the same class as other VAR objects,

extend it with various features.

Of Lourse there are some areas

since for the most part their life (extent) is not limited to the extent of

where PASCAL must be extended (see later), but every extension provides

the program or a procedure thereof.

a user temptation and reduces portability of the resulting programs.

They may be already existing On which

case the declaration is more of the nature of a specification), or may live

rn
-I
-I

rn
;:0

This works towards implementing PASCAL as she is defined, and that
alone.

on past the program's death (and often t,ave to conform to external

2. Ttlere are the problems associated with undefined parts of PASCAL; for

requirements such as line-length).

example the elaboration of a CASE where the case expr2ssion evaluates
TherefDre all normal VAR operations on files should be carefully avoided.

to a valele not matched by any label.

The assignment and comparisons on files should be regardad as absolutely

something, 8ml these flaws or loopholes in the deFinition are left to

meaningless, as should possibilities such as arrays of files, or records

A compiler writer has to do

individual discretion.
• 3. There are places in F-'ASCAL ,"here the language is seriously deficient;

containing files, and other similar nonsense.

primarily in tI'eatment of files and i/o.
The B6700 implementation will include attribute lists in the FILE type

but can be

decl aration (wheUIE'r in thE TYPE or \/P,R part) according to the following

messes.

Individuality here is necessary

be clea)'ly tendi.ng towards the Algol and BASIC

5E'!m tCl

4. There are places in the PASCAL definition ",here the antecedents of

syntax:

---'.!>-

f"ILE

the present st8te

1:

~ OF

( -7

machinesp,"cificattritllJtelist -?')

J

.-->---

"no",

through, in an unwarranted manner.

Examples

of ttlese are (1) Hie CDC influE'rlce in the curious PROGRAM construct
(often unnec8ssary, and deriving from CDC FORTRMIi), the use of •• or
from Algol in OlrTay declal'atior.s (whell TO is more explicit and less
fJbScul·e), anll H,E' insistencE'

Exampl es:

at the start.

VAR
INPUT (KIND=READER) OF PACKED ARR'W
CODE

t. 0:79J OF

llbjectively,

r1AXRECSIZE=30 ,BLOCKSIZE=300 ,MVUSE=OUT)
OF SECTORRECORDTVPE;

~r

randD~ly,

F.;-"I :IJ1I'i2'j 2nc!

50 this

~:uto"l3ticallv
qu~stiorl ~~es

as far as I am capall) e nf it, it seems to me that PASCAL

ElJlo:.J2d to be

acc~ssc::cj

dune via C:Jlls on

~ll-'CJli

fE:l';:::tion of dialects is inevitable.

Some of the afterthoughts should be recognized as such, and
province of the standard defining ctocum~nt.

re~uved

from the

ssquentiallv

Ilot arise speciFicallv_

attri~J'.Jt~: clEmQr.'s C:'::l b~

It is ther·efore of prime importance that

some procedure be adopted where::'y evolutionary r.hange in the language

can be contI'olled) othentJ:'1 se

of' the recorD of the file is

checked for compatibility with any specified attribute.
All 8;700 fLies arc

0:::'

chance to be era,jicated.
!~:ize

f llRTRArJ' S archaic control character

has in fact been frozer. too soon, bef Ole the rJeFects have had a proper

The attribute list probably has to be machine-specific at the present state
The l!eclarec.l

[Jri

a printed J j ne!

CHAR;

(KIND=PACr;, TITLE=fXECUTABLE/CODE!TEST ,Ur~IT S=ujQRDS,

of' operating svsterns.

[If

t~=

Environ:nent
Ofleratin.;J

s,/~3te,TI ..

(*Received 10/31/76*)

a
<:
rn

OPEN
(SHORT,

FORUM

FOR

MEMBERS
692 1122

DEPARTMENT OF' MATHEMATICS
C~RISTMAS.SAUCON HALL #14

July

PENNSYLVANIA

EXT 3491

~~~
.~t~~.

LEHIGH UNIVERSITY
BETHLEHf':M.

TELEPHONE: 692 3491

IN REPLY PLEASE QUOTE:

Ih~Oi·;0:.i\L CORRESpmWEi~CE)
16015

~

23, 1976

UNIVERSITY COMPUTING CENTRE
THE UNIVERSITY
NSW

"

rn

OF SYDNEY

30th July, 1976

2006

(/)

r---l
---l

rn
;::0

Mr. Andy Mickel
PASCAL Users Group
UCC: 227 Exp. Engr.
University of Minnesota
Minneapolis, MN
55455
Dear Andy:

Pascal User's Group C/- Andy Mickel,
University computer Centre: 227 Exp Engr.
University of Minnesota,
Minneapolis, MN
55455
U.S.A.

What happened to that new PASCAL release announced
las t [-larch?

Dear Andy,

One of my students has just completed a CAl system
in PASCAL.
It features a lesson creation language Which
has excellent expressive ability (it is possible to create
structured CAl lessons with it). The compiler for this
lang'1age is quite efficient.
Its output code is interpreted
by a small (l2.5KS words) PASCAL program. The interpreter
features good run time debugging aids which in many ways
resemble PASCAL's PMD.
.
In addition to the lesson compiler. and interpreter,
there is an object lesson decoder and student monitoring
facility.
The student monitoring routines record and
report individual student scores.
Lessons can also be
set up which administer tests.
The monitoring facility
reports a trace of each student's lesson sessions question
by question.
The system keeps track (on a permanent file)
of each student's status and can be used to sequence
students thru a series of lessons and tests.
In total, the system is the most versatile and
efficient CAl system I have ever seen. To a great extent
the viability of the system can be attributed to the fact
that it was built with PASCAL. Should we write up the
system for the Newsletter?

Please accept an application for membership of the Pascal
User's Group in my name. A cheque for $US4 is enclosed.
Our computing Centre provides a service to the University
and to some outside users. For the past 18 months we have
been developing some of our applications programs in PASCAL.
We have found a significant improvement in the rate of
production of reliable programs.
It is, of course, a
pleasure to write in.
The PASCAL compiler here is maintained by the Basser
Department of Computer Science who make extensive use of it
for undergwDduate teaching and research computing. As
we have to continue to provide software products across
hardware changes, we are interested in the transfer of
PASCAL to new machines and in program writing tools. No
doubt your Center has the same concern.
As we have only had
our CYBER 72-26 for two years it will be some time before
we may have to face the problem.

Yours sincerely,

SJ7:t'
IL .__

Brian G. Rowswell

Richard J. Cichelli

(*Note:

The student mentioned above is PUG member David Englander.*)
encl.

,,-0/]'; ca77l'lNU7lu'eal/,{:~/f'&tJJaclf{/Mtt.Y

2512 San Gabriel St.
Austin, TX 78705
17 Aug 1976

Andy Mickel
Univ Computation center
Univ of Minnesota

Plm·re1'.u"tjt/ ¥ u-Itz.JJnr/f(lJd13
YhmfC7JI O/(J02
COMPUTER AND INFORMA nON SC IENCE

,

(/)

GRAOLJA TE RESEARCH CENTER

(4131545-274'

Dear Dr. Mickel,

rn

August 31, 1976

-i
-i

rn

I would like to join the PASCAL users group, and receive
your newsletter.
am a doctoral candidate in anthropology, and my uses of
PASCAL are for organization and analysis of data on language
acquisition and on cognitive variation. Since programming
for anthropological applications usually involves handling
odball data (when the study is not a simple statistical one),
the ability to strucu~re that data has a rather liberating
effect on one's programmingl

:;a

I

However, I have found the lack of formatted read capability
rather annoying at times. and I wonder if other users feel
the same way. It would certainly not be difficult to add
this capability to the compiler in such a way that it would
provide upward compatability with the Jensen and Wirth (1974)
standard. for example:

Dr. Andrew Hickel, Editor
Unive-rsj.ty Computer Center
227 Experimental Engineering Bldg.
University of ~linn€sota
Minne"po1is, ~m 55455

Dear Andy:

Also, enclosed js a copy of the actual prettyprinting program
and doctunentation~ which is for your informatlofl.

READLN(f. xllwi, X21W2, x3Iw3);
where Xn is a variable of type integer, real, or packed array
of char. For blank fields, integer and real variables are
assigned the value zero. Variables formatted to positions
past the end of line should be assigned zero (or blank in
the case of st:t-ings) or there would be transportatility
problems between systems which truncate trailing blanks and
those which do not. Real numbers such as .05, -.3 should
not cause RDR to halt the program (in formatted or freefield
re~ds)1 Honestly -- you'd think ETH never writeS-programs
whwh have to read the output of Fortran programs (i.e.
statistical packages).
I'm looking forward to seeing my first PASCAl, users group
Ylewsletter -- tell me if there are any dues or anything.

We h;n'c looked at the prettyprinting doc.umentatiou from Leh;gh and
it is not at all along the lines of our prettyvrinting program. Let us
keep in touch.

Sincerely,

~7/0

sinc~r:!JiZAl-4.d/;:t4-.
1fJ
ani ?Lv_~f~
Willett Kempton

(SHORT

J

I liFORriAL

FORUM
CORRESPOi~DEi~CE)

FOR

MEMBERS

-/' _ / /

./

-l-L.1;{ 1'y v-\. ..J::t:;,,-t't-4
Henry ;f,. Lecigard
Associate Professor
IiFL: lms
Enclosure

OPEN

C>

As we discussed on thE' phonc f enclosed is an itero Hhich we "..'QuId
likE' to have :inc.luded in the next issue of the PASCAL Ne",Ysletter.

<
rn
3:
ttl

rn
;:0

UNIVERSITE

C1S

DE

NICE

lABDRATDIRE O'INFDRMATIQUE

N.ce, Ie

16 th SEPI'EMBF.R 1976

PARe VALROSI!!;

8

WEST TEXAS STATE UNIVERSITY
SCHOOL Of BUSINESS CANYON, TEXAS 79016
DEPARTMENT Of COMPUTER INfORMATION SYSTEMS

06034 NICE CEDEX
Te:L,~::4A~

rn

September 13, 1976
Pascal userls Group
clo Arl'ly nickel

C/)

r-

Ur,i versi ty Computer Cen ter

\

rn

227 Exp. Engr.
Uni vet'S i ty of Minr1esota
Hinneapclis, MN 55455
U.S.A.

PASCAL User's Group
0/0 Andy Michel
UCC: 227 Exp. Engr.
University of Minnesota
Minneapolis, MN 55455

1-

-!
-!

rn
::0

.J

. :), ", /\rlCly :

Andy:
Some time ago you sent to all PUG members a set of corrections for
the PASCAL User Manual and Report, Second Eliition. In the process
of moving from Drake to West Texas State r have buried my copy in
stacks of yet unpacked papers. Would you please sendJne another
copy. I would appreciate such.
We are in the process of getting PASCAL up and running on our DEC-10.
r am wOJ;'king without letup on the process of ,converting to PASCAL
some rather open-minded colleagues. I will use PASCAL as the vehicle
language in the data structures course this spring. (Is there any
other way to do it?)
Do you know if anyone has yet to build a really interactive version of
PASCAL?
When does the first edition of the PASCAL Newsletter come out?
looking forward to receiving it.

~.

H. P. "Duke" Haiduk

Assistant Professor
Computer Information Systems

I am

I read with much interest the first newsletter made under your responsibility,
and I was very impressed of the vast ~~unt of useful informations you
managed to pack in it. One problem afraid me : at Sf 1.31 for pcstage costs,
my fec for the group will not even cover them for one year. If you have a
non-negligible number of overseas correspondents, this could be a problem.
Would it not be good to have a ElL."'Opean re-distributor, who could make as
much copies of the newsletter as necessary and send them throughout our
whole old continent
He could also collect fees and keep the part needed
for his own costs. This would be an extension of the suggestion made by
Judy Hullins of Southampton. I am not suggesting that I could do this work,
since \.,e have no really good copying facilities in Nice, but ITBybe somebody

, C>

-<
rn
:3:
ttl

rn
::0

else could be contacted in a weal+hier University. I think that Pascal is a
language which is equally pcpularon both sides of the Atlantic, and that
it would be a pity not to take advantage of this exceptional situation.
The rest of the present letter is devoted to some remarks, comments and
precisions urged on by the reading of the newslette".. Some of them may be
of interest for other Pascalers and In"rit publication in the newsletter,
but I think it would be better that you cb selection and morever a rewriting,
since I know my English has much deteriored since my departure from Canada.
Pascal User's Group session at IrIP , 77 : in the same spirit as
the remark before, I think it would be very interesting to have a "Jorld
meeting after the many national meetings in USA, England, France (more
details beIO'..J), Switzerland, etc. It should be pcssible to arrange something
with the local organizers in Toronto, Or through a TC 2 member. Since IrIP
is a very formal organization, it should be useful to search for some
arrangement as soon as possible_
V1
C>

2

Standa~'d

Pa.scal book by Bill Ah-.;ood : I am somelt;})(}'- a-fraic! by

1j"::1<.::, arld I '. .]ill \,rr)i1-(2
~vi!.''th)

-;J,al zi:r/hody (but
is

t}-!I:.'

s~ciliual~d, I,Jithou~

\'JhaT is exactly

c(luld

b~) V~!!..,V

ideas

dangf:rous

that his own idea of the language

SdY

any dLscussir;.n with thE-c ccmmunil'l of

differ~nt

Ha;l\' p,,::oi'le hav,-;
sub] ".x,··

s0~\.3rately ro Bil~.

I do'nt kno1,v, and I thi.nk it should

PCt~;C31,

St.d:";d.:-ll.'d

the

all

sub'~cct,

Pascal~rs.

and I say mor'e

Oil

the

t,le;,'.':; dboLlt Pascal in France
(ri.:~:,l're

FP--':-:--C~·l-~.Jl __''--\'l~~~lT[,

a~Jd

or:her trench-speakinG parts

lJeslar'dins cO'Jld say much JroT'e than me about the

iJart of i\rer'ica) : I?ascal is llsed i ,1 some import-ant

(n-' :3nallep Universities as a vehicle for teaching programming and

Hl':tirlg

~~oftware,

especially in Paris Clnstitut de PrograrrID::l.tion),

i'0uloust:7 Chi'1er'~i t·} ?a~ll Saba t'ieY'), Bruxelles (Universi t.-~ LibY'e),
Lausa:--,T"le (Ec81e Poly technique

F\.:;d~rale), Morrrpellier, Nice,

Neucha-;--el,

el-C. Som2 impOy'ta:lt un·ive::-.:;ities (Grenoble, Renflf;s) do not us(-~ it

because they have made high investments in either Algol W or Algol 68,
\-\;hi.ch a1.""'e much

~)etter

tools than Fortran and therefore STronger

")bs-;::acles to the s;i.ift to Pascal. Implementations of Pascal have been
fi1::L1e in Gr€IK.'blc on the IBivt 360, Paris on the ell Iris 80 and 10070,
NeuC'h3.tel on the IEl"'! 1130, and one is being made in Nice
Tr'~::.~

5['i. t-'lor(: detaiL:; follow in the "implementation

~.::'esenT

l2't--:_-ep. A thlo-ddyS mEeTing aoou"t-

P~lscal

H

on

crr

the

pari - of the

Took place' in Nice

veaL" ago. Six+y pr:r'sons fpom Fra:lce, Belgium and Switzer1and attenrl.ed.
yo~

11 r?'ceive by separate mail the text of the majority of the papPY's

1.--'11>-'h ·,,-Jere pr·esen:ed. Additionnally, there were panels about the use
of :Pasca.:l if; tprJchir.g, its imi--)1':men-ra-rl0n an.j i :-,s ch<3nges or r:xtensions.
l

;)la[: Lo cr'ga;lize d sirnilat' meeting, ill HaV Of'
par,r~r

P-l)Ollt chr::

very'

usc~ful

l:()li.cy

'vh'ite Tr-li::-rr: in

t[,(-;

iO

1,;1 both

'~;i;:-,::'le 2 ;.j

:;.:, ~;.., 1fOl,'JIl u:3,~;d

JUl'!i--:'

17.

by I:::

,'>

dnd so on. I think the

::mly truly ]'(;i"1ddbJe and aesthetic form, and

that every imp1enentatioL should be free

TO

give its own interpn,tatioll

of the char'dcte .....s which are ;10t avai lable on its pact lcu]ar har'dware,

provided ii confom,s to the geneY'al

rules "tated by \virth himself. In

fact, ar,y implementation language \"hich can be translated into another
one by means of a ol1e-pa£" Pascal pr'Ogram should be acceptable, and this

DC' luv/.

:-,f Lur-Jpc:

letters, ( * and * )

publication

L')n

'LrJrlp;uag(~.

~\lir'"t ~'ll f:

J.0\¥?l'-CdSi--'

~~y IIpub':;'icd~ ion languClgp!!~

book'? dl:d

i~'l

the Pascal repor'ts from Zurich

jy< ters, uf'ldec:i ne,j keyt-Jords, use of

<3.es't_hetic availdble- ch3.racters, such as { and}

a~vi;-;o Oil.

oy

I mean the
eVt~ry

for

r;ornmen~s,

IIhar":lwal""'e or imple. .i'nentatjo!l la>19d,;ig(:II , I ~1.ean the

,Tcr;:';2n & ~'hrth's

book

(becdUS(-~

of

l_~mitari.ons

on the

includes national var'idnts for key-words. In Cichelli' s paper, examples
in the t.ext generally conform to the publication language, corrunenrs
excepted, but figure 1 does not underlines keY",ords and uses a character
SlOt

not particulary readable, and the complete prol'l'am seems to me a good

t~~xdJl1pl

e

()f

unclC'~lined

what Gfiollld bE: !""lever done : only uppAr-case letters, no
keywords,

fc)r strings, 1* .:md */ for corrunents as well as

r-

and ' , and so on. I know well that it is very difficult to have any
secretary to type correct program texts, and that is probably the reason
why Jensen & Wirth's rook was typed by a computer, but it can be done
and I ,Li.nk it is worth the trouble. Of course, these remarks are not
criticisms arom: CicheJli' s paper, which I find very inTeresting and
useful.
Atout the paper by Tirrothy M. Bonham :, I agree arout paint 1.
Ahou':: paine 2, I must recognize that to crj tize Haberrrann arout the use
of " ... " instead of " .. " was a petty point and probably a cri ,icism of the
'·ypEsetter', bU1 I think also tha1 proof-reading exists for rellDving such
errors. 'The symbol " ... II i t:;e If would cause problems in some scanners,
since i, would be the only

three-character'~

I have a llDre impol'tant criticism about 1hC'

delimiter in the language.

cre

6000 (j'Jrnpiler, which

C'onsj riel's " .. " and ": II as equivalent, for some historical and obscure

reason. Thai is prooobly the nBin obstacle ro a vel'y simple and natural
e-X":.ensio!l of rhe case stat.ement, viz. the use of a subr'ange as a case
label, by similary with the notaUon for sets.
About point 3, I think that this long discussion should not
be necessary if the distinction betwe2n publication and implementation
language was clear'ly (lone : if you have the left arrow and like it,
\lse :it; but il is much more uncomm::m than you think, and there are much
llDrc Algol users than APL users on the Eastern side of 'the Atlantic.
About lX>int 4, I agree, rrDre espvcially as the French version

of Fac;('al keY"JOrds uses bas ",nd haut (up and doym) as translations for
to and dovmto. Aboui.- point 5, I disagree, because three different syntaxes

o

<

rn

4

fot' COmITlen::s seem I'c:ally too much. As it is, the current syntax

Pascal have been done for the IBM 1130 afld are iT I use at the

University of Nf.'llchotel (Centre de CJlc'll, C,.antemcor-le 20, Ch-2000

every particular lexical convent ion which may be tpanslated inco tile

Ncuchatc~l,

~'tanriard

\

has

mre Advantages thaI! disdirantages. Once more, however, I think that
one (if 'Ist"andelI'd" is

r\(~dlly

defined) by a one-pa.ce Pascal

S\Fl_tL'.I~rland).

A cO!;1plete and ,:.;tandard cornpiJ er fur fhe Xe:r'Ox Sigrrs 6,7

program should bc acceptable (but not fa!' publication!).

and 9 has been eione: by

PiCr~\2

Pascal bibliography: my translation in French of Wirth's
first book (Sys~ematic programming) is at last 'n hands of the

desirable information.

AI1',/v..Iay,

publisher (Masson). I expect the !lOOK to be released during 1977.
Implementation notes: AlthOllgh CrI 10070 is a nickname
fer Xerox Sigma 7, the ell Iris 80 is another machine, more precisely
an extension of the first one. Moreover, the ell operating system is
different from Xerox and transporting a Pascal compiler from a Xerox
Sigma 7 to a CII Iris 80 probably would not be a trivial job.
A Pascal compiler for both ell machines has been written by Messrs.
Thibault and Mancel of IRIA (Research institute in Informatics dnd
Automatics, a French government agency), by bootstrapping the first

Des jan] ins, \,-Jho can give you all

it se,-:>ms to

b(~

a very good implementa-

tion, especially in the domain of comp'lti!lilil-y anci conformity with
the standapd.

C/)

rrn
-l
-l

rn
::0

I hope that some of these infopmatiens will be of interest
to yo';!, and that my poor EJ 'gl ish will not be a hindrancE,. If you
managed to read this long letter in its entirety, thank you for your
long-suffering. I look fon-HPd to any news.
Sincerely yours,

o

ere

6000 Pascal compiler. It has now been upgraded to accept Standard
Pascal and to allow separate compilation, and it is Officially distri-

buted by IRIA, a case which seems unique. Its overall performance seems
to be quite good, and it is used in French Universities which have one
of these machines.
The ell Iris 50 is a completely different machine, much
smaller, and we have some trouble in Nice when trying to implement
Pascal. Pascal-P presently works interpretatively, but it is unusable
for programs larger than one page, and consequently it cannot be used

rn

-<

rn
O. LECA'l.!'1E

as a tool for bootstrapping a true compiler. I plan to write a brief
y:1pC'r for dC'scpibing the boots·trap method which will be used, and which
seems to be a unique one. Maybe it could be done in time to be included
in newsletter number 6.
A Pascal compiler for the IBM 360, which was probably the
first one, has been done in one of the Universities of Grenoble.
Unfortunately, the people who made it had no time nor support for
distributing it, although it seems to have impressive performances in
execution time (but less good in storage needed for compilation).
People to contact are Messrs. Henneron and Tassart (Informatique &
Matherratiques Appllquees, B.P. 53, 38041 Grenoble-Cedex, France).
Implementations for Pascal-P, Pascal-S and finally full
V1

IV

LNiVAC
INDIANA UNIVERSITY
Research Computing Center

u:\:'Vt.C PARK. P O. BOX 3525
5: PAUL. M::-"NE"SOTA S5~65

Wru~.~~~i~~~~nter

Tn •• 'HON[ lli~~1 u4~·n!il1

BLOOMI~GTON.

September 17, 1976
.\I"'.,J~l

INDIANA 41401

-nL.

NO. I I Z - U ' · I ' I I

September 22, 1976

Mic}\.cl

Univc?rsity computer Center

University of Minnesota
227 Experimental Engineering Building
Minneapolis, Minnesota 55455
Dear Andy,
In response to John Eisenberg's article 'In
Defense of Formatted Input' I would like to make the
following remarks:
1.

I/O statements are usually wrapped
up in a package of confusing motations which
detract from the readability of a program.

2.

:a is not clear that a system routine 'vhich
does ord(ch) - ord('~') would be any'better
than tr.e user's own routine and in addition,
it is unlikely to respond in a flexible manner
cO exceptional numbers (e.g. beyond machine
precision) .

3.

Format~ed

Formatted I/O .':>till does not sol'le the
general problem of number to string and string
,to nlli~ber conversions.

The University of Illinois PASCAL compiler has
a rather elegant solution to this topic. This
L:lplementation of PASCAL allows the user to 'read'
or 'write' numbers or strings to and from arrays
as well as files.
'
Sincerely yours,

PASCAL User's Group
c/o Andy Mickel
.
University Computer Center
227 Exp. Engr.
University of Minnesota
Minneapolis, Minnesota 55~5S
Dear Andy:
Since your visit to Indiana University last Spring and
with some prodding from Al Towell, I've become "hooked" on
PASCAL! ~lith my administrative responsibilities in the center
I have not been able to spend the time on the language that I
would like (i..e. I'm not an "expert" yet); nevertheless, it
is clear to me that the language far exceeds (elegance, readability, flexibility, etc.) anything else that is generally
available. I am gratified to see the formation of PUG (enclosed
is a $~.OO check for membership); if ever users (without manufacturers' interference) have had an opportunity to do a great
service to the comnuting community, this is it ••• we must not let
the language get away from us by allowing local extensions to
creep into widespread existence without a proper review procedure (Eg. a PUG Standards Committee ••• we have a "jewel" here that
needs protection). I also support Hellmut Golde's belief that
the widespread acceptance of PASCAL is dependent on the ability
to mix Fortran and PASCAL main- and sub-programs; Fortran (an
historical accident) can only be corrected if programmers are
able to "grow" to PASCAL gradually.
As my expertise in the language develops I hope to contribute to PUG's primary roles ••• to maintain the integrity and
pronlote the acceptance of PASCAL.•
Sincerely,

te~\>I. Young
~""
Director'

Robert E. Novak
SWY/pce
P.S.

SPERRY UNIVAC IS A DIVISION OF SPEARV RAND CORPORATiON

I know of at least two PASCAL users; hence,
"PASCAL User's Group" should become "PASCAL
Users' Grollp!"

Cl

<:
rn

LEHIGH UNIVERSITY
BETHLEH.E,""

PROFESSOR OF COMPUTER SCIENCE
T. KILBuRN. e.B.E., M.A.. Ph.D.,
D.Se., F.l.E.E .. F.B.C.S .. F.R.S.

THE UNIVERSITY
MANCHESTER

leL PROFESSOR OF COMPUTER ENGINEERING
0.8. G. EDWARDS, M.Sc., Ph.D .. M.l.E.E.
PROFESSOR OF COMPUTING SCIENCE
F. H. SUMNER, Ph.D., F.B.C.S.
PROFESSOR OF COMPUTER PROGRAMMING
D. MORRIS, Ph.D.

OEPARrMENT OF MATHEMATICS
CHRISTMAS·SAUCON HALL #14

18015

October 9, 1976

M139PL

Telephone. 06t-273 5466

29th September 1976
\

PENNSY1.VANIA

DEPARTMENT OF COMPUTER SCIENCE

Andy Mickel
PASCAL Users Group
UCC: 227 Exp. Engr.
University of Minnesota
Minneapolis, MN 55455

Mr.

Mr. Andy Mickel
University Computer Center
227 Experimental Engineering Build ing
Minneapolis
Minnesota 55455
U.S.A.

Dear Andy:

Dear Andy.

I was sorry to read that Dr. Waite initially declined to
Join because of the dues cost. Since I suggested the membership
rate (on the principle that "there ain't no free lunch") and I
regard Dr. Waite as having potentially great positive influence
on PASCAL development, I hereby contribute his dues. I hope Dr.
Waite will use the Newsletter as the two-way communications
channel it was meant to be.

Thanks for the letter and detailed information that you sent. In an
attempt to get this to you by 1st October I have only included the
following:
l. Documentation relating to Pascal at UMRCC
2.
3.

Details of our CDC 7600 implementation
A short note on our experiences with Pascal under NOS
the CYBER 72

all

4.

A copy of the updates to the compiJer mentioned in item 3.
Feel free to use, distribute or destroy! any of these mods

5.

Details of a possible bug in the Zurich compiler. Lack of time
prevents me from finding the cause. so I will only send you the
evidence this time.

I would also like to advertise the fact that I wish to see formed within PUG
a Pascal Standard's Group, which I am wilUng to organise unless a more
suitable candidate volunteers. If I am not overtaken by events I will
contribute a brief outline for Newsletter #l of how the standards group
might operate.
Yours sincerely,

r
j Ii
/;;~,') /0.,<.!./'y "",_.....
,

~I

Tony Addyman
P.S. This will be late - I've been ill.

The first PUG Newsletter was really well done - keep up
the good work.

I enclose an article from the British Computer Society
Bulletin. The article, entitled "Which language?", shows that
within the next five years PASCAL could become the language of
choice for university computer science programs.
I also enclose an article which addresses a mishmash of
topics. In it are presented some frankly half-baked ideas. I
hope the membership can cook them down (by stepwise refinement).

~~

y"O'O,

Richard J. Cichelli

:z
Cl

<

rn
3:

to

rn
::0

-c

»

University of Illinois at Urbana-Champaign
COllEGE OF COMMERCE AND aUS1N!ESS ADMINISTRATION
DEPARTMENT OF BUSINESS ADMINISTRATION' 350 COMMERce BUILDING (WEST) • URBANA, ILLINOIS 61801 . (217~ 333.42.'

en

n

-2-

Andy Mickel

October II, 1976

Second, we do a considerable amount of work in artificial intelligence.

October 11, 1976

»

r-

PASCAL

certainly has the ability to build complex data structures, but these abilities
are rather low-level compared to LISP, or even SAIL.

To do what we do with

LISP in PASCAL, one would apparently have to write a memory-management system,

Andy Mickel
University of Minnesota
University Computer Center
227 Experimental Engineering Bldg.
Minneapolis, Minn: 55455

either garbage-collecting or·reference counting, and then build up a collection
of basic procedures to manipulate the structures. I.e., one would nearly have
to

r~~ite

LISP in PASCAL.

More about this below, under runtime memory

management.

Dear Andy:
I have some further comments on PASCAL, based on my experience as the local
implementor of the Hamburg

DEC~lO

version.

First, On the compiler itself.

Finally, We do a good bit of what might be called "system hacking."

This

includes writing system programs such as a mail system, various programs for

My comments, as published in the Newsletter (No.5) were possibly a bit too

displaying information about system status and parameters, for analyzing dumps

harsh.

of moniter crashes, editors, etc.

They did not make it clear that my objections were to the interface

All of these programs require us to make

between the compiler and the system, not to the reliability of the compiler

many obscure monitor calls and to transform data between the form used in-'

or the quality of the code (aside from one bug in parameter passing - my

monitor calls and usable external forms.

blanket attack on procedure linkage seems to be more applicable to the older

doing monitor calls (since these are by definition machine - dependent), nor

PASCAL compiler, rather than PASREL, the one we are now using).

does it supply the large libr.ary of conversion procedures that SAIL, for

However the

main thing I have to say is that I am unable to report on the usage of PASCAL.
As far as I know there isn't any, except a few computer operators who use it
to do homework that was supposed to be done on the Computer Science Department's PDP-II PASCAL system.

I thought you might find my analysis of this

situation useful.
Much of our computer programming

rather inconVenient.

This really falls into the same category as my complaint

that PASCAL is not LISP, since we are again talking about a lack of run-time
processing.

String processing appears to require this as much as list

By run-time memory management I mean the ability to do NEW

is "peculiar" in one way or another, and PASCAL turns out not to be very use-

repeatedly, without eventually running out of space.

garbage collection, reference counts, or 90me such scheme, as well as an

controlling a robot, or doing random access work.

PASCAL can hardly be blamed

for not having the facilities to handle real-time device control.
even had to modify the operating system slightly for that.

We have

But it does not

rT'1

More generally, the lack of string processing facilities makes many tasks

ful for it.

First of all, we are often doing unusual input/output operations:

o
<:

example, does (SIXBIT.to ASCII, etc.).

memory, management.
Our lab is entirely a research organization.

PASCAL provides no facilities for

This Seems to require

ability to get more memory from the operating system when it is needed.
realize that this is a controversial issue.

I

If PASCAL is intended solely as

an implementation language, it should not supply a built-in memory-management

support random aCCesS file manipulation, or for that matter any non-buffered

scheme since that is one thing that an implementor will want to design for him-

kind of I/O.

self.

But I believe it is unreasonable to expect applications programmers to

include a garbage collector and/or memory allocator in every program.

I find

it hard to believe that any serious use can be made of NEW without some memory

-c

»

en

f'T'1
Vl
V"i

And/Mickel
Andy Mickel

management.

-4-

October II, 1976

October II, 1976

Indeed the DEC-IO PASCAL compiler uses extensions to PASCAL to

keep its symbol table within bounds.

Possibly built-in garbage collection

should be available only when specifically requested.

Then implementors who

SAIL is certainly not the ideal programming language, especially when judged
by the "struc'tured progrannning" and machine-independence ideals that guided
the design of PASCAL.

But I find it hard to imagine myself adopting a language

wish to design their own memory management would be free to do so.

for day-to-day use that did not have most of its features:

the ability to

Also, no attempt seems to have been made to facilitate decoding anything other

memory-management, and a good library of special-purpose procedures.

use all of the facilities available in the operating system, run-time

,

than numerical input items.

I sat down to write a program that would read a

program name from the terminal and then run it.

I knew that I would have to

do the running by a call to an assembly-language subroutine. But when writing
the filename scanner began to look like writing the syntax analyzer for a
small compiler, I gave up and used SAlL.
to use PASCAL.

In fact, this was my last attempt

(Filenames on the DEC-lO are not trivial:

might be DSKB:PGM.EXE[S,731,SAlL,SRC].
gets a default value.

===
en
r
f'T1

Unless

PASCAL can find a ,way to incorporate some of this in a reasonably structured
way, I think it will not get beyond introductory computer science courses.
UnYortunately, pLII comes very close to meeting my goals (especially when
used with OS/360).

Z
f'T1

-f
-f
f'T1
;;0

I fear I may find myself teaching students PL/I when

I had hoped to use PASCAL.

A full-blown one

Sincerely yours,

Almost any part can be left out, and

Also, the bracketed item can come first).
Charles L. Hedrick
Assistant Professor of Busines1t'
Administration

I think the real issue is what kinds of problems PASCAL is intended to attack.
It is Unreasonable to expect any general-purpose language to have the peculiar
capabilities of LISP.

That one could write a LISP interpreter in PASCAL is

possibly all that should be asked.

The inability to·handle messy I/O and

"system hacks" seems more serious, though.

If we give uP. on that it seems to

limit PASCAL to compiler writing and a replacement for FORTRAN.
comings as a replacement for COBOL have been noted elsewhere.)

(Its short-

CLH/jh

z
o

-<
f'T1

3:
t:<:I
f'T1
;;0

The best

language for such things on the DEC-lO is SAIL, a Stanford University
extended ALGOL.

It makes no pretense at machine-independence.

syntax for doing monitor calls directly.

There is a

Any I/O mode available in the

monitor may be explicitly specified (and is handled automatically, so that
buffered and unbuffered I/O can be done with the same higher-level language
constructs).

A huge

library of speciel purpose procedures is provided,

including conversion procedures that allow one to make sense of data in
funny monitor formats.

If all else fails, one may insert sections of

assembly language in the middle of a SAIL program.

Accumulators are freed

for your use, and constructs are defined to let you refer to the address of
array elements, record elements, etc. in higher-level terms.
several data types that depend upon runtime memory-management:
lists, and records.

SAIL also has
e.g., strings,

(I believe these three classes are separately garbage

collected. )
V1
0'>

CI" S

WEST TEXAS STATE UNIVERSITY
SCHOOl OF BUSINESS CANYON. TEXAS 79016
DEPARTMENT OF COMPUTER INFORMATION SYSTEMS

Xerox CorporJ.tion
Palo Ajro Research Center

3333 Coyote Hill Road

::z
rn

Palo Alto, California 94304

(415) 494-4000

,

C/)

Okt. 15. 1976

October 21, 1976

rn
-i
-i

rn

Mr. Andy Mi che 1·
227 Experimental Eng. Bldg.
University of Minnesota
Minneapolis, MN 55455

Mr. Andrew B. Mickel
Editor. Pascal Newsletter
Computer Center
University of Minnesota
Minneapolis. Minn. 55455

;;;0

Andy:
Dear Andy.
Upon reading the last issue of the Pascal Newsleller I was surprised to find that you do
not distinguish between private letters and letters to the Editor. I strongly disagree with
your elimination of this distintion. and fear that some of the writers of the published
letters may resent your zeal for transparency.
I suggest that letters for publication must explicitly be addressed to the Editor of the
Pascal Newsletter (as shown above). and that no other letters will be published.
Yours sincerely.

I have just recently finished reading from cover to cover the
Pascal Newsletter Number 5. You guys deserve a big commendation from all advocates of progress in programming languages
especi ally advocates of PASCAL and its future deve 1opment.
With such a common forum as the Newsletter, perhaps we can
intel'act in such a way as to encourage if not force, a "standara" series of improvements to PASCAL.
--In one of the letters (1 have searched several times for the
specif·ic one) t.here was mention of an implementation of Brinch
Hansen's concurrent PASCJI.L. Could you please give me informati on tonce-Hoi fig the avail abil ity of concurrent PASCAL for the
DEC System - 10. That appears to me to be a desirable way to
go with the operating systems course.
Keep up the good wor·k. I will support you in spirit and continue to send in my mar,dary support for the Newsletter.

Prof. N. Wirth

p~

H. P. "Duk!:'''

Haidu~.

=
o
<
rn

The University of Tasmania
Postal Address: Box 252C, G.p.a .. Hobart, Tasmania. Australia 7001
Telephone: 230561. Cables'Tasuni'
IN REPLY PLEASE QUOTE:

Telex: 58150 UNTAS

rn

INFORMATION SCIENCE DEPARTMENT.

en

Departrno::nt of Maihematics

FilE NO.
IF TELEPHONING OR CALLING

22nd October, 1976.

The Univer:3ity,

South~1,Tipton

I

rrn

Telex 47661
Tel 0703559122 Ext

SOD .5NH.

2387

ASK FOR

-f
-f

rn

\

=
Pascal User's Group,
C/- Andy Mickel,
University Computer Center, 227 Exp. Engr.
University of Minnesota,
MINNEAPOLIS, MN. 55455

COMPUTER STUDIES GROUP

Dear Mr. Mickel,

Dear Professor Sale,
PASCAL NEWSLETTER

October 4, 1976.

Thank you for your long and most informative letter.
two points

Judy Mullins, of the University of Southampton lCL 2900 project. has
I believe been sending you copies of the correspondence we are generating between
.Tasmania and Southampton on the common problems of implementing PASCAL on highly
structured computers (B6700 and ICL2900) instead of the more usual monol ithic
machines. l enclose therefore my reply to the last letter she sent you. in case
you want to include it in the Newsletter. It contains, I think, discussions

~vhich

are of interest to both our Universities as well as) I believe,

the Pascal. community in general.

and

It has raised

:z
o

-<

rn

These are

Wnat brand of Pascal should be implemented?

ttl

How is it implemented on high-level machines?

=

rn

we have had long discussions on these questions, both previously, and in the
light of your letter. Here follow our views.

of severa I important issues.

Some time later I must write a view for the Newsletter specifically
on PASCAL development, for it is clearly going off the rails (clear to me anyway),
A great pity, and something should be done to remedy the residual problems in
definition and to encourage greater interchange of programs and program portability,
l shudder at all those PDPII and IBM 370 implementations!
I enclose also a release on the status of the 86700 PASCAL
compiler, which I ask you to print. It should clarify the situation for any
interested 86700 users on a machine which is noted for the rarity of any new
compilers.

Yours sincerely,

~~at?

We believe~ for better or for worse, in Standard Pascal, as laid down
in Jensen and ~·Jirth. The 1900 cgmpiler which \ole are bootstrapping is a full

implewentation of the Standard with one exception: the Pascal 1 I/O routines
are kept (e.g. write (eo£), ,,'hile not (ch=eo£) do read (ch) etc). Considering
the oess the Zurich compilers got into when Ammann tried to rationlize the
readtn procedure for. integers, \ve consider this a wise choice.

However) Jim

Welsh is proposing to support read£n, write£n in tandem with the other set, to
ease portability problems, To be realistic one must accept that there is no
such thing as a fully portable program, but if the changes are few and well
understood then an intelligent programmer will have a small, albeit irritating,
task to bring an alien program up on another machine. The syntactic changes in
your implementation are good ones

except for the % connnent which reminds me

too muoh of assembler, and the ELSE case label (more of that anon). But if you
allow all these goodies and students get to knOl, of them, it merely widens the
. communication gap hoth bet. . ~een
.
the students and the excellent t-ext books that
are beginning to appear on Pascal, and the students' programs and other machines.

Enels.

A.H.J, SALE,
Professor of Information Science.

Burroughs installations have for many years fed the Algol 60 communication gap.
and gaily ignored its consequences. Certainly, B 5700 Xalgol programs are more

Vl

00

-0

J>
C/)

n
r('ad~:ble

and ucLtcr in ;,31'Y !.""(!,:.:pe..:ts th,,:.n ::.llcir -2qU val.c:nts on conventional
n;:lchincs.
~',~~::. 1:,,']C their i<;e:ls 'c~~:n copied?
~:y.pcr cncc h,1S 8ho\\'11 that
people wi1_! stic\ to 3 SLdnd;~rd un12ss it is quite ntole~abl.e. Fortran is
just in::;i0{' ::.;,.". tul'.:!i·,:iblQ, EASIC (':.8 ciefil:(:a at D.1rtrr.Qutll in 1971) is not:.
Extensions h0'.'il'~'d \";itil th,?: result th<:t: the St.and,:It-c.i~.ltion COfirrnjttee cannot
lbope to proJl.~c,.-' w of
the 1:-:08L pTt"s::iing arc file I/O anddia:!l105tic aids. We .?re tnking the line that
both of tllC~~ ~hould encroach as little as possible on the Pascal source. '~lat
additional ~Ylit~x ~ill be needed [or files on th~ 2970 will on Iv be considered
in a.Dout Jar.v'.:"l":" and I 5h,111 k(~cp you informed. If you could s~nd IDe full
detaiL, of yOur. I/O intcr:f..Jcc, it \d.ll be around at the vital moment 2nd l>.'e can
sec if the 2970 version cnn be made to conform at all.

As regarDs di2.gr.l..~stics} -;~~e a.re lucky here. Glasgow hnve implemented a
diagnostic vackJgc [or sy!~bol table du~ps, profiles and tracifig on the 1900
cor.-.pil,~r an(l ',·;ill bc ructing it cnto the 2900 as soon as our compiler is ready.
(Thc'y tn~c ;'.et~. if:'; .2 2980 c:~n?ntually). The syst(~m is simple and i~dllces minimal
ov<.'~h(:.:tds at c:-:ec1,;tion tir::e.
A few parasitic procedures t-lrite information to
di sc end i!-: t.he' e'·:er.t of a failure, the POEt mort£rn p'rogrcm (t\~ritten in Pascal)
co~e3 in to di~::ect the corpse and produce its rcport.
All v£ry clinical!
I
(:nclc~.;e a copy of Gl.:lsgm.;r's ~oc'J!!:r;;ntation.
In conjunction ",,·ito. David hTatt and
Eill Findlay ~c arc going to ~hange the user interface from the horrible
pragI.:1ats to rrOl"C recognis.:l'Jle direc.tives (proposals attached).
Global octions
will come before tho first hscal stat"",ent (be it CO:1ST, PROGRAJ.! OR PROer:nUREl
e. g.
OPTIO~
LIST ~ FALSE;

RETROTRAC;: = 500;

,J>
I hope Y0tl dor.'t Mine. if I send a copy of this letter to Andy Hickel for the
P.D.G. nQ\-Jslctter as I had b2cn I!](;:1niIl; to ~/,-'rite to hin: on the same: to?ic.
On tIle pllone Dhout distribt~ting n~~51etl0rs, he reitcr3ted llis concern about
the hcaltll o[ ~~tscal and tile extent to whicll it is diversifying. No one is
quite sure l.;~!:;t to do, except t-iorry, bllt I aGree that ,"1 cGffiITLittee is not the
an:31.·,er.

,

I haven't bro:1chcd the secol.. d question (i.e. Ho'>.J?) but that vIiIl have to
w2it for another letter. Before I close, two quick comments.

-f
-f

C/)

rn
rn
ELSE case 181>c1: I had the opportunity to discuss this v:i'.th 'i-?irth and his
objectIon is ·"D.-very valid one i.e. the progrc:·uT.If.c-r ,·;ril1 put the ELSE there to
catch val,-,cs y:hic.h he expects, but t..;.:lr.ts to treat in such-and-Sllch a way_ Hhat
will h2.ppE.p. is that it t .. ill (;I1so catch thosc iacvitlait your next letter with interest;
Ne\'ls letter.

I toohaveforl.arded

a e-..;es!}eciallyU:'d tenciahcy tllti;':

it will
wantin~

1

to tho::.e who seem to hI;:: callinJ fop

in

Further, the structure seems to fit

standard and the "tar;dards are

impleJ~entable);

of the reasons for the success of P-"scal is the close resemblence of

a lot of Ces anyone have any information on " t'ascal co,"p11"r
for the IBl1 Systo." 31

'*I:

en

and tiu,t tiU,l'O "ill be

ma~

of it's features to those of other languages such as ALJ0L and

IT!

IT!
::;c

Hopefully 1:11« CO.lIiaitt."., structure

themselves implOl.lentor:; (thus insuring that the i1"pleNenta iions al'e

It seems to nle that one

r-

know of auy othur acceptable way to go.

to implement.

me--the standard functions '10';' and '11i;:h'.

:E:
(I')

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

will be sirailar to that of tiIHULA, where the co,,""ittee metat,ar:; aro

proposal seems debatable to

=
IT!

seem to ha.ve to cD;llprolaise rather than choose the best; but.. I don't

well into the present Pascal syntax and does not appear too difficult
However, one area of the

n
:x:r-

(If there are none avaiJ;;bla, thi,s w'JaId sec,"

b:I
IT!
::;c

.

to be a .:;ood project for some computer science student, since lhis

..-

standArd.,functions be ;liven the names 'lowbound' and 'highbound'

machine is widely distdbuted.)

instead of 'low' and 'hi3h'.

co,.piler for the Cuntrol

.......
en

ble, with other,

lang",~ges.

For this reason I would suggest that these

nlis would be more consistent with the

names used for the similar functions in AWOL and PL/I.

u.. ta )2001

Also, does anyone I'.now of a

I.C

I do not

think that the minor disadvanta&e of slightly lo"tler nat.es is 5i.;nifioant; especially in consideration of the way in which the names
'lowbound'-a.rld 'hi"hbound' more clear1,;r express the meaning of these
standard functions.
standardization ... It is pecoining clear that Pascal is in need of an
"official" standard, formally published by some group """h as AI'ISI.
'!he lan(>Uage is presently plagued by a host of inconsistent and contradictoryadditions, extensions, and modifications.

If this trend

-0

:x:Ci')

IT!

en

w

IMPLEMENTATION

NOTES

(SOURCE INFORMATION, PROPOSALS FOR EXTEi~SIOr!S TO STANDP,RD PASCAL,
BUG REPORTS, PROGRAr'I I/RITltJG TOOLS, ETC.)

The IMPLEMENTATION NOTES sec+ion of +he newsle+ter is organized as follows:
1) A checkl ist to consider when sending us information about distributed
versions of S+andard Pascal.

fT1
::>C

en

2) Pascal-P, a "portable" compiler of Pascal for a hypothe+ical "stack
machine". It comes on tape asa kit and may be used to bootstrap
compilers onto real computer systems.
\

3) Other portable compilers: Pascal Trunk compiler, Pascal-J, Pascal-S,
and Concurrent Pascal.

rCHECKLIST - CHECKLIST - CHECKLIST - CHECKLIST - CHECKLIST - CHECKLIST

fT1
--l
--l
fT1

:::c

4) Implementation independant software writing +0015.
5) Compilers and software writing tools for specific computers sorted by

1. Names, addresses, and phone numbers of implementors and
distributors.

computer system.
2. Machine(s) (manufacturer, model/series).
Our policy is +0 print only new information.

If you do not find what you are
3. Operating system(s), minimal hardware configuration, etc.

look i ng for in News letter .#6, check # 5.
4. Method of distribution (cost, magnetic tape formats, etc.).
As Newsletter #6 goes to press, we stil I do not have enough implementation
and distribution information.

6. Maintenance policy (for how long, future development plans,
accept bug reports).

However, thanks to Timothy Bonham, we sent

requests for information to over 80 known implementors late in October.
responses we have received since then have been very gratifying.

The

We thank all

of you who have taken the time to respond, the repl ies have been a big boost for
this section of the newsletter.
Again we must stress that we need more information.

The PUG Newsletter is

the focal point for communications dealing with Pascal; implementors and
distributors must keep us Informed.

5. Documentation available (machine retrievable, in form of a
supplement to the book Pascal User Manual and Report).

7. Fully implements Standard Pascal? (why not?, what's
different? )
8. Compiler or interpreter? (written in what language, length in
source I ines, compiler or interpreter size in words or bytes,
compilation speed in characters per second,
compilation/execution speed compared to other language
processors (e.g. FORTRAN»
9. Reliability of complier or interpreter (poor, moderate, good,
excellent) •

We encourage users to share their
10. Method of development (from Pascal-P, hand coded from

experiences by sending qual itative and quantitative descriptions of particular
implentations.

scratch, bootstrapped, cross-compiled, etc.; effort to
implement in man months, experience of implementors).

Please realize that individual requests for Information are a

great drain on our resources.
CHECKLIST - CHECKLIST - CHECKLIST - CHECKLIST - CHECKLIST - CHECKLIST
Those sending information are encouraged to consider the check I ist, and if
possible, to supply a short order form (both "camera ready").

To further the

spread of Pascal, and avoid dupl ication of effort, this section should be kept
complete and up to date.

-John.

=
o
<
fT1

tx:I

rn

:::c

Order form for the revised P3scal P

syste~.

PASCAL-P
It seems that Pascal-P has been stabil ized/frozen. In a letter of
14 Sep 76 to George Richmond, Niklaus Wirth stated: "As for Pascal-P, where
we have done a major revision this past spring, I cling to the hope that we
can leave it at that, merely continuing the handl ing of new orders."

Please provide us with your revised Pascal P systen accordine to
the specifications on the this for~.

=

Address for delivery of the system

To order Pascal-P, use the updated form on the following pages (* we
apologize for the disjointness of the two parts of the form *). See
Newsletter #5 for more complete information on Pascal-P, in particular for
explanations of the instal la+ion parameters and magnetic tape format.
If you are in Europe, Asia, or Africa, order from:
Ch. Jacobi
Institut fur Informatik
E.T.H.-Zentrum
CH-8092 Zurich
Switzerland
(phone: 01/3262 11)

Prices are printed on the order form,
and include the cost of a mini-tape.

The characteristics of our installation are
tlachine type
z

George H. Richmond
Computing Center: 3645 Marine St.
University of Colorado
Boulder, Co 80309
U.S.A.
(phone: (303) 492-8131)

C>

Operating system

If you are in North or South America, order from:
$50 for P3 and P4 tape and document.
add $10 if Colorado suppl ies the tape.
add $30 if the version is to be preconfigured to your machine
(necessary if you do not have
access to a working compiler).
add $10 for a nine-track tape.
add postage if not pre-paid (if you wish
to be b i I led) .

<

Installation parameters (to be filled for case
intal

realsize

realal

charsize

charal

bools ize

boolal

ptrsize

ptral

If you are in Austral ia, New Zealand, or Oceania (*Antarctica too?*):

setsize

setal

Carro II Morgan
Basser Department of Computer Science
University of Sydney
Sydney, N.S.W. 2006
Australia

$A30 for P3 and P4 tape (option A).

stackelsize

(* price information for options B

strglgth

and C is unavai lable. -*)

and C is unavailable. *)

IMPLEMENTATION

NOTES

b:I

rn
intsize

(* price information for options B

'A' below)

rn
::s:

~__________~

stackal

intbits
sethi:;h

setloH

orcr:-'?xchar

ordr::inch2r

(SOURCE INFORMATlOli, PROPOSALS FOR EXTEijSlOl'JS TO STAND~.RD PASCAL
BUG REPORTS, PROGRM: IJRITliJG TOOLS, ETC.)

::0

UWEa:
AO

DO

Pascal p4 cOQ~iler (in Pascal).
- Pascal P4 cOQpiler (in P4 code).
An assembler interpreter of P4 code (in Pascal, for
docu~entation purposes, all alignment and size
constants set to 1).
- Pascal P co~piler implementation notes with update
list.
Pascal P3 compiler (in Pascal).
With line numbers, to indicate where it differs
from Pascal P2. (All installation parameters set
to a standard value.)
Charge SPr 160.(For users who have access to a CDC 6000 computer and
want to experiment with the compiler)
- Pascal p4 compiler with some changes, so that it is
accepted by the Pascal 6000 compiler (in Pascal). (All
installation parameters set to a standard value.)
- An assembler interpreter (in Pascal, as in package

'A' ) .

- Pascal P coapiler implementation notes with update
list.
Charge SFr 80.-

cO

- Update list to 'PASCAL-P compiler implementation notes'.
Charge Sfr 5.-

Date

Signature

UNIVERSITY OF WISCONSIN - EAU CLAIRE / EAU CLAIRE WISCONSIN 54701
DEPARTMENT OF COMPUTER SCIENCE

25 August 1976
PASCAL-P

Progress

Report

Our interpretive PASCAL-P system has been running since
November 1975. This summer the portable compder was
re.,ritten in Burroughs B5700 compatible ALGOL. This ne.,
version of the compiler generates P-code which is subsequently "executed" by our P-code assembler/interpreter.
Compile times have improveu by a factor of 16 as compareu to the interpretive system. I expect a further
improvement of two to four \'iill be achieved by rewriting the procedures INSYI·lBOL and NEXTCH.
Using the (slightly modified) PASCAL source code su~plied
with the PASCAL-P implementation kit, this ne., complIer
has successfully compiled both the PASCAL-P compiler and
the P-code assembler/interpreter. The source code for
the PASCAL-P compiler contains several records (lines in
PASCAL terminology) longer than 80 characters. These
had to be rewritten/shortened to make them acceptable
to our ne" compiler.
(lVe expect input to come from cards
or a teletype.) Also, one or two long string constan~s
had to be broken in two to satisfy the STRGLGTH restrlction of our system.
The source code for the P-code assembler/interpreter was
a bit more troublesome since it is written in standard
PASCAL rather than PASCAL-Po The problem areas were:
too many long constants in procedure INIT; the standard
types TEXT and ALFA; the standard procedures RESET,
REWRITE, and PACK; an argument of type BOOLEAN in a
WRITE invokation; an octal (that's right, fOlks!) format
specification in a WRITE invokation; an actual parameter
that was a string constant passed to a procedure expecting a PACKED array of type CHAR; the attempt to reference the procedure PUSH in procedure EX3 (PUSH is local
to procedure EXO); string constants too long for our
system; standard I/O procedures without file parameters;
semicolons preceding the final END in case statements
(surprise!); and a function (BASE) of type subrange.

The UniverSity of Wfscon'Sin·Eau Claire is an Equal Opportunity employer and actively seekS applications from all,quall1!ed
persons, whatever their sex, race, color. religion, national origin, or age.

=

PASCAL TRUNK COMPILER

UWEI:

UNIVERSITY OF WISCONSIN - EAU CLAIRE / EAU CLAIRE WISCONSIN 54701
DEPARTMENT OF COMPUTER SCIENCE

PASCAL-P

Progress

Report

(no new information, see NelYsletter #5)

PASCAL-J

(no new information, see NelYsletter #5)

PASCAL-S

(no new information, see Newsletter #5)

=

Page 2

(/)

r-

CONCURRENT PASCAL
Having completed the rewrite of the compiler, the next
step was obvious -- modify it!
The error codes emitted by our new compiler are diff~rent
from those emitted by the Zurich compiler.
The comp"Ier
teSts for over 250 different syntax errors and each of
these errors is now associated with a unique error code.
This allows the corresponding error messages to be more
explicit and, hence, useful to the novice users of our
system.
We have added another (extremely useful) type of comment
to our PASCAL system. A percent sign el) is used to
signal the compiler that the rest of the current source
image is to be ignored (our system respects card boundaries in this case).
This allows the programmer to pl:;tce
short documenting comments after the percent SIgn. ThIS
type of comment is very useful.
It is much less error
prone than the multi-character comment delImIters l~
PASCAL and PL/T.
It speeds up compilation by redUCIng
the number of characters the compiler must "look at."
It encourages proper documentation by placing the comment alongside the code.
(Assembly lan~uag~ programmers
have been doing this for years WIth satlsfYln~ results.)
If portability is a concern, a very SImple edItIng program addition will remove the non-standard comments at
the same time the character set converSIon IS beIng done.
Assertion: this type of comment should be a part of ~
future high-level programming languages.
A future report will outline some of the ways in which
our PASCAL system is being used in s~ppor! of ou~.Com­
puter Science program here at the UnIverSIty of WIS_cons in - Eau Claire.

August 1976

;;0

Termination of the Concurrent Pascal Distribution
The distribution of the reports and system tapes of Concurrent
Pascal and Solo was terminated in August when I left Cal tech
to join the University of Southern California.

Papers describ-

ing the language and the operating system have been published
:z:

in the IEEE Transactions on Software Engineering (June 1975)
and in Software - Practice & Experience (April-June 1976).

The

tapes are now so wide-spread that they can be obtained elsewhere.
Several groups are currently moving the system to other computers.

I will be using Concurrent Pascal at USC, but will not continue
the distribution of the present system.

I would appreciate it very much if you would keep me informed
about your experience in implementing and using Concurrent Pascal.
Yours sincerely,

~u=-Q;?+
Dr. Bruce A. Pumplin

The University of Wisconsin-Eau Claire is an Equal OPDortunity employer and actively seeks applicat(ons from all qualified
persons, wnatevcr their sex, r ~ce, Color, religion, national origin, or age,

rr1
--f
--f
rr1

Per Brinch Hansen
Computer Science Department
Universitv of Southern California
L6s Anqel~s. California 90007

a
-<
rr1

rr()fesso\~ P~r Brinch Hansen

;,',191.:5 t. (, .19~J (i

COF~pu~:cr science Dl?po.:rtrr,ent

Universitv of southern Califl)rnia
Los Anacl;,s, Califorr,ia 90007

Since October 1975 renorts and syste~ taoes
have he en distributed to 252 institutions:

\

86 companies
119 universities
31 research laboratories
16 others
AEG - Telefunken
Amdahl Corporation
Analog 'l'echnology Corporation
Basic Timesharing Inc.
Bell Telephone Laboratories
Boeing Aerospace Corporation
Bolt, Beranek & Ne~man
BUrroughs Corporation
Comptek Research Inc.
Computer Automation
Computer Consoles Inc.
Computer Sciences Corporation
Computer systems International
Data General Corporation
Digital Equipment Corporation
E. I. dupont de Nemours
Electromagnetic Systems Laboratories
First Data Corporation
Fisher Controls Company
John Fluke Manufacturing Company
Foxboro Company
General Automation Inc.
General Electric Company
General Radio Company
General Research Corporation
GRI Computer Corporation
GTE Laboratories
He~llett Packard Corporation
Hitachi Research Laboratory
HoneYHell Inc.
Inco Inc.
Incoterm Corporation
"[:1 '.:. ,.'

C·..,.~:!:-:1

I hope the above information will enable you to obtain
the material required for the Newsletter.
Yours sincerely,

I can give you details of other B1726 Pascal
These are:

(1)

(a)

There is to be another European user's meeting at
Karlsruhe in February 1977. Our Own contact for all the
European information is through the University of Newcastleupon-Tyne.

~c~
BURROUGHS B-4700
vlilliam C. Price of Burroughs Co,rporation, 460 Sierra Madre Villa Ave.,
Pasadena, CA 91109, has informed us that he and Robert M. Lansford also of
Burroughs, 3620 Greenhill Road, Pasadena. CA 91107, are preparing a
description of their 84700 Pascal implementation. We will print this
in Newsletter #7,

BURROUGHS B-S700

(implementations exist)

rrl
;:0

B~RROUGHS

The University of Tasmania

B-6700/B-7700

Postal Address: Box 252C, G.P.D., Hobart, Tasmania. Australia 7001

Telephone: 230561. Cables'Tasun,'

Telex: 58150 UNTAS

=

IN REPLY PLEASE QUOTE:

Thi! University (If Tr.Jsr(l:wlia is de lJ21::JpinQ a c[1:Tlpilcr for PASCAL to

prDL!Llce CXl'!cLli::][lle programs

011

the [Jurrou,]hs 86700/07'700 computer systems.

The cDmpiler i~ currently (1~7G October) operational but with only a
simple i/o system (default file declarations and PASC.~L 1 i/o statements).
Curr~nt

VepM{men{

FILE NO

work con2entrates on implementing general file and file attribute

declarations, and on extending i/o statements to a usefully sized set.

0

f,

1116o~mat.i.ol1

Suenee.

IF TELEPHON!NG OF! CALLING

8 November, 1976.

ASK FOR

Pascal Implementations,
University Computer Center,

\

227 Experimental Engineering Building,
University of Minnesota,

Our current policy is not to release the compiler until it reaches this
next stable state as otherwise copies of the simplified version will
proliferate. We would welcome any expressions of interest from B6700

MINNEAPOLIS,
USA.

MN 55455

Dear Timothy Bonham,

users in the compiler, and will add addresses to our list of interested
people, as this will determine the level of support that will be necessary
to maintain the final system.

Burroughs B6700 PASCAL Implementation
L

The anticipated release date is December

Names, etc. of imp 1ementors
Professor A.H.J. Sale
(Phone Tasmania (STD 002) 23-0561 Ext. 435)
Dept. of Information Science

1976.

University of Tasmania

The Burroughs PASCAL compiler is a true. compiler for the B6700: it generates
a code-file which can be executed by the system.

The code-file contains

2.

case with DASIC). The execution speed and compilation speed of PASCAL
are comparable to the Algol compiler, though much less code and data space

Machine tested on
of main store, disk, 4 pack drives, etc.
environment with heavy interactive use.

3.

is needed for compilation.

maintains standard treatment of PASCAL features with the addition of
86700-compatible compiler-options and other features.

The aim is to

4.

Documentation available
Under development.
Will be in form of user manual as well as supplement
to Pascal User Manual and Report.

6.

Maintenance policy
To be maintained for teaching use within University as well as larger
aims.
Reported bugs should be fixed as soon as possible, with notification
to users.
Duration of support not yet determined; several developments
are also pending.

7.

Standard-compat i b iIi ty

Arthur Sale
Professor of Information Science
University of Tasmania
252C

G.P.D.
7001

Method of distribution

5.

retained.

Flox

not known,

Not officially released (December?), nor cost determined.
Format will be
via magnetic tape (both 7-track and 9-track drives available).

for which transFerable skills from other Burroughs subsystems can be

Hobart, Tasmanlil

Minimal system to operate:

but unl ikely to be any B6700that small (store demands are low, 1 ittle
else is critical).

It

produce a compiler Wllich "Jill comply with the B6700 conventions as
embodied in the Algol/FORTRAr,/COBOL/etc compilers for that system, and

Machine operates in university

Operating System, etc.
Burroughs MCP Version 11.8 operating system with (few) minor local
modifications for accounting, etc.

The compiler is based on PASCAL-P, but is written in Burroughs Algol.

J'T'1

Burroughs Model I II B6700 processor, with vector mode hardware, 196k words

no BIrJDII\JFO and cannot be bound to any other language at present (as is the

Does implement PASCAL in Report with following exceptions where noted
wi th reasons:

o

<

Box 252C G.P.O.
Hobart, Tasmania 7001.

Compiler information

heading:

reserved word program is synonymous \oJith procedure;

no parameters (fi les) are permi tted after the program heading.
Reason:

likely to

CDC anachronism of no utility in our instal lotion, and
b~

confusing.

set constructor of form A.. B not implemented. Reason: future plan.
FORTRAN control character on print line not implemented.
Reason:
a ridiculous feature to standardize.

Full Pascal 1/0 not implemented.
scheme is PASCAL-I-like.

Reason:

UNIVERSI fAT KARLSRUHE
INSTITUT FOR INFORMATIK

75 KARLSRUHE I. den
II

1.

Okt.

1976

71RK f l 1
ro~ T' ",ell t..lHU

Dipl.-Inform. Uwe Kastens

lHlFO,,"

tIl7!1tOO!l~72

rn

future plans, present

::;::
(/)

r-

Extensions

Burroughs comment facil ity
ELSE inCASE
Fi Ie attributes in declarations

Format declarations
Extensive Burroughs-compatible compiler options (Pascal option mode
not implemented).

8.

rn

Pascal User's Group
c/o Andy Mickel
University Computer Center:227 ExpEngr
University of Minnesota

Various reserved words, character set transl iterations.

-l
-l

rn
;0

Hinneapolis, lili'l55455

Compiler or interpreter, etc.

USA

Compi ler:
generates B6700 code-files which are directly executed by the B6700
with MCP.
There is as yet no BINDINFO in the codefile so that
it is nDt possible to link Pascal to modules compiled by other
systems.

written in B6700 Algol entirely.
Characteristics:
compiles about 20% slower than FORTRAN or ALGOL, but in about 2/3 of

=

Dear Mr. Mickel,

their space (for test proqranls about 11-5k words on average

instead of o-IOk).
Elapsed compilation times similar, though
PASCAL slower.
Speed should be improved by eventual tu~ing.
executes at same speed as FORTRAN and ALGOL (code is very similar and
optimal) and takes generally longer elapsed residence time
primarily due to Mep intervention to create new segments for
record structures (not present in FORTRAN/ALGOL).
Elapsed
residence times about 20% greater than equivalent ALGOL.

one-pass system: code generated is very close to optimal for B6700
unless checking requirements of Pascal intervene to inhibit this.
options include listing of object code in symbolic and/or absolute
form, editing of input, etc.

9.

as is the B6700, a high level of confidence is essential.

The compiler

code-generator section incorporates many reasonableness checks on the code to

trap some flaws before they get executed and to aid in tracing errors.
Method of development
Hand-coded using Pascal-P as a guide/model.
All other paths offered
much greater difficulty on 86700 due to special nature of machine/system.
Han-month details not kept, and project proceeds in fits and starts as
teaching intervenes.
Project has thus far been limited to two people:
Prof. A.H.J. Sale and R.A. Freak (support Programmer).

I trust the above comments meet your need.
1 enclose a copy of a brief
technical report on some thoughts on Pascal implementation around August of this
year.
I am, and intend to remain, a member of P.U.G. ~f ~
Yours sincerely,

A.H.J. SALE ...

~ith the ?2-Cornpilcr

(as described in Nori, e.a., "The PASCAL P-Cornpiler Implementation
Notes", ETH Zlirich) and translated the assembler/interpreter for
the hypothetical stack computer from PASCAL to Burroughs Extended
Algol. So we can compile PASCAL-programs by interpreting the
PASCAL-Compiler and execute the generated Code for the stack
computer by interpreting it. This technique is very time- and

Rei iabi I ity
Excellent.
Only one system crash during testing attributed to Pascal
(in run #2), and a total of two serious bu~s ul1cover~d durin0 extensive
testing. On a machine with minimal protection against aberrant compilers

10.

Until now we have an interpreting PASCAL-System running on the
B6700. We got the "PASCAL-!rnplementation-Kit"

P~OF.

OF INFORMATION SCIENCE.

space- consuming: The PASCAL-Compiler needs about 30 min B6700
processor time to compile itself.
~,e

didn't complete the whole bootstrap yet, because of several

problems concerning the generation of B6700 machine code in
general.
Sincerely

V',I\TRSlTAT KARLSRUHE
INSTITt'T FGR I"FOR;\\\TlK

75KARLSRUHEl.~~

(II 100l0)

l'i)~rF"CIl1>38(l

TElEFOi" (07211 60S

Dipl. Inform. U. Kastens

,

5.11.1976

71N.KH 2

3495

University of Minnesota
University Computer Center
227 Experimental Engineering Bui ldi ng
Minneapolis, Minnesota 55455
c/o Mr. Tim Bonham
U. S. A.

Dear Mister Bonham,
According to your letter dated October 25, 1976,
directed to Prof. Dr. G. Goos, I will give you some
information about the state of our PASCAL-activities.
We have an interpretive PASCAL-System running on
the B 6700. It is based on the PASCAL-P2 compiler and
the assembler/interpreter from ZUrich. We translated the
latter one to a Burroughs Extended Algol-Program. This
'interpretive version is naturally very time and space
consuming. (The compiler compiles itself in about 30
minutes CPU-time.) The system is available on magnetic
tape for a nominal charge of ~ 20.00 when tape is supplied, ~ 30.00 otherwise. We have a short note for users
of the svstem (in German only).
Another project on the B 6700 is based on an early
version of the PASCAL-JANUS-Compiler (from Boulder, Colo~ado). PASCAL is translated via JANUS, STAGE II and an
,ssembler to B 6700 machinecode. We didn't test the
system enough to say how reliable it is.
Both projects were not further developed nor maintained because of a lack of manpower at our institute
and deminished computing capacity on the B 6700.
Sincerely.

'//

.

/

(f, (((~ /y;:~(

'J

IRIS

50}

IRIS

80

Olivier Lecarme of the Universite de Nice, Laboratoire D'Informatique,
Parc Val rose, 06034 Nice eedex, France, has helped to clear up our
confusion about the ell machines. In a letter of 16 Sep 76, he wrote:
"Altnough ell 10070 is a nickname for Xerox Sigma 7, the ell Iris 80
is another machine, more precisely an extension of the first one. Moreover.
the ell operating system is different from Xerox and transporting a Pascal
compiler from a Xerox Sigma 7 to a ell Iris 80 probably would not be a
trivial job. A Pascal ~ompiler for both ell machines has been written by
Messrs. Thibault and Mancel of IRIA (Research institute in Informatics and
Automatics. a French government agency), by bootstrapping the first eDe 6000
compiler. It has now been upgraded to accept Standard Pascal and to allow
separate compilations. and it is officially distributed by IRIA, a case
whi ch seems uni que. I ts overall performance seems to be qUl te good, and
it is used in French universities which have one of these machines.
"The ell Iris 50 is a completely different machine, much smaller.
and we have some trouble in Nice \'1hen trying to implement Pascal. Pascal-P
works interoretively, but it is unusable for programs larger than one page,
and consequently it cannot be used as a tool for bootstrapping a true
compiler. I plan to write a brief paper for describi~g the bootstrap.
method whi ch wi 11 be used, and whi ch seems to be a Unl que one. Maybe 1 t
could be done in time to be included in newsletter number 6."
(* perhaps
Newsletter #7? *)

CONTROL DATA

(YBER

2550
3300
3600

18

(an implementation exists)

lO} 170

SERIES

(see also Newsletter #5)

There is very little fresh news on this implementation. It is rumored
that Zurich has w'ritten a first modset (UPDATE1) to Release2 of Pasca16000.
We at Minnesota have not received it yet. There is a new price list for
distribution tapes, but no new order form. See Newsletter #5 for the old one.
If

you are in Europe, Asia, or Africa, order from:

Ch. Jacobi
Institut fur Informatik
E. T. H-Zentrum
CH-8092 Zuri ch
Swi tzerl and
(phone: 01/32 62 11)

The handling charge for Release2 is SFr. 100
which includes the cost of a mini-tape.
Do not pay in advance, you will be
charged at delivery.

If you are in North or South Ameri.ca, order from:
(U. Kastens)

Ka/Wh.

en
I
rr1

-l
-l
rr1

:;u

=
o
-<

(an implementation exists)

(Control Data supports a cross-compiler on the
6000lCyber 70, 170 seri es)
(implementations exist)

6000/(YBER

=

George H. Richmond
Comp,uti ng Center: 3645 Marine St.
University of Colorado
Boulder. eo 80309
(phone: (303) 492-8131)

$60 for Release2 tape and documentation.
$50 if you supply the tape.
$25 if you have Release1- you supply
the tape, and no documentation is
i ncl uded.

rr1

If you are in Australia, New Zealand, or Oceania, order from:
Carro 11 Morgan
Basser Department of Computer Science
Universtty of Sydney
Sydney, N.S.W. 2006
Austral i a

CRAY

RESE.~ROI CRAy-l

$A30 for Release2 tape and document.
l::'>iIVERSITY OF CALlFOR:-:L\
I.OS AI.A \IOS SnE"TlFIC LABORATORY
I

P.O. U()X Ifl6.l

CONTROL DATA 7600/CYBER 76

I.OS A1.:\\tOS, '1-:\\ :'\U:\I("O H7545

Pascal on the· cue 7600
This Pascal compiler is essentially the Zurich 6000 -3.4 compiler.
The run-timp system is based on that of Hans Joraanstad (see Newletter #4)
The compiler is release~.

It was developed by cross-compiling from our

CYBER 72.
The compiler is currently running under SCOPE 2.1.3 and will re-compile
its<,lf on a 'half-size' (32K SCM) machine.
c;.ompilation Sp~Q.
57000 characters/second approx.

Cnmpiler re-compiles in less

than 10 seconds.
Exec u t ion Speed
Pascal execution speed has been measured by using the obvious encoding
in Pascal of Wichmann's Synthetic Benchmark (see Computer Journal Vol.19 No.1).

11'; REPLY
REH:R TO:
MAil STOP:

C-11
296

ALGOL

q

(0=5)

PASCIIL
FTN (oPT=.!)

* Using T + option
** forces OPT = U

No run time
Checkinq

1230
6240*

9345

3174**

1996

of self-interest assist with bugs in the 760U_dependent code.
majority of the compiler and library is standard Zurich tode.
Con!J!.U~

Mr. H. U. Ellison

or

Mr. A. P. Hayes at

UMItCC, Oxford Road, Manchester M13 9PL, England

o
<
I'T1

::s:
1.

Implementor and maintainer:
Robert T. Johnson
C-11, MS/296
Los Alamos Scientific Laboratory
P. O. Box 1663
Los Alamos, New ~!exico
87545
phone: (505) 667-5014

UMRCC will presumahly, out

-i
-i
I'T1
::0

October 27, 1976

I want to tell you about an implementation of Pascal for the Cray
Research CRAY-l computer done here at Los Alamos. I will follow the
che.cklist outline on page 44 of PASCAL NEWSLETTER #5.

2.

Machine: Cray Research, Inc., CRAY-I.

3.

Operating System:
and is now called

i.e. all run time checks included

Ma i nten anc e
-The situation is unclear at present.

r
rn

Dear Andy:

Array Board
Checking

6850

en

Mr. Andy Mickel
Pascal User's Group
University Computer Center
227 Experimental Engineering Bldg.
Uni vers i ty of Minnesota
Minneapolis, Minnesota
55455

The units are in thousands of Wh'etstones.
Compiler and
optimisation level

co, TR:\(~r \\ -7411~·F'{;·.lbl

rn
:c

It was called the Benchmark Operating System,
after several extensions and enhancements.

l~S

4.

The compiler has not been distributed elsewhere, and no arrangements have been made for the distribution.

5.

Documentation consists of a two-page description of how to access
and use the compiler.

6.

Maintenance on this compiler is suspended; the compiler is at
the end of its usefulness on the CRAY-l, because support for
it cannot keep up with system development and changes. The
compiler has been superceded for our development work by a
cross-compiler for the Model language designed and implemented

The vast

t:C
I'T1
::0

DIGITAL EOUIPMENT (DEC) PDP-lO. DECSYSTEM-IO
Oct. 28, 1976

-2-

Mr. Andy Mickel

UNIYERSITAT

HAMBURG

(see also Newsletter #5)

INSTITUT FOR
INFORMATIK

by James B. Morris, Jr., of this Laboratory. Model was based on
Pascal and retains many of its concepts. (Cf. "Abstract Data
Types in the ~Iodel Programming L'wguage," Robert T. Johnson and
James B. Morris, Proceedings of the Conference on Data: Abstraction,
Definition, and Structure, SIGPLAl'l Notices, Vol. 8, Number 2, 1976.)
Pascal-P2 did not seem to provide a good enough basis for further
work, perhaps P4 will be better.

\

7.
8.

The compiler implements Pascal-P2 except for I/O.
no I/O was available on the CRAY system.

Until recently

9.

The compiler reliability has been good for programs which were
first tested on the CDC 6000 compiler.

10.

The compiler is a cross-compiler written as a translator of
P-code output from a (slightly modified) Pascal-P2 compiler.
Both the Pascal-P2 and the code translator use the CDC 6000
compiler. About 3 man-months of effort have been expended on
this development.
Keep up the

Sincerely,
)'.\ <:'
,;..

.:r. j\n..J,:'

'/~< t~.;~ ~--f VI

,

Bob Johnson

i~.-!;.

~'Ja:::;el

:i_c:~el

·~:liV'~l.':-3i ~~S
,!..:;!;__ '/er...;il,j

'.;C,;::r.:ute2-'
'..:;:(

F~fD.precbcr; 0i0-4123-

:~·f.-:n-'.,·,:r>

'i:,~;C:J0ttl

Bch6rdcnnen:

;'~
,:it~n8i.:-:p()}.i~,
ii.:'.D8f;Oto. ~jii

I: 151}

9,09(.)

DurchW&h1

~:~:~!

Ttlex-Nr.: :2 1-4:732 unl hhd

___

lJ~) f

Datum WId Zekben Ibre. Sdan:ibenl

Aktenzeldlea (bel AnNett bltte angebm.)

0.....

September 24, 1976

~\Ja/J3.

t:--il:

.~-;:

r"ISC.!\:"

:~e·i':31et

tel'

~,.~.u:ibcr

j

113.3 b~en studied by ce with Great

intere::.;t.
I co~gr&tulate for t~e livelj exc~un~a of G~inions that you enatle
by your effort. I woulti like to sUDpieJ~ent the twa.cGntrj~utions

..,;i-dch refer to tiie Ji:;C;Syste?"::-10 i-·r:]CII.L-coE'pj 1cr uevelor·~""\t~d qt LaL:burg.
.-!r. J. ~G8oo1 \'-;1'10 3ee ' jiS '~() be utterly -iisal::;,ointed by our cO:!1piler
~e:l~ r;:e two l.etters. ':'l\!'le rir~Jt letter' froT;: hir;l(dated >larch 16,76
2.rr~ved ~lere April :0,76) presented a pro~srajJ listin,:; ~'litll the rer:tark
t~~at thj.~ pr();r~~ started exc8ution and th2n never coulJ be nudced

ff~:~!·~~~~~; ~~~~~i::'~~~ii;~~;~~:;,}~~~~ ~~~;i~~~;~~: ~ ~~: ~~~E:~:~~~~:::)

an:i delay ,due to the E2.6tS':'~ :lol:idays 76 :L i'!Tote him. a letter indicatiDt=; the 1~ro:xole arId nJail'21 it ;;"2r3cJrJally on ~;ooJ ?I'::'~1ay. fl. fev; days
~yt~~~ ~;.;)}"·ll 2.6,
T received c~ letter (.j.:~t0.:i ;:~apch 26, 76) from
·.r . .'~cc..ool co:;.pla.ln.Lll:· oi' not bavin e.: receiveJ an ans\".:er to his fir'st

y6!

tVil) additional co~npilcr err·ors - the date
al1d .. ?~12 f~ct, that If~.J on input turned out to be
-!;.,~jjJ on UULp~t ~~~ to the co~verSlor~ ~o~tines. ~oth letters
~':ere sent Ly cI'.Jinar·~,· .~lail. ,u.rparently ~·i:l>. :lcC:o·ol did not realize

letter afl:i

~.~l~t
~ ~. ,~

C)

J..!l:.,t':lll~l-

ti.v!/ .

1.

-

L.aiL imf!'::::':':V''':::(:!14~!5 L-f ;;r.:; :1(: ....

the

1.11

r',):_lti·;c:~:.

'.lC(!..::);~,p:,:L-:Jr".

tu

11.

:~()TJ

-:2.

Tl"!~,=

P;·JcC'~:1re...:ii""l;-lction.~

out (ii'

;.irc il"i'l"';l

en~:~cl.

i;.-:p1.er:c:;tat.ioL of f'or:'i~: r-r()cc
.
);tiOll ~.!
:n~ull

i:~Lo

,
l;~·r>:·':e

ths-

LCJ\~)

nur:be::.'

:...~.:~.C;·,y~~tC'l:-·l,:;

::inc:
()C

13.

L~L CU'~'!'
:';lj! ..

C.

't.e.:::bu::.",::.

r'_L .l'~r

Pt-~C;i~ :i!':cl U:·:Pfl.C~( Lave been <-:.on.8teu ts t~:C' st~!.:~~~,~Q.l'd definition r,iven
in th(~ :J/\_'~C;lL GSer .,anual anj- Leport. ;:'',-10 uuJitiono.l octional ar:'I'L) H,:::'Jitional 3tan_darJ functions ~L()CK ~_:1j r~:EJ'..L:1I~lE !l2.Ve
intr{)duced ~ith i.nte~er funcLio~ value to determine CPU-

&nJ

:·>.?al-(~'':rr'e

:";S'v:

stant~arG.

ti1t:~

det0:!"r..ine

1(; .
1 '7,

l)~

r~,-ht'

';;nerr~ti(;;-~

1;OL1,S(""1' ..:!!:i tC:l

.

::.n

T!j lli.3~;eonJ;J.
-:'-'J::;:.C~f;\

fLll'"2ctl:)n:;;
f~rst

(in;';

J.;-l~;t

r.2ve ::,een in'c.::--oduced to
ci' D_ .3calar or 3ubrnnce.

and IISr:
~la_lue

L ()~',.:;":iL;(J:j;·.Ej and Urr:":TA.;Ui1U allo-,'i to det!::rr::ii";':; t:1e re3[JectivE' index
\:~lliP:~ f(lr ~!rrpy riefiGitic:n8 to enrble Rn 08s i er ct!anse of C0Dstant or' ['a:;-IL~e Jefifl.i 'tion3 '"

US~!, j2fi!)~_ :~~ul~r vari~Dle3 cal: be input ani output us~n3 the
':::;i:":'':'>:''-l,ctf·~ -=-"0;:r'r]:-}(~nt2;~icn (;f th,? 'Jalue con.st:.L.;.;1tS. r~:'~1e co'!"~version
f'rc" ':.YC to t.ile .int..err~:lJ. repr'e:j'.1:·l1~Eition is taken care or by the
~·i.~;·itJ.::1f:: 3tlprO:::'t. 'valuc~3 ;."'or DI:'':-vaI'iablcs ~:!ill li~':e\'!ise be conv~r·t~j on i::.l~·'.lt/(),.ttput frol?':. resp. to the C;Vlrnctcr representation
t;.::: :L'~ a..:)~.:;a:::>s in {..: sour'c(' ,:.;ro:-;r.:tf: ~-;::'~~·-con;::;t3.r,t.

uI' a i.-:_-3t.i:<. ~;,~'~:'. ();,;; c:ont!'ollcd Ly
l..h::- ~~-:)!:;r-2.1£:. ccr.!l:lt:r<1.

j"l

"':,:.

intro~:iv.c~"ioli 0[' a Ci-lLL e~1i.lLJle3 the
procr::ir.~ and the i::i8ed io.t S' s t.:'.:.rt
c~~ticn oet\'!t:e~~ iJP()Cl~2.LS j S :.;I'ov-Lc!cd by

':'Le

:? iiSCllL

f-':::~c'-2eciut'e::)
~.p:;C'n(i,ed

T~lC 3t:'H1i::tl'< ::::L,/ tc 0!.l:i[_;le::1ent
;::, :-1 i t c bes i d eChO i:i,-JiJ.il-?~~'lc.

E:

t

r:

':';,u

':iiLh

F,!\:~,DL}~'

A.

......

2~

Jr~iC d{.:~;j.re
s:;':~l;d::tLJe

•

for 2rrur r2(:ov!~ry du!'i:l~ te~~inal in0ut lS qui te uncterfowe v 0r, it ~equire~ ~ cbGylete redesign of tile (ns:.3emLly)

~o

t~e

deL'u;,,~ 5y~-jte!:1 has been e~llar'ceu by an opdU7:.p in source level code.

:!.I;vcl

:')'Jt.tpc,_;

~lC(!P

?O;3·i~- ...10Tr~1>:::-:)U-·P

pcrlJeJ

3.

'::,!"'E' :~';·-_-.:::'dtle to ,_l:;;~cr;:.l!lc the value of OIjtion S\'Jitches
r:~'~?CiTl-'I~~ co,~::"lan;~i ;rc;l \', i ~ :r1i!"';. the P t\~~·Ci·-\.L pro[ral.:.

t-,,) t Le

t,ior'Jal st:-ick and
2'2.

tern:in2.tion of the current
of 2.!10tber proL:rar.L. Cor.,L'!uni;:it:l!'Kl3.rd JCC !:;:';·IPCOr. file3.

facility at source
3y3te;~ .

lan2:':.!a~e

level has been [:,p-

Fh3DJ~

~'~u~ltiIi1e

:.necKs ~1ave been exterl'.!.r::,j tCJ 20-Je:' d. lart,;er number of possible trouble point.:;. If a pro~:r2.L1 hcs been cO;:"Lpiled ~"ith the
FhSGilT 1ebuS a[ltion, any runti~~e error detected - includin~ those
by the TOP~-1l) rl.o~lito:· - l.·:ill tran3fer con~r81 to the PA:=1DDT-system.

2A3CAL procedures/functions and ~:ACRO-l0 routines can be complledl
~33embled separately and inclu0ed to:ether with ?O?!~A~ routines
i,~itQ n relocatnble object code library.

25. A Elachine

retricv:ltle nanual for th~3
;!!entation in ~:!.:·~lish is o_vailccle.

0~C3y3te!n-la

PASCAL

i~ple­

-0

»
C/J

n

»
.:.>~11J

i)Y:3tC;;,;3

:)ei:;

·,,::::,t~;\~

;~<').':::'

:.:.t

...'e~~'.t
-in;:';

(.~

-..JU-~·

r~t.~\lt·:'-".'_ii t,':·:teih.lcd t'.:~~·i.:.J.i G;
(A'v'I.)jj ,J i·5:Jr\r:'():1.r~t;i.c;'ll 'lftF"
/.

~'t'Cl::1t,

'Jcrsjc'11

:.;;

..

~,~ .. (:

<:.JtI'Iv . lt,io~;,

~~-,.:.ic::

;. . ~.(:

,_ ;i:i.::·t:>i,)·.~t iu~!
..;;L:-J.',.... J.. ;L i 2 ·,t :\~1,
C'c' ,!~ly
1~'1':J r-,j(~~~, L:.: of' i.nt·~r-,.'::·.t.

··isi(~~·~~
'ti.,

of'

rlU

,:u!'.i:"·~~;·ltly

1s

L'oJld 1: \

1-:11 -·t.t

U:,_~r'

:i:::~

(\!-t":.'

:')/\,'~~'l

i.o;,

c

~,<,'

t,1;

DIGITAL EQUIPMENT (DEC) PDP-II

r

(see also Newsletter #5)

Stephen C. Schwarm of E. J. du Pont de Nemours Co., 101 Beech Street,
Wilmington, DE 19898, has written us: "I am Chairman of DECUS SIG PASCAL
and I will be glad to help vlith distributinq any systems on DEC PDP-lls."
(" maybe Steve can helr organize this section of the implementation notes. *)

,":(Jp:t)~.l:.:r

,

'lI:

en

1',)

's:p
Bo'~

in8tall~.ltion:3

,ib:;.J'..:. ~'i:;j en '

~no~'.!.

to .s1.lLtr'n.ct t1-j2 i!1.:;1~-2.l1ation of

:-'£.

:.1.1. l'.::y~,e·"3

lC

Ti')ese :ire the

rn

rn

;~;

~r"~i

z

To:

,;

SASI--::.

'~:7N

OI.dO

INTERESTED IN MY PDP-1t
PASCAL IMF·LEMENTATION.
CC:,P8SCAL NEWSLETTEP
PE~SDNS

i10I' ver::;ion. t~,y ';)n~·:r~e.:;lfil;
t:.) the ~:!rit.(:;i.'> ',,;itll t;18 hl.r:.u~

J'or.::ulD.ted cxpect~:::.ti·:J!! thc~t "t~' sUi:~port,:5 :d::: Clr..i.lc:~ LJ J~ J.~~o.st elvin
detu.i13 0.:' '.'.:hel'E' tIL c'nco~ntS'J'>ej tro:...:Llc, illjicat~.n:: t:-~,,: CG!:.p:'J.e;· V2r
sion tG '\(nlch hi: r't.';. . ··lr;,:~) :~0y'J..v &r:.~~ r.:'~·;j,;, :...rh(j~:, he f,)b~2..i!1.e~; it. ,',-"-L1cr)
:.~L e itorial ~)~ll-:.;.:.r ::j._~~~~ o.d..i. t·:} til? v:::l'vt{~ uf' the r!;,'::;rL ;,jssr ~~ro:Jp
::e'::s etter since - u.[;,(::n:.; ot:'i8!''- t'{!;J~:;cns ... i.t '.".t~';:lt U;..i.;<:'-: t!!,.~ ~t~.ier l~O:.;­
rr.l.l:-.l y c~':are of ::ccut12 net. yet id.-:-:nti fic~c at thei2 i:~~.;t2.1:at::'(J!1.

THIS LETTER IS TO AI'~!ISE YOU OF THE ST~TUS OF MY PASCAL IMPLEMENTATIO(1
FOR
THE
PDP-11.
I APOLOGISE FOP SOME DELAY IN WRITING
THI~ LETTEP;
I ~~E BEEN EUSY MOVING.
IN A WDRD,

MY COMPILEP

IS DEFUNCT.

My

IMFLEMENTATION WAS NEVER MORE THAN A SPAPE-TIME
PRDJECT~
AND
~:AS
SLOW AS I HAI!E BEEN VERY BUSY.
My MOVE TO TORONTO
ESSENTIALL~'
ELIMINATES BOTH MY SF ARE TIME AND
MY
CHEAF
MACHINE
ACCESS.
As
t·n··
COt 1 F I LER
t·~EI.··'ER
CFtt·1E Ftt·f(~·~HERE NEAR' OPERFtT I ONAL
STATt~S,
AND IT IS MOST UNLIKELY THAT I WILL BE ABLE
TO
DO
MORE
WO~~ ON IT ANY TIME SOON~
I HAVE ABANDONED THE PROJECT.
FRDG~ESS

HENP"'"

t'lEHBER

SPENCER

OF

TECHNI'=AL

S:TFtFF

LECTRO-SCIENTIFIC INDUS.KIES CFFtRS A COMPLETE

I~P

EM N 1710~ CF T~E PROGRAMMING LANGUAGE PASCAL FOR PDP-ll
CJ~ UT R.
ALL THE FEATURES OF PASCAL ARE INCLUDED, PLUS
[

_ ..._I ....

/,

,',' "

f

~;

{'

EXT

! ! 'l -~

@

Timothy Bomham
University of Minnesota

Nov. 2, 1976

Dear Tim;
Thanks for your letter. We had noticed the smmll mention of
ESI Pascal in the last PUG newsletter and were a little concerned
because it made reference to the U. of III Pascal and implied that
ours was essent11lly the same. ESI Pascal was based on the U. of III
bootstrap compiler (not the student compiler they are now offering),
but has oeen so completely rewritten and reshaped that we have no
hesitation in claiming it as our own creation.
Briefly, our compiler
runs under RT-11 on any PDP-II processor in 16K or more and complLes
full Pascal with a few differences. The enclosed documents will
explain more.
Taking your pmints in order:
1)
John Ankcorn did most of the work on the compiler. He and I
are the Pascalians here and can be reached at this phone.
2)
All II's. The compiler source has assembly conditionals to
shape it for the desired machine.
3)
RT-l1, 16K words. We have an RSX-11M version in the works.
4)
see enclosures
5)
Our supplement is enclosed.
We are working on more.
6)
Probably will be one year of unlimited fix~s and updates
followed by an annual subscription service.
'
7)
Basically yes, but see the second page of the supplement.
8)
Compiler (Pascal to Macro assembler text). Fits in 12K
with the extra space taken by the symbol table.
See the enclosures.
John is preparing a paper describing many of the details.
9)
Excellent.
It has been used on our laser trimming systems
for more than a year, and we have assitiuously searched for and
eliminated bugs.
10)
The compiler is written in Macro-II. We started with the
U. of Ill. bootstrap, changed the syntax scanner, totally changed
tbe code generation, wr&te our own expression analyzer,and wrote
our own support packa~e for arithmetic, math and file handlin~.
Effort has been on the order of 2 man-years, thoufh some of this
time was spent on the applicatmons software for our systems.
It
was'the first complIer for each of us, \~hich is why we are grateful
to the Illin1 for their initial help.
.
I am not sure any of this is dFrectly suitable for publication,
and I think you should resist the newsletter becoming an advertising
forum.
Nevertheless, we immodestly think that ESI Pascal is probably
the smallest, fastest, most complete and most reliable compiler for
the PDP-II, and we are not about to hide our candle under a basket.
'I

David Rowland
manager, programming

,--fl.t~

~5

0 S FOR

HARD~AqE

CONTROL.

THE ESI PASCAL COMPILER RU~S O~ ANY PDP-l1 PROCESSOR
U~~~R THE ~T-l1 OPERATING SYSTEM.
NO OVERLAYS ARE USED,
A~~ ONLY 16K OF MEMORY IS REQUIRED.
THE COMPILER USES THE
PRI~CIPLE OF RECURSIVE DESCENT AND MA~ES A SI~GLE PASS OVER
TH~ INPUT TEXT AT APPROXIMATELY 3500 CHARACTERS PER SECOND

TWO FILES ARE PRODUCED; A LISTING OF THE SOURCE
INCLUDING ERROR MESSAGES. AND A TRANSLATION OF THE SOURCE INTO
MACRO ASSE~8LER CODE. THE MACRO CODE IS ASSEMBLED AND LINKED
TO A SUPPORT MODULE TO PRODUCE THE EXECUTABLE PROGRAM.
THE SUPPORT MODULE CONTAINS ALL THE PRE-DEFINED FUNCTIONS
AND PROCEDURES. PLUS A SIMULATOR FOR THE PDP-11/40 INTEGER
AND FLOATING POINT HARDWARE. TWO VERSIONS OF THE COMPILER ARE
AVAILA3LE: ONE THAT GENERATES PDP il/~O FIS INSTRUCTIONS (WHICH IS
USED O~ 11/03, 11/04.11/05 AND 11/40'S) AND A VERSION THAT GENERATES
11/45 FLOATING POINT.
THE SUPPORT MODULE CAN BE CONFIGURED
TO INCLUDE ONLY THE ROUTINES NEEDED BY THE PROGRAM.
(PD;>-11/05).

ALL THE PASCAl. DATA TYPES. DATA STRUCTURES AND STATEMENTS
ARE PRESENT. FORWARD PROCEDURES MAY BE DECLtRED. "NEW" AND
"DISPOSE" PROCEDURES ARE AVA ll.ABLE FOR THE DYNAM IC
ALLOCATION OF VARIABLES. PROCEDURES MAY BE DECLARED AS EXTERNAL.
PRE-COMPILED AND INSERTED IN THE PROGRAM AT LINK TIME.
ESI'S EXTENSIONS ALLOW VARIABLES TO BE FIXED IN CORE
AT A CHOSEN ADDRESS. THUS GIVING ACcESS iO THE
EXTERNAL PAGE 1/0 ADDRESSES AT THE PASCAL LEVEL.
ALSO. MACRO CODE CAN BE INSERTED IN LINE WITH PASCAL CODE.
BENCHMARKS INDICATE THAT PROGRAMS COMPlkED
BY ESI PASCAL WILL RUN APPROXIMATELY TWICE AS FAST AS SIMILAR
PROGRAMS COMPILED BY DEC FORTRAN IV, AND MANY TIMES FASTER
THAN PROGRAMS EXECUTED BY INTERPRETERS LIKE DEC 8~SIC.
ESI PASCAL HAS SEEN IN USE SINCE lHE SUMMER OF 1975
IN LASER TRIMMING SYSTEMS BUILT BY ESI.' IT IS NOW AVAILABLE
TO ALL PDP-l1 USERS. IT IS A SUPERIOR LANGUAGE fOR DATA
PROCESSING AND EDUCATION, .S EXTENDED BY ESI, IT HAS BECOME
AN UNEQUALLED TOOL FOR HARDWARE CONTROL APPLICATIONS.
PRICE OF THE SYSTEM IS $1500. THIS INCLUDES THE COMPILER.
THE SUPPORT MODULE. A CROSS REFERENCE DIRECTORY GENERATOR,
A SIMPLE TEXT EDITOR ANO AN INSTRUCTION ~ANUAL.

ELECTRO-SCIENTIFIC INDUSTRIES
13900 N~ SCIENCE PARK DR
PORTL'~C O~E
97229

(* David Rowland sent us the machine

retrievable user manual which accompanied this page. It is an impressive
70+ pages long! *)

::z:
<:)

fT1

3:
t:;:!

fT1
:;0

HITACHI HITAC 8800/8700
FOXBORO Fox-l

HONEYWELL

Warren R. Brown of the Foxboro Co., 0.330,38 Neponset Ave., Foxbora
MA, 02038. phone (617) 543-8750 x2023. has written to us "In response to
previous inquiries about the FOX-1 implementation of Pascal, we are
currently formulating a statement for later publication."

,

FUJITSU FACOM 230-38
FACOM 230-55

(an implementation exists)

6

(an implementation is being considered)

H316
A modified $010 (kernel) Concurrent Pascal interpreter is running on the
Honeywell H316. For more information. write or phone Robert A. Stryk of
Honeywell Corporate Research. home address: 5441 Halifax Lane. Edina MN 55424.
office phone: (612) 887-4356.

6000, LEVEL 66 SERIES

(an implementation is underway)

(see also Newsletter #5)

University of Waterloo

HEWLETT PACKARD HP-2100, HP-3000
THE UNIVERS:'r f Dr ;;ANTA CI.At!A· Cl\LiFOHNfA' Q5053

SERIES

(see IBM 360/370 series)

November 8, 1976

W.llt'llm), Onl.ui(), [.111 ....<1.1

N:!l.JGl
TEL: 984·4482

M.lI!1"lll.lllI . . I.ludly Computing r.Hihly
Diu'( 101: lill) nWi· 1.211

Mr. Timothy Bonham

Pascal Implementations
University Computer Center
227 Exper:iJlIental Engineering Building
University of Minnesota
/'linneapolis, Minnesota 55455

August 25, 1976

Dear Mr. Bonham:
In response to your letter of October 22, I have taken over responsibility
for Pascal implementation here at Santa Clara from Dan Lewis. There has
been essentially no progress on implementation since the last contact with
George Richmond in May of 1975.
Current plans are to initially implement Pascal via Pascal-P on the University's
HP3000/Series II, which is running under MPH with 256 K words of memory. A
very rough cDnqlletion date is January, 1978 (we hope to beat this, but given
the realities of implementor time availability, January is as good a guess as
any).
Following completion of this task, we intend to implement a (still undefined)
subset of Pascal for the Department's HP2100, running under DOS III with 32 K
words of memory. The implementation will be in Pascal and cross-compiled from
the 3000.
I'll keep in touch as

t~e

implementatiOn progresses.

Incidentally, I've enclosed

my

PUG membership· application.

Mr. Andy Mickel. Editor
Pascal Newsletter
University Computer Center
227 Experimental Engineering
University of Minnesota
Mi nneapo 1is, M~I 55455

Dear Sir:
.

Hav~ ng

jus t read the PASCAL News 1etter Number 4, wi th its
attent10~ the PA?CAL 1m~lementation for the Honeywell 6000 and level 66
Se:1es'lIII~h1nes wh~ch we completed for Honeywell earlier this year.
Th~s c?mp1ler, an 1ndependent implementation of the full language
WhlCh 1S not related to any previous PASCAL compiler.has been a commercial product of Honeywell Information Systems since ~~y 1976. To
m~ kn?wledge, it is the first PASCAL implementation to be officially
d1strlbuted through and maintained by a major manufacturer.
l~st of PASCAL l~plementations. I thought I should draw to Your

Yours truly.

Sincerely,

../
RonaldL. Danielson
Assistant Professor
RLD:dlm

Encl.

WMG:cm

.\

,i;. "'c:.,.:~.,

I~. Morven Gentleman
Director

(* note: manuals are available from Honeywell Sales *)

00

o

Pileslredet 32

RIKSHOSPITAlETS EDB-AVOELING
UNIVERSITY HOSPITAL, OSLO; COMPUTER OEPARTMENT

IBM

Oslo I, Norway
T<~/efon

SYSTEM

360/370

(this section also includes the Hitachi 8000 series
and the Amdahl 470. see also Newsletter #5)

-" (02) 20 1050

:-',':1"
,C J"'

rn
,

:~

,~ '.)

::E

'. '/'

,

,

(/)

rn
PASCAL 8000 Implementation Note

1.

Implementor:

-l
-l

November 5, 1976
.!"A:"'C-JJ l"~Cr~r:; :':'~Y'C'J\j:;
e/() :\:::d' J ·:-;.c~:eJ"

Terua Hikita and Kiyoshi Ishihata
Department of Information Science

~~n i'JeL'~;::_t-·r

'~~0

University of Tokyo
Tokyo 113 Japan

i;r:i.\,O?1.;~~it··

0"'"

;"::;/.

""u'L i

rn
:;:0

1

\....

~j.

1..

2;:-

'~:,

1.1"0-1 (:(;:"""

0~

"':~ll.-'

;·0.·:~/'/S

l:?r~

'.~~.ti-l

()~"i':-·;-~ti_n-,

,:'o:;t r;r,~'::-~cn ·}·In.-(I')c~r,~tir',
j ~~ s: ·:::!.l i;l~.>"t'lJ.l'Tti;)n-:;

t'!,::
tl'::e~~

r,~c(:~~~r;~r._

i~

d()-j'~~tj,~:.

level.

A few nove] language features are
included ~

8.

9.

Charact.eristics of the c.on,piler:
Written in Pascal (about 5200 source
lines).
Compilf·r object size iR about 100
kbytes.
Compiling speed is about 350 line/sec.
Execution speed is comparahle to
FORTRAN-compiled obj eets.
Reliability of the compiler: Good

10. Method of development:

Modified Naegeli's trunk compiler and
bootstrapped it by Pascal-P
(about three man--months).

:z
o

OJP

3i'.~ i~ to lJ~e ?asc21 ~n 2 ~ro~uction cnvi~on~en~
~:'l~~ ~__:IJ2.'
0::- ·,'.'0r'<: i-:-; .ir. t~:::~ £il~-nroc0~ssir:i: ::i'21d.

i,.rll'""'.:'"""":

i.p. ·t'10
It1P";r:'
T:js

:~j~iris·tr,ltic~

(econo~ic

~~:l

ot~e~)

of

~

·;c--3~)itJ:.

~!"'"l:r

-r;~"'()'·",T~'-'.:T!11~5.n"'"

ctPJ"1 C~~~';"YJ,

,'r.c since

111.'!"l":1.1.a,--:e::>
~.Te

~"1ave

,"

2.vai} 2fJle

,000

3!.'e

ro:tT'u\::

r:.;R:'RA:'~-!1lili(.::u,

::;:'~~;:;t~~n~~' i~~;~~~h ~v,~~ ~~')~~~~";~~i~~=--'~~~::s~ ;~~

le~~t ~~rtial17) Wit~l P~scal.
~~owev~r, i~ S~it2 of
\':0
vi Y't '--Ie. s of ~a,sc21, ~ t 1'1':')([; t~e necr;s.c; -'.!"" ,
f~clli·ti~3 [O~ C11~ ~~nrl of ~~~lic~tions.
A nu~~~r
o"~ .feAt;lrc:, ~··!il2. ';i€: .--L.;i,J (re':>~~'\"2(:) H(\~.''-.~ ex"tE;!."r-11 to ,~n ordinary
".3._'I:·init';.0p. t::i 11. (>J.U';,~ -~].l vari -11')les o,~ ti1A.t
to
~.llloc,'1te( as sr::';~2Pt::t(; f'1oduJe3.
r-:'~le n2;:-}2, of
eac\ ::-.c'f:;ule is til(~ vc;ri~!.DIC-r1c~r,:~.
r_"'~lis alloca.tion is
s tr.!t i.e , t:-1>3 vari3.·:)l.·~ of t:10 eX-3..m~J'3 is not allocated on
the Y"un-time stRCK, but the scope of ·thp- v,.=J.riables the
Droced~lre U;l~re it is (jcr.lar~d.
It is c')er;F'tT.'S ~)\~st
:';JV~0~OS tocc ;)'/ CO:T',!2.rir_~
i t F.~_ ~:'l T"'()?':'i~l\'l' S :!j~:~F~
C,;'·~:IU:T (ou~'" '·~I·~in re,l.S on f 0-·...,
it), or

for data transfer.

r,,::cClY':
t~·'T"e

~~3/VS

~e

m0"

!lfile-~an2

has no

use? to

(Iescri~p

,er'l
th~

~lhere

£ile

Job-Control-Lan~ua~e
(recorri-ler~th,

'blocLi_nnf-fa.c,tor etc.).
This forces ilS either to
Y::.-3.k2 au::.'" c:..;!~ ~~i l.<2-T~?,n.-::t,-er-' ~.1:;_i:~'! 3. s<::·-:;citl.l r::(:~"}trc).
12n~u2?e

l',"e !1r..\l~.2

:i.''; thr:c
}:'?FTl

CP to
chc:;:~en

"t:.:-:,:..;~"

011"('

\lc"l'l:;5

~a~:2

SOt~i~ications

to PascRl'g

s~'nt~x.

::;le. £ir.')t alte~_--'n.-'3.tivc, not b~C3.UE;e it
soluticr:, ~ut r,at'1er 1)ec~use lie ·'~,·'.nt "to
C~

or

:::,l':~

12n.:~ud.... 2.

COf'lTJ":ti:,lc

Hit')

tl.ll?

stan:~2-::':"~.

"the
'1"';1"3

Er.:'3tU~:"93

":'(~.:.:;c.'.J.

o~ly

t~R

S'lryn~rt

fo~

sep~rdtp

cor

.-'-:

~~~~7::?

r,~2r,tior;r~"j

-~;"'~'or·T:,.~:nt ~~0r us
CCLI~::::·~:.; en t'l'~'; ,
~('lJ\j~

It is not

STf::~'I

r ..:;~;--,,:,

PC:·=:tt

,_

:i:':;.\.:: SUT":-or"t for t'lt':: in-teY"'-l'Jn;:;u03 ;-::
cor.:.~~.1.:r:icd'-:.:5. on, tc ~r.:, abJ.e to r:~J_~" rOllt .~nes \·"e_'!.. ttcn
0::

i\1'3

-Lf:'

DT::1':~~'

::"an

,13;' S~,

I:J1'!e~~v::~r'

·t:l'2?

a.r'~

u·;eY'-~·.71"'ittr·~

3::·;J.ic·"}tic' n T'outines, l.:i_~--:-r;:l."r~l n!"'o;:r2;'1S, sClY'tin,;,-,
0-":!t'1.-1"""a.s·;::- OY" un.t 3.-COFlf'!tlnic·""::"t;.CIl s0ft\'.]3Y';.
r

c
~'-.li).Y'

externaJ. 1roc~dures ~~e us?d, t~e d~t3-tran~fcr
hetw0pn ~hen vlll create l):coL!J.-:=:~ns sir.ce ~:loj)al v.J.l"'i~:~~ 12.
:11<1y not be accessed, an(] since the data-~r~nsfer tl1rou~:1
?.-1.raT'letY"es h~~ certain limitations.
\':e it·?'!:':
i!1"':Y'0'-;llC-2(~ ? )'l(2 t.' <~t:~, t~.'''":'z''!-Cxt2Y'r..al r8c0""'ds.
~~cn

~..I,=:.>-?.?~:

"'~/(' j,~-n-----

"l!-rD~'

I.~/j)~7G03t]9

00

N

NEW MEXICO TECH
r ....'M!·UTCR CENTER

SOCORRO. NEW MEXICO 87801

September 20, 1976

Mr. Andy Mickel
University.Computer Center: 227 Exp Engr
University of Minnesota
··1Iil1lleapoHs, 'Minnesota 55455

. Dear Andy,
We have been working on'a PASCAL. compiler for the 360/370 series
for the past year.' The compiler.design was done by Dr. Jan V. Gar~ick, with imple~ntation by Dr. Garwick. Paul Merillat and myself
·In Pl360 and ChriS Strachey's GPM. We are about 95% done. and it
is a full compiler for PASCAL with the following exceptions~
1)
..2)

Andy Mickel
September 20, 1976
Page 2
We have been testing the compiler for about a month now, and
the :esults are good. Runtime facilities are still undergoing debuggIng, but should be completely done by September 31. We are going
to use the compiler in .(Jur introductory C.S. course, and hope to unearth pathologies that would not come out in use by an experienced
. PASCALer.
j)istribution .of.anJlS·version lS -exrected to start by January
···1s1:.• ~.Dr_ T_ltiirt.term-nur LS..

flimdle'inquiril!5-

.If anybody has any questions about the compiler (other than
.'.distributional). I would be glad to answer them.
'Ve

GOTO's and labels are unsupported (and are flagged with a warning
i f used).

think the PASCAL newsletter is great. keep up the 900d work.

o
<:
I'T1

UNPACKED arrays ·are not supported.

5} Sets of.characters.are not allowed.

~-¥il1

RK:pq

4) Tag field specifications in NEW and DISPOSE are ignored, the'
record is allocated ~ith the maximum space needed .
.. -5}

Procedure or program segments each must not exceed 4K bytes.

6} A predefined procedure, CLOSE. has been added to facilitate file
opera t ions.
Extensive compile time and runtime error checking is done. The
runtime checking is optional, and the compiler will generate runtime
chec~s b~ use of a toggle which may be set or reset at any time during
compIlatIon. There are extensive compile time facilities, including
a reformatter and cross.referencer.

00
IoN

AN EQUAL OPPORTUNITY I AFFIRMATIVE ACTION EMPLOYER

- 2 -

STONY BROOK's PASCAL/360 - A STATUS REPORT - NOVEMBER 1976

,

The Stony Brook Pascal Compiler for IBH 360 and 370 computers
is alive and welL As of November, 19]6 more than 65 copies have been

be compiled. The design target on the Plain storage requirement is l20K
bytes. Compilation speed will be improved, primaril>' through the use
of corefiles and interpass data oon~unication buffers to reduce I/O.
The compiler already includes excellent syntax error recovery, intelligible error messages and runtime diagnostics that enhance its usefullness

issued, and several installations are using the compiler under a live

in education.

load. The compiler project continues at Stony Brook, and a second
release .is planned for January, 1977.
Release 1 was issued in June, 1976.

It provides an almost com-

For those interested in acqulrlug the Pascal/360 compiler, the
cost is $175.00, which includes distribution, complete system documentation (when available), and maintenance at least through August, 1977.

plete implementation of Standard Pascal except for a variation iri the

means of specifying print field widths in the Write procedure. Not
implemented . . in Release 1. are nonstandard.·.files"and the . standard procedure Dispose. The compiler has been successfully installed under the
.OS/lIVT, NFT, VSl and VS2 operating syster.ls,and::under VH/Cl1S with modifications to the as interface. A DOS interface is near"ing completion.
At present, the main storage requiremerrt,is 160K,byt.es including space
~or file buffers.
The compiler is coded in ,XPL~ with an assembler-coded monitor
that provides the interface with as. tve do not have good statistics on

compilation speed, but Release 1 has 1. 93 CPU·-second overhead to compile
a trivial program on a 360/65. This is believed to be mainly due to the
complexity of opening and clOSing files under OS/360.
The execution time of several cOl~piled Pasc~i programs has 'been

,compared with that of equivalent translatiQn,intoALGOLW, whose compiler
is known -to produce good, though not opt_imized ,.code.

The Pascal programs

execute faster, in nearly all, cases.

Although it would be f;olharcly' to.

allege~hata ~ompiler

that has

been field-tested for less than six-months is bug-free, we believe that

the majority of errors have probably been corrected. The three updates
have repaired all errors reported as of November 1, 1976, as well as
. improving the resiliance of the compiler in the presence of Pascal source
program errors, and reducing the storage requ~rements from 180 to 160K
bytes. Updates are issued in the form of source-language (XPL or BAL)
patches to be input to a card-oriented editor. Both the editor and an
XPL compiler are furnished on the distribution tape.
Present work is directed toward completing the implementation of
nonstandard fi,les, management of heap storage, and external compilation,

all of which will be included in Release 2. This release, subject to
late~ updates to correct errors and impxove performance, w~ll be the
production version of the compiler.
Future work-will be directed toward producing an edition specialized for student use. This will offer the same capabilities in a compileand-go version, except for a limitation on the size of programs that can

A 50-page User's guide is available at a cost of $1.00 per copy
in CJ,uantities of a dozen or more. The User's GuidE: is in.t.ended'as'a
supplement to Jensen and Wirth, and tells everything that· a user needs
to knot..,. about the compiler.
At no cost whatsoever, one can obtain a packet giving additional
information on the Pascal/360 compiler by sending a request to:

Pascal Compiler Proj ect
Department of Computer Science
SUNY ,at Stony Brook

Stony. Brook, New York 11794

o

-<
fTI

UNIVERSITY OF MINNESOTA

University Computer Center

I

227 Experimental Engineering Building

lWlN CITIES

Minneapolis. Minnesota 55455

(612)37~

17 September 1976

6-7290

I

(/)

r-

rn

Andy Mickel
PASCAL User's Group
University Computer Center
227 Experimental Engineering
University of Minnesota
Minneapolis, MN 55455

--I
--I

Sept6lllber 24. 1976

rn
:::c
Dear Steve,

I felt

&

tWinge even as I

11&8

pu.tting your letter into the last

m.J in your op1n1ons

Dear Andy,

newsletter.

I was quite surprised to see my last letter to you printed
in the Newsletter. Nevertheless, since it did appear, I feel
compelled to follow up on my comments about the Stony Brook PASCAL
compiler for the IBM 5/370.

outweighed the fact that I gave you no warning that it would be printed.

At the time I wrote the letter, the compiler was, indeed, buggy.
response from them has been excellent. I have since received
and installed two updates; the cover letter with the second stated
that it fixed all reported bugs. I have since run at least one
medium-to-large (700 statements) program using it, with no trouble.
And the post-mortem histogram -- showing how many times each statement
was executed -- is a most useful feature.
However~

Complaints about the compiler? Sure, there's always something
that could be improved. The compiler is a bit too big (180K), and
a bit too slow for small programs (high fixed overhead per compilation),
and, perhaps most serious, they omitted the standard formatted-write
notation. And it would be nice if the compiler wrote out standard
OS-format object modules.

I feel that the interest that other :persons

I'll

glad you wrote a follow up letter and sent a copy of it to SUNY Stony Brook.
And I'll glad that their cOlllpUer 1s work1ng better, also.
so

brd

P\umy, we struggle

::z
o

just to get t1dbi ts of 1nf'ormation.

As I guess you can tell from Newsletter

#5.

we are tr,ying to push hard to

<
rn

repair the ccm£'usion about Pascal !mplementations;
So, thank you very much for writing.

I'll of course prl,nt your letter

in Newsletter #6.

S1ncer61y.

I should note that I ordered the Stony Brook compiler in
preference to the Manitoba version, since it seems more suited to
use with production-quality programs. Particularly serious restrictions
(from my point of view)- in the Manitoba compiler are its lack of I/O,
its lack of a full version of NEW, and its restriction on the size of

':,0000"'"

'

En reponse a votre lettre du 25 Ocotbre 1976 voiei Ie point des travaux
faits sur Ie compi I.ateur Pascal.
- I I est operationnel sur
360/67
avec
5/U/14H a.~_

OS/HVT
VS/M~T

- Demande REGION 220 K pour s'autocompiler.
_ Distribution sur bandes ma"netiques 9 pistes/SOO bpi.
_ II existe un supplement au manuel du langage Pascal, deerivant I'implementation sur IBM.
_ Langage Pascal accept& est conforma au standard 74 a quelques oxceptions
pres.
I I manque HCJhat under 32;(.

4.

No distributic'Il since

5.

No docllmentat;on avoila"le let.

6.

This compiler is, more 0= less, my 110htlY so a
maintellcc poliq, can:l0t he stc;ted.

il~pleTP.e;1tation

is not complete.

~;ccific

7.

Th:]s implenwnta!ion is cf a ::t.:bset nf PASCAL which I call
P/\SCM_-~[ (PAS:AL for nicroproccssors).
Due to the 'Jery
limited resourc(>g of Jllic.:rop'::-:.cesscrs, ?:\,5'CAL-~1 does not
inc~ude the fol~owing PASCAL features:
a.
no files - ,3.11 I/O via PEJlD, WRITE
h. no Ri:AL :yp~
no decllred scalar tyre.s
ci. no \"ari·;~nt records
e. no LAEEL seci~i·:ln
t,
no [0',0 s tatemerLt
g. HO WITH statement

h.
i.
j.

n-) FOR statelf.ent (use WllILE instead!)
no r.ASE statement
(l!lay be put: back in)
no run··time checks yet

k.

standard procedures are: READ, WRITE, NEW, RELEASE,
READLN, WrUTELN, ORD, (;HR, EOLN, MARK
It is possible that the final implementation will have the
CASE state",ent reinstated and that I may produce additional
implementations for those having PlOre resources to include
REAL and PI LE types.
8.

9.
10.

NCR CENTURY 100. 200. 300

(no known impl ementations)
rn

PHILLIPS P-1400

(a non-standard implementation exists)

,

(/)

rn

PRIME P-400
Phillip H. Enslow of the School of Information and Computer Science,
Georgia Tech, Atlanta, GA 30332, has informed us that Georgia Tech is bootstrapping a compiler for the Prime P-400 using Pascal-P4. The P-400 is a
large "mini" with a 32 bit word, and 512 million words of hardware supported
virtual memory for each of 64 possible users.

SEL 8600

rn
;::c

SIEMENS 4004/157
H.-J. Hoffmann of the Fachbereich Informatik, Techn. Hochschule,
Steubenplatz 12, J).6100 Darmstadt, Germany, wrote us: "We have implemented
PASCAL P2 in three different versions (fully interpretive, SC-code automatically translated to assembly language, code emitters for assembly language)
for SIEMENS 4004/157 computer. Usage in some systems programming work."

The reliability of the compiler see",s to be excellent.

TELEFUNKEN

developed from PASCAL-P2 and is being crosscompiled by !like Ball' 5 UNIVAC 1100 PASCAL. I would
estimate that about two man-months 1ave gone into this
implementation and I expect that about one more man-month
to complete it. I have found the PASCAL compiler much
easier to work on and understand than I expected and I
believe that this is attributable to the language it is
written in (PASCAL).

-i
-i

(an implementation exists)

The compiler produces an intrepretive code which is output
onto an external medium such as paper tape which is then
loaded with the intrepreter for execution. The compiler
is "ritten in the subset of PASCAL which it compiles and
is about 2200 lines of code. The compiler should compile
useable programs in under 32K bytes. The compilation and
execution speeds can not yet he tested.

PASCAL-~l

::E:

o
<:
rn
to

TR~440

(an implementation exists)

rn
;::c

was

TEXAS INSTRUMENTS TI-ASC
TI-980A

(an implementatIon exists)
(implementations exist)

I will be preparing both documentation and reports on this
implementation of PASCAL for publication once implementation is
completed. For your information, all that remains is to dehug the
tf-CODE (what I call my interpretive code, like P-CODE) inte~p~eter.
Sincerely,

!

i )~ .. .I:. '/".~ <:'7:r;~

I·lark Rustad

00
00

UNIVAC 1100

SERIES

installation.. Perhaps this data could be published in the newsletter as it
hecomes available? Sinec we are promoting the language as le:aJing Lo portability,
we should practice what we preach.

NAVAL UNDERSEA CENTER
San Diego, California

92132
2 November 1976

Hr

0

Finally, wher(~ can I obtain copies of the new document's from Wirth's group.
am particularly interested in t,he paper on PascaJ.-S.

Andy Hickel

Hinneapolis, HN

:E:
C/)

rn
-I
-I

~~:.,~. r/~' ,,~cJ

55455

=
rn
r

Sincerely,

University Computer Center
227 Exp Engr
University of Minnesota
.\

I

rn

Hichae 1 S. Ba 11

:;0

Dear He.. Hickel:
Thank you for the Pascal newsletter..

I just got number 5 and enjoyed it greatlyo

As you know, We, have a quit.e complete implementatioll of Pasc<31 for the Univac
1100 s0ries. I have enclosed some performance data on the compiler and generated
code which you may find of interest" We kept the implementation as close as
possible to standard pascal, with extensions only to allow interface to the
Univac Exec~ and for compatib.ility with other systems whose code we wanted to
use. The restrictions are essentially the same as those in the CDC compiler ..
We have been using the Pascal compiler for about nine months:> and its reliability
has been quit€-' good.
It should soon approach excellent.

We are using the compiler for general purpose programming and "systems" programming
for the Univac and other IDdchines., Its usage is steadily increasing, and is
currently ahout 60 to 70 compilations a day,
This compares to Fortran which
is about 600, but of course, each Fortran subroutine is counted se_parately. User
response has been quite favorable:> and the interface to the user is at least as
good as the rest of the language processors available for the;> 110 series. A
large, but unknown, pprcentage of the use is interactive (demand mode in Univac
terms).
One major ust' of the system has been the development of compilers for Concurrent
Pascal and Sequential Pascal for an Interdata 7/16. These compI1ers are based
on those supplied by Per Brinch Hansen, and generate machine code for the 7/16.
They are currently uperating as cross compilers, running on the Univac 1110 and
generating code for the lnt(.'rdata~ We are currt'.'lltly in the process of moving
them to the Interdata for self-compilation" The project has been a very
interesting ('xercise in maC"hine independence, and the code which must be changed
when moving the compilers from the Univac 1110, a 36 bit l's eomplement machine,
is surprisingJy small.. loJe have nut measured it accurately:> but it is on the
order of one to two percent v
These compilers are highly optimizing compilers, 'and the direct machine code
which they generate is up to twenty perc?nt smaller than the interpretive version
generated by the original co:upLl ers. Since there. was no attempt to make the
interpretive code compact, this is not surprising. The next project along these
lines is to modify the compiler to gpoerate code for the Interdata 8/32.

PEHFOP1.~'t!CC OF THE Pl\SCl\L 1100 SYSTEM

The following performance \-las measured on a Univac
arc totals, including both CAU time and CCER time.
1.

1110~

14 October 1976

All times given

Compiler Performance.
The

cornpil(~r

performance vIas measured as it compiled itself.

The

compiler is 7,494 lines of code, inCluding conunents and blank lines. It
compiles into 34,875 words of code and literals~ The library adds 5,912
Viords (including some d:3.ta area), for a total of 40,787 words. The Univac

=
o
<:

rn

compiler interface routines account for 4,685 ,..,ards 'of the library~
The
data space allocuted for the compiler is 16 , 1GB t.vords, and while compiling

itself the compiler USes 8,068 words in the heap and 7,444 words in the
stack.
The compilation rate is 105 lines per second \vith an output listing,

and 118 lines per second without a listing.

The compiled code \vas cOI':1.pared \vi th that generated by the NUI\LG and
ASCII FORTRAN processors. For both Pascal and NUALG, tests were done both
with and without run-time checks. The FOR'rRAH compiler never generates
run-time checks, but does allow for three different levels of optimization~
'l'he normal mode provides no. optimization, and optional modes provide local
and global optimizations. The local optimiza-tion mode ,."as chosen as the
standard of comparison, since the short test programs ,·]hich \oJere used
provide an unusually simple case for the global optimizer, and allow it to
perform much better than would be expected for the average program.

The programs used as a basis for comparison were taken from \\lirth I S
'l'118Y are Dll programs ".Ilhich are
easily written in all three languages, and so do not use the expressive
po\ver of Pascal. In addition, the time taken t.o call a simple procedure
o/ith four value parameters were measured for each processor~ The results
are surrunarized in the following tables.
paper on t!JE: d.:;;sign of a Pascal Cc;npiler.

One problem whic.h we have is kt>eping up to datt-" on various extensions and c1wnges
to tile CDC compilers. As you mentioned in the newsletter, this c{lmpiler has
served as an unofficial standard for compatibility, and we would like to know
about things like the "VALUE" section before we see them in some code from another

-u
;bo
Gl

rn
ex>
lO

'"'0

:J>

ReI

P.ZlSCAL
~

0.62

PASCAL
NO CHECKS
Time
~
9.17

fT1

0.61

NUALG
NO CHECKS

NUALG
~

~

0.85

12.88

~

12.67

~

PARTNP

1.10

1.18

0.99

1.06

3.06

3.29

2.95

3.17

24.61

1.37

20.22

1.12

32.92

1.83

26.B1

1.49

18.70

1.B2

14.69

1.43

21.02

2.05

17.46

1.70

4.99

0.30

4.69

0.28

12.15

0.72

11.13

0.66

FORTRAN
OPT.
~
~

15.10

1.G

15~10

1.00

14.94

0.99

0.87

0.94

0.93

1.00

0.79

0.85

SORT

18.01

1.00

18.01

1.00

10.56

0.59

MATMUL

10.27

1.00

10.26

1.00

4.04

0.39

,COUNT

16.88

1.00

16.83

1.00

16.40

0.97

PARTNP

Califomia State University, Chico
Chico, California 95929

-0;:

U)

r-

"

fT1

--I
--I

Department of Computer Science
(91&) 895-6442

fT1

November 2, 1976

:::0

"!t:

FORTRi,N
ReI,
~
PART

::;:

~~
~;rJ

0.84

9.36

COUNT

:J>

r-

Procedure Call Times.

PART

SORT

n

implementations)

Table 1.

~

kno~m

(no

V73

l.00

4.96

1.21

U)

VARIAN 620

21.9

108.6

26.4

'rime

FORTRJlN

NUALG

PASCAL

r,QCAL

FORTRAN
GLOBAL OPT.
!!~

.8£!.

m
Mr. Timothy Bonham
Pascal Implementations
Unive.rsity Computer Center
227 Experimental Engineering Building
University of Minnesota
Minneapolis, MN
55455
Dear Mr. Bonham:
. Thank you for your interest in our activities at
State University, Chico.

Cal~fornia

Due to some staff changes, our Pascal project has
not been completed. The implementation is planned on
a Varian V73. Pending the completion of hardware
changes, this project will remain stagnant for at least
another year.
Sincerely,

Table 2.
The program listed on the left side of Table 2 are:
PART

compute the additive partitions of a number (30 in this case) and
print tho results. This uses recursion for Pascal and NUALG, and a
hand simulated stack for FORT?..AN.

PARTNP

the same as above, but with no printing

SORT

sort an array of 1,000 numbers by a bubble sort

I4ATHUL

matrix multiply of t~o 100 by 100 natrices

COUNT

count,the characters in a file and print the number of times each
occurs. The file was 124,000 characters long.

~1.:f~
',1. S. BALL

,

,

I

I

"

1),:/ \
; ' ...

L'

Orlando S.: ,Madrig 1, Ph.D.
Chairman &iprofessor
Department of Computer Science
OSM:lt

XEROX

SIGMA

6,

SIGMA

7,

SIGMA

9

(see also

elr

10070)

Olivier Lecarme. Universite de Nice. Laboratoire D'Informatique.
Parc Val rose, 06034 Nice Cedex. France, in his letter of 16 Sep 76:
"A complete and standard compiler for the Xerox Sigma 6,7 and 9 has
been don~ by Pierre Desjardins, who can give you all desirable information.
Anyway, lt seems to be a very good implementation, especially in the domain
of compatibility and conformity to the standard."
(* We do not have Pierre'Dejardin5's correct address, can someone help? *)

'"'0
~

Ci">
~

..

<.0
0

ALL PURPOSE COUPON

PASCAL USER'S GROUP

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

USER'S
GROUP

Clip, photocopy, or reproduce, etc. and mail to:

/ /

Pascal User's Group
c/o Andy Mi ckel
University Computer Center
227 Exp Engr
Uni vers i ty of Mi nnesota
Minneapolis, MN 55455
(phone~ (612) 376-7290)

P
renew my membership in
,
next.
lease enter me as a member of the PASCAL USER S GROUP for the current Academlc
Year ending June 30. I shalf receive all 4 issues of PMc.ai. Newl.>leftVt for'
the year. Enclosed please find $4.00. (*When joining from overseas, check
the NeLU6leftVt POLICY section for a PUG "regional representative .*)
,
<

ll

/ / Please send a copy of PMcal NeLU6lefteJt Number
Enclosed please find
.
$1.00 for each. (*See the NeLU6letieJtPOLICY section for tssues
out of print.*)"
_...
.-.".

-

."

/ / My new address is printed below. Please use it from now on.
old mailing label if I can find one.
/ / You messed up my address.

S~e

1111 enclose an

below.

/ / Enclosed are some bugs I would like to report to the maintainer of the
version of Pascal. Please forward it to the
------~------~--~--appropriate person so that something can be done about it.
/ / 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 Pahcal N0Wl.>lefteJt.

I / None of the above.

Other comments:

From:

name _________________
address

---------------~~----------

'phone ________________
date

---------------~------------

(*Your phone number hel ps facil itate communi cat; on \'Jith other PUG members. *)

,

return to:
University Computer Center
University of Minnesota
227 Experimental Engineering Building
Minneapolis, Minnesota 55455 USA
return postage guaranteed
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 10:49:37-08:00
Modify Date                     : 2011:06:15 10:57:22-07:00
Metadata Date                   : 2011:06:15 10:57:22-07:00
Producer                        : Adobe Acrobat 9.43 Paper Capture Plug-in
Format                          : application/pdf
Document ID                     : uuid:f80a56e0-1cfc-456a-a52f-456da2581e8e
Instance ID                     : uuid:9e77745c-37a3-47ab-a6de-fa0d6cf1643b
Page Layout                     : SinglePage
Page Mode                       : UseNone
Page Count                      : 94
EXIF Metadata provided by EXIF.tools

Navigation menu