18 April 1973
.br
.sp 4
Dr. William A. Wulf
.br
Department of Computer Science
.br
Carnegie-Mellon University
.br
Schenley Park
.br
Pittsburgh, Pennsylvania 15213
.br
.sp 1
Dear Dr. Wulf:
.sp 1
.br
     I am sorry to have delayed so long in responding to Project
Rosetta Stone.  I completed the first three problems in a day, but as
seems to have been the case with others, I got hung up on Problem 4.
Not having time to do it myself, I tried to get one of the students
associated with Project MAC to write the MIXALL assembler during the
MIT Independent Activities period in February.  He promised but never
delivered.  Consequently, I am sending along solutions for only the
first three problems.
.sp 1
     The Multics PL/l language is essentially ANSI PL/I with very
few restrictions or extensions.  There are no major changes to
the syntax.  There are a few builtin functions which relate
specifically to Multics.  We believe the
quality of the generated code to be very qood.  The Multics
PL/I compiler is written entirely in PL/I.
If you could send me another copy of your language information
form, I'll be glad to give you more data on Multics PL/I.
.br
.sp 1
     I have included compiler listings as well as source decks for
the three programs.  Please be careful of the source decks since they
contain no sequencing information and there are many blank
cards present (because of blank lines in programs).  I tried to use
fewer than 72 characters per line, so there should be a single card
for each source line.  Any line longer than 72 characters will cause two
cards to be punched. I am enclosing documentation on the card code
used by Multics.  If you have any difficulties reading these decks
on your 360, let me know and we can try some other method of transferring
the source programs.
.br
.sp 1
     Some specific comments on the individual programs:
.br
.sp 1
1.   This is a straight conversion of the sample program and is written
in ANSI PL/I.  The arrays "a" and "b" may be un-connected.  I did not
execute the object program.
.br
.sp 1
2.   This is also written in ANSI PL/I.  Mote that the internal procedures share
the stack frame of the external procedure.  If you looked at the generated
code, you would find that most of the time is spent preparing argument lists
since this (in general) cannot be done at compile time in Multics.  I did not
actually test this program because of the size of the test environment required.
But having programmed problems very similar to this before, I am sure that
the program will work (barring typographical errors, of course).
.br
.sp 1
3.   This program contains one deviation from ANSI PL/I.  The Multics compiler will
map references to the external variable "m$" into references to an external segment
"m" residing in the permanent file storage;  the Multics system will create
this segment if necessary.  The program, as it stands, would execute in any
PL/I environment which allowed arrays of this size, however.
The array "two" which is never changed is recognized as being constant and
is stored in the text section.  Lines 67 and 91 are needlessly complicated by
the fact that PL/I lacks an exclusive or operation;  the generated code is quite
simple.  This program was extensively tested and is believed to be correct.
.br
.sp 1
     I am looking forward to seeing the final report from Project Rosetta Stone.
Let me know if I can provide any further information.
.br
.sp 3
.indent 40
Sincerely yours,
.sp 4
Barry L. Wolman