Synthetic 68K CPU (used by Executor)
Go to file
2009-12-05 17:36:04 -07:00
config
include x86_64 runs now, although so far only with optimization flags lowered by hand. 2009-06-08 20:07:17 -06:00
profile make distcheck works. 2009-12-05 15:34:57 -07:00
runtime Fixed so we can build in our source directory (make distcheck doesn't check that). 2009-12-05 17:36:04 -07:00
syngen make distcheck works. 2009-12-05 15:34:57 -07:00
test make distcheck works. 2009-12-05 15:34:57 -07:00
.gitignore make distcheck works. 2009-12-05 15:34:57 -07:00
AUTHORS
autogen.sh Fixed to build on Fedora 11 and Fedora 12. 2009-11-27 12:31:18 -07:00
ChangeLog
configure.ac Fixed underscore detection to work on Snow Leopard. 2009-12-05 17:35:31 -07:00
COPYING
Makefile.am make distcheck works. 2009-12-05 15:34:57 -07:00
Makefile.common.in
NEWS
README updated README to mention that Syn68k will not build properly under Snow Leopard. 2009-11-27 13:54:25 -07:00
TODO No more need for extra arguments to configure (at least on the systems I'm currently testing) 2009-06-22 22:38:05 -06:00
TODO.variables

========================================================================
Mac OS X 10.6 (Snow Leopard) note:  by default gcc now creates 64-bit
binaries, which means the version of Syn68k that will be built won't work
with Executor.  The "-m32" command line option does the right thing, so it
should be possible to get Syn68k (and Executor) to work on Snow Leopard
again, but I don't know that I'll have much time for it.
========================================================================


Syn68k is a "synthetic CPU" that executes Motorola 68LC040
instructions, either via interpretation or via compilation into Intel
(32-bit) x86 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.

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.

In late 2003 we did a partial conversion from our 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 2008.

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 when I
first put it on GitHub.  There's still a lot of cruft that can be
removed, but at least there are enough variants that can be built to
show that both big-endian (e.g., PowerPC) and little-endian
(e.g. i386, x86_64), 32-bit and 64-bit, native (i386-only) and
non-native versions work.

To compile syn68k, try

  ./autogen.sh
  ./configure
  make

To test syn68k, run test/syngentest and compare the output to
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.

If you plan on building Executor, you'll need to put Syn68k where it
can be found during Executor's build.  The easiest way is with

  make install

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
    On Fedora 11 I needed glibc-devel.i586 and libgcc.i586
    On Fedora 12 I needed the .i686 versions of those packages

Once you have those install, try this:

  ./autogen.sh
  CC='gcc -m32' ./configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
  make
  make install

It's possible to compile a 64-bit version of Syn68k on an x86_64, but
such a version won't work with Executor yet (and will not use native
x86 instructions).

My email address is still <ctm@ardi.com>, although ARDI itself is
defunct.  I get a ridiculous amount of spam and will quite possibly
not see email addressed to me.  I'm ctm on GitHub (http://github.com)
and typically check my email there once a day.

--Cliff Matthews