Kyoto Common Lisp on SGI

[dixons%phvax.dnet at SMITHKLINE.COM]

In article <818 at mv06.ecf.toronto.edu>, soosaar at ecf.toronto.edu (Robert Soosaar)
writes:
> We are porting Kyoto Common Lisp to our Silicon Graphics
> workstations (Personal Iris and 3000 series) and have come
> across a few problems.
...
>
> On the Personal Iris:
>       A few of the functions are written with in-line assembly
>       code.  These functions (in earith.c and bitop.c) have to
>       be converted into assembler code for the MIPS processor.
>
...
> Rob Soosaar

And in reply, Jim Barton (jmb at sgi.sgi.com) writes
> Might I suggest you just write the same code in C, and let the MIPS optimizer
> turn it into fast assembly.  I haven't hand coded assembly for a 4D for
> speed purposes for years.  The last time I did, I spent hours getting at as
> fast as possible.  Then I wrote the same function in C, compiled & optmized
> it, and found out that the generated code had one less instruction than I
> had.  Why beat your brains out?

The port of KCL to the Personal Iris has been done by Dennis Hultquist
(hultquis at nas.nasa.gov).  He has gotten it mostly working so send him a
message.  Most of the assemble code is trivial.  The one that is a problem
is earith.c, which is not done correctly for the 4D.  The problem there is
that one of the functions in earith is to divide a 64 bit number by a 32 bit
number (actually I think it is a 62 bit number by 31 bits but same difference)
to give a 32 bit answer and a remainder.  There is
no simple way to translate such an operation to C, although on many machines
it is a single instruction.  The other problem, at least for the 4D port is
that there seems (at least from my perusal of the manual) to be no
corresponding machine instruction for the MIPS chips.  Hence, extended
precision arithmetic on the 4D version doesn't work.  If anyone has a good
idea of how to do this, let me or Dennis Hultquist  know.  I am aware of how
it is done in SCHEME but this is pretty complicated and I haven't taken the
time to translate it (essentially a long division algorithm) to the special
case needed for KCL.

Scott Dixon
dixons at smithkline.com