hartzell@boulder.colorado.edu (George Hartzell) (12/05/89)
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 <alloca.h>. 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