syn68k/README

93 lines
3.9 KiB
Plaintext
Raw Normal View History

2009-06-10 22:42:45 +00:00
Syn68k is a "synthetic CPU" that executes Motorola 68LC040
instructions, either via interpretation or via compilation into Intel
ia32 instructions. It was originally written to allow Executor (a
Macintosh emulator) to run on platforms that didn't contain a 680x0
CPU. Executor first ran on the Sun-3, and then on NeXT computers.
2009-06-09 04:02:29 +00:00
Syn68k has not been actively worked on since about 1995. When it was
originally written, there were a bunch of alterable variables in
various Makefiles that allowed us to build Syn68k for many different
architectures with a few different features.
2008-09-26 14:28:53 +00:00
2009-06-09 04:02:29 +00:00
In late 2003 we did a partial conversion from our home-grown build
system to the GNU build system. The result was a Syn68k that could be
built with the then current version of gcc but basically only for the
i386 architecture using the native code back-end. That's basically the
state Syn68k was in when I put the code on github in September 2006.
In June 2009, I've been able to scrape together a little free time and
make it so Syn68k builds on a few more platforms than it did. There's
still a lot of cruft that can be removed and still a bunch of gotchas
that require special command line arguments to the configuration
utility, but at least there are enough variants that can be built to
2009-06-10 14:16:22 +00:00
show that both big-endian (e.g., PPC) and little-endian (e.g. i386, x86_64),
32-bit and 64-bit, native (i386-only) and non-native versions work.
2009-06-10 14:16:22 +00:00
On i386 Fedora systems (tested on 9 and 11), this version of Syn68k
compiles and produces a libsyn68k.a that works with Executor.
2009-06-02 14:25:10 +00:00
To compile syn68k on a 32-bit i386 system, try
./autogen.sh
./configure
make
2009-06-02 14:25:10 +00:00
make install
2009-06-09 04:02:29 +00:00
To compile a 32-bit syn68k on an x86_64 system, make sure you have all
the 32-bit libraries you need (on Fedora 10 I needed to install
glibc-devel.i386 and libgcc.i386) then try this hack
./autogen.sh
CC='gcc -m32' ./configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
make
make install
2009-06-09 04:02:29 +00:00
To compile syn68k on Intel Mac OS X (tested under 10.5.7), you
currently have to override the cleanup script, since the stock script
2009-06-08 01:12:25 +00:00
(i486-cleanup.pl) will consume all of syn68k.s.
2009-06-06 20:23:16 +00:00
./autogen.sh
CLEANUP='' ./configure
make
2009-06-09 04:02:29 +00:00
# No point to installing it, since Executor doesn't run on Mac OS X
To compile syn68k on PPC Mac OS X (tested under 10.5.7), you must explicitly
request the non-native port (the default is to try to build the native
backend even on architectures where it's not supported--bad default!)
./autogen.sh
./configure --disable-native
make
# No point to installing it, since Executor doesn't run on Mac OS X
2009-06-09 04:02:29 +00:00
It's possible to compile a 64-bit version of Syn68k on an x86_64
(which won't work with Executor, AFAIK), but you currently need to
manually adjust SYN68K_CFLAGS (at least Fedora 10's gcc 4.3.2 20081105
(Red Hat 4.3.2-7)) due to a bug that allows "dead code elimination" to
eliminate updates to a global register.
./autogen.sh
SYN68K_CFLAGS='-O2 -fomit-frame-pointer -fno-dce' ./configure --disable-native
make
# No point to installing it, since Executor doesn't run in 64-bit mode
To test syn68k, run test/syngentest and compare the output to
2009-06-08 01:12:25 +00:00
test/output/10000. It should be the same, assuming the same block of
memory can be obtained for the test. If you want to be more thorough,
you can use other command line options and compare the results to
other files, as described in test/output/README.
Performance nit:
2009-06-02 14:25:10 +00:00
The code in runtime/i486-cleanup.pl no longer gets rid of all the
2009-06-06 20:23:16 +00:00
cruft in the trailer (except under Mac OS X, where it gets rid of way
too much code). It's quite possible that the code in
runtime/i486-optimize.pl doesn't do the right thing either.
My email address is still <ctm@ardi.com>, although ARDI itself is
defunct. I get a ridiculous amount of spam and will quite possibly
2009-06-10 22:42:45 +00:00
not see email addressed to me. I'm ctm on github (http://github.com)
and typically check my email there once a day.
2009-06-09 04:02:29 +00:00
--Cliff Matthews