Xref: utzoo comp.sys.mips:334 comp.lang.scheme:947 Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!mailrus!ncar!boulder!hartzell From: hartzell@boulder.colorado.edu (George Hartzell) Newsgroups: comp.sys.mips,comp.lang.scheme Subject: ELK on the MIPS Message-ID: <14533@boulder.Colorado.EDU> Date: 4 Dec 89 18:16:42 GMT Sender: news@boulder.Colorado.EDU Reply-To: hartzell@boulder.colorado.edu (George Hartzell) Organization: University of Colorado, Boulder Lines: 157 Keywords: Here are the changes necessary to get ELK to run on MIPS systems. This work was done in the bsd43 environment under RISCos 4.01 on a MIPS M-2000. You *must* use the 2.10 compiler release (I used a beta copy) because previous releases don't support a stack-extending alloca (see below). One should be able to build it with gcc, but I haven't tried it yet. This stuff should also be a good starting point for ELK on the DECstation (I think that DEC is just about to release the 2.00 compilers, so you'll have to use gcc or wait a bit longer for the 2.10 suite). The following features work: - the basic interpreter. - dumping preloaded executables. - dynamically loading object files (see below). - The xlib interface (if you have -G 0 compiled version of the X libraries. I made one from the X11R3 source. I haven't tested this very thoroughly yet... I don't know about: - the Xt interface. We don't have the HP widget set (yet), so I couldn't test it. The Xt stuff seems to have compiled correctly (see alloca changes below). There are several types of changes that I had to make: - wrote the MIPS specific version of stack.s and created an empty alloca.s.mips to satisfy the Makefile. - rewrote the routines that need to work with MIPS' unique symbol table format. These changes were substantial enough that I just created a new file for the MIPS version, rather than try to #ifdef it into the original one. Elk's author may or may not stick with this scheme. The new files are dumpmips.c, stabmips.c, and loadmips.c. The Makefile in the src directory is modified by the SRC_PATCHES to use the mips version of these files. The file dumpmips.c explicitly calls "ld2.10". If/when the compilers are installed as the default, this should be changed to "/bsd43/bin/ld". - Change stuff to work with the 2.10 builtin alloca(). Any file that wants to use the builtin alloca needs to include the file . I put this in the MIPS section of config.h, since it is included by scheme.h. I also had to work around the crippled nature of the alloca in the 2.10 compiler suite. While it is a "true" stack extending alloca, it is implemented as an operator, and only works with "integral_types". For instance, this is legal: int size; foo = alloca(size); but this is not: int size; foo = alloca(size+1); I went through all of the sources and replaced every occurrence calls like: int size; ... foo = alloca(size+1); with something similar to: int size; ... #ifdef MIPS_ALLOCA foo = alloca(size+1); #else { int mips_alloca_size = size + 1; foo = alloca(mips_alloca_size); } #endif I dislike declaring variables in local blocks like this, but it seemed like the cleanest way to get things to work. [begin editorial comment] The comment in the alloca header file implies that the builtin alloca was implemented this way for efficiency... It seems to me that forcing me to go through all of the source code and make these changes is not the most efficient way to make it work. If there is really a neat/fast way to do the builtin alloca for "integral_types" (and it seems to me that there would be) then why not make the compiler smart enough to use it when appropriate, and handle the other cases as needed? Maybe the compiler people are planning this? [end editorial comment] The compiler becomes very unhappy (one of the ucode stages dumps core and dies) if you don't assign the pointer returned by the builtin alloca to something. For example, there are two places in scheme's main routine that do this: (void)alloca(something); These were changed to assign the returned value to a scratch variable. I don't know if this is a bug or a side effect of implementing the builtin alloca as an operator. One of the programs for testing stack.s also has this problem. - Any object file that will be fast loaded (dynamically loaded) needs to be compiled and linked with the -G 0 and without the -x flag. The interpreter doesn't need this, and should run more efficiently without it, so I changed the root Makefile to use a different set of compile and load flags when working on the src directory and all of the others. - All of the source file modifications are inside #ifdef's, using the following two identifiers: "MIPS_ALLOCA" for code that handles MIPS' alloca "mips" for two places (src/bignum.c and lib/xlib/font.c) where the code tickles some compiler bug. In both cases, breaking out the complicated expression fixed things. - The modifications to the root Makefile, the lib/xlib/Makefile and the lib/xt/Makefile just comment out the original lines. The modifications to the src Makefile replace dump.c with dumpmips.c, etc... because I was worried about putting a comment line inside the long set of "\" continued lines. It should be easy enough to change it back. A cleaner way to do this would be to define DUMP_SRC (etc...) at the top of the Makefile. I'll leave that to ELK's author for the next release. Three shar files (posted separately) contain the changes: sources.shar README.MIPS (this file) alloca.s.mips dumpmips.c loadmips.c stabmips.c stack.s.mips patches1.shar LIB_PATCHES LIB_UTIL_PATCHES LIB_XLIB_PATCHES LIB_XT_PATCHES patches2.shar ROOT_PATCHES SRC_PATCHES All of the files from the sources.shar file should be put in the src directory. I recommend making a MIPS directory in the root directory and unpacking the patches there. Then just invoke patch as: patch -d .. < ROOT_PATCHES patch -d ../src < SRC_PATCHES patch -d ../lib < LIB_PATCHES patch -d ../lib/util < LIB_UTIL_PATCHES patch -d ../lib/xlib < LIB_XLIB_PATCHES patch -d ../lib/xt < LIB_XT_PATCHES George Hartzell (303) 492-4535 MCD Biology, University of Colorado-Boulder, Boulder, CO 80309 hartzell@Boulder.Colorado.EDU ..!{ncar,nbires}!boulder!hartzell George Hartzell (303) 492-4535 MCD Biology, University of Colorado-Boulder, Boulder, CO 80309 hartzell@Boulder.Colorado.EDU ..!{ncar,nbires}!boulder!hartzell