hultquis@wk31.nas.nasa.gov (Jeff P.M. Hultquist) (04/08/89)
> Subject: KCL for MIPS machine? > > Are there patches to allow KCL to work on MIPS machines? (i.e. the DEC > MIPS machine that just came out?) If so, could somebody please direct > me to them? I ported KCL to a Silicon Graphics "Personal Iris", which also contains the MIPS chip. I don't have the diffs, but I can report that these changes were required ... ------------------------------ copied from tape touch all the sources to ensure proper 'make' check that ... have not been truncated lsp/evalmacros.data cmpnew/cmpspecial.data put 'SHELL=/bin/sh' in makefiles changed makedefs for SGI4 * added "sgi4_chtab.s" to makefile * no RSYM and no SFASL * changed include.h and mdefs.h to define SGI4 * added sgi4_chtab.s to /c make sources This invokes some "super-diff" utility written by Bill Schelter of Texas. He is the author of the changes which cellectively transform KCL to A_KCL (the 'a' stands for Austin). patch page.h to account for data segment bit The MIPS processor (which is in the IRIS-4) has a high-order bit set on the data segment, and this bit must be accounted for when we convert between page numbers and addresses. See the note below regarding the need to relocate the data segment from its default position. added new code to find start of fasl_vector in file.d The object file format is different, and so locating the start of the FASL vector has changed. This new code mucks about in the object file headers to find the right place. (Personally, I think that appending the FASL stuff to the end of the object file is a very bad idea.) externs needed ... * array declarations in cmpinclude.h * character_table[] in object.h * lisp_implementation_version[] in external.h * system_directory[] in external.h earith.c defined 'extended_mul' and 'extended_div' to the extended arithmetic routines. I don't want SFASL! * changed h/include.h so that it no longer defines SFASL * commented 'sfasl.o' out of o/makefile (The makefiles in this system are a mess!) changed unixfasl.c Completely rewrote this file, using code from GNU and lots of advice from SGI. The system can only incrementally load if the data section in within the same segment (256 meg?) as the text segment. This is because the JAL instruction has only 28 bits available for the jump offset. The entire system must therefore be compiled with '-Wl,-D,a000000' which instructs the linker to move the data section in closer. Changed the call to 'fasload' in 'file.d' so that uses the new stuff in 'unixfasl'. add *features* to main.c Must define the features (UNIX, IEEE, ...) which are available under this implementation. This sort of stuff should be defined in LISP, and _not_ in C, but nobody asked me. :-) changed to 'vararg' passing in ... 'list' and 'listA' in list.d 'parse_keys' and 'check_other_keys' in bind.c These four routines take an indeterminate number of arguments, but they did _not_ use real honest-to-God varargs. Now they do. new version of unixsave, which uses 'unexmips.c' Replaced unixsave with the unexmips which is packaged with GNU. Also had to change the call to 'unexec' in 'unixsave.c'. Also, 'unixsave.c' used to call '_cleanup', this does not work on an IRIS-4 (it leaves the saved image with a null '_iob'). ******** known bugs ******** Bignums don't work ... 'nuff said. The compiler can't handle gl-funcs.lsp, which is the collection of graphics library hooks originally written by Eric Raible. (directory "") does not work ... the pathname seems to be mangled before the directory open is attempted. Jeff Hultquist hultquis@prandtl.nas.nasa.gov (415) 694-4970