soosaar@ecf.toronto.edu (Robert Soosaar) (03/27/89)
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 Iris 3130: We cannot get KCL to generate a saved state by dumping to a file. The root of this problem is likely in the unix_save.c routines. 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. If someone has already performed the modifications or even attempted some of these mods. I would appreciate hearing some feedback. Rob Soosaar University of Toronto Institute for Aerospace Studies (416)667-7701 soosaar@ecf.toronto.edu
jmb@patton.SGI.COM (Jim Barton) (03/29/89)
In article <818@mv06.ecf.toronto.edu>, soosaar@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 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? -- Jim Barton Silicon Graphics Computer Systems "UNIX: Live Free Or Die!" jmb@sgi.sgi.com, sgi!jmb@decwrl.dec.com, ...{decwrl,sun}!sgi!jmb "I used to be disgusted, now I'm just amused." - Elvis Costello, 'Red Shoes' --
dixons%phvax.dnet@SMITHKLINE.COM (03/29/89)
In article <818@mv06.ecf.toronto.edu>, soosaar@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@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@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@smithkline.com