PSL progress report

[Griss at UTAH-20 (Martin.Griss)]

How was common LISP meeting?
Did you meet Ohlander?

Excuse me if following remailed to you, seems to be a mailer bug:
                            PSL Interest Group
                              2 December 1981


     Since my last message at the end of October, we have made significant
progress on the VAX version of PSL. Most of the effort this last month has
been directed at VAX PSL, with some utility work on the DEC-20 and Apollo.
Please send a message if you wish to be removed from this mailing LIST, or
wish other names to be added.

	Martin L. Griss,
	CS Dept., 3160 MEB,
	University of Utah,
	Salt Lake City, Utah 84112.
	(801)-581-6542

--------------------------------------------------------------------------

Last month, we started the VAX macros and LAP to UNIX as converter in
earnest.  We used the PSL-20 V2 sources and PSL to MIDAS compiler c-macros
and tables as a guide. After some small pieces of code were tested, cross
compilation on the DEC-20 and assembly on the VAX proceeded full-bore. Just
before Thanksgiving, there was rapid progress resulting in the first
executing PSL on the VAX. This version consisted mostly of the kernel
modules of the PSL-20 version, without the garbage collector, resident LAP
and some debugging tools. Most of the effort in implementing these smaller
modules is the requirement for a small amount of LAP to provide the
compiled function/interpreted function interface, and efficient variable
binding operations.  The resident LAP has to be newly written for the VAX.
The c-macros and compiler of course have been fully tested in the process
of building the kernel.

It was decided to produce a new stop-and-copy (two space) collector for
PSL-VAX, to replace the PSL-20 compacting collector.  This collector was
written in about a day and tested by loading it into PSL-20 and dynamically
redefining the compacting collector. On the DEC-20, it seems about 50%
faster than the compacting collector, and MUCH simpler to maintain. It will
be used for the Extended addressing PSL-20. This garbage collector is now
in use with PSL-VAX.

Additional ("non-kernel") modules have also been incorporated in this
cross-compilation phase (they are normally loaded as LAP into PSL-20) to
provide a usable interpreted PSL. PSL-VAX V1 now runs all of the Standard
LISP test file, and most utility modules run interpretively (RLISP parser,
structure editor, etc).  We may compile the RLISP parser and support in the
next build and have a complete RLISP for use until we have resident LAP and
compiler.  The implementation of the resident LAP, a SYSCALL function, etc
should take a few weeks. One possibility is to look at the Franz LISP fasl
and object file loader, and consider using the Unix assembler in a lower
fork with a fasl loader.

Preliminary timings of small interpreted code segments indicate that this
version PSL runs somewhat slower than FranzLISP. There are functions that
are slower and functions that are faster (usually because of SYSLISP
constructs).  We will time some compiled code shortly (have to
cross-compile and link into kernel in current PSL) to identify good and bad
constructs.  We will also spend some time studying the code emitted, and
change the code-generator tables to produce the next version, which we
expect to be quite a bit faster. The current code generator does not use
any three address or indexing mode operations.

We will shortly concentrate on the first Apollo version of PSL.  We do not
expect any major surprises. Most of the changes from the PSL-20 system
(byte/word conflicts) have now been completely flushed out in the VAX
version.  The 68000 tables should be modeled very closely on the VAX
tables. The current Apollo assembler, file-transfer program, and debugger
are not as powerful as the corresponding VAX tools, and this will make work
a little harder. To compensate, there will be less source changes to check
out.



M
-------

Eric
Just finished my long trip plus recovery from East coast flu's etc. Can
you compile the TAK function for me using your portable compiler and send
me the code. Also, could you time it on (TAK 18. 12. 6.). Here's the code
I mean:

(defun tak (x y z)
       (cond ((not (< y x))
	      z)
	     (t (tak (tak (1- x) y z)
		     (tak (1- y) z x)
		     (tak (1- z) x y))))))

I'm in the process of purring together a synopsis of the results from
the meeting. In short, from your viewpoint, we decided that it would be
necessary for us (Common Lisp) to specify a small virtual machine and
for us to then supply to all interested parties the rest of the system
in Common Lisp code. This means that there would be a smallish number
of primitives that you would need to implement. I assume that this
is satisfactory for the Utah contingent.

Unfortunately, a second meeting will be necessary to complete the agenda
since we did not quite finish. In fact, I was unable to travel to
Washington on this account.