Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

No more need for extra arguments to configure (at least on the system…

…s I'm currently testing)
  • Loading branch information...
commit b9044353deba13876bd024ea42c8be04e2ff3d8f 1 parent dada69c
Clifford Matthews authored
Showing with 35 additions and 83 deletions.
  1. +30 −61 README
  2. +0 −18 TODO
  3. +5 −4 runtime/i486-cleanup.pl
View
91 README
@@ -1,36 +1,44 @@
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.
+(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 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 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. 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
-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.
+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.
-On i386 Fedora systems (tested on 9 and 11), this version of Syn68k
-compiles and produces a libsyn68k.a that works with Executor.
-
-To compile syn68k on a 32-bit i386 system, try
+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
@@ -42,52 +50,13 @@ glibc-devel.i386 and libgcc.i386) then try this hack
make
make install
-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
-(i486-cleanup.pl) will consume all of syn68k.s.
-
- ./autogen.sh
- CLEANUP='' ./configure
- make
- make install
-
-To compile syn68k on PowerPC 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
- make install
-
-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
-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:
-
-The code in runtime/i486-cleanup.pl no longer gets rid of all the
-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.
+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)
+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
View
18 TODO
@@ -1,21 +1,3 @@
-TEST Need to make it so that the minimal required compilation options for
- x86_64 (-fno-dce) are set up by default
-
-TEST cleanup and optimize shouldn't be done via environment variables;
- they should be done with AC_ARG_ENABLE and default to be turned on
- on the architectures where they work (and should be made to work on
- the architectures they support)
-
-TEST only invoke the x86 cleanup & optimize when compiling for an
- x86 architecture
-
- can probably write cleanup scripts for other architectures,
- don't think it's worth doing optimize though (which may no
- longer be a good idea w/ newer compilers)
-
- Fix i486-cleanup.pl and i486-optimize.pl for all x86 targets
- (including Mac OS X)
-
See if we can find an address to map that is available to all our
currently tested targets (i386-native, i386-notnative, x86_64,
ppc)
View
9 runtime/i486-cleanup.pl
@@ -6,13 +6,13 @@
# aligned optimally.
# Delete the header for each function
-if (/^\.globl _?s68k_handle_opcode_0x/ .. /^[#\/]APP$/)
+if (/^\.globl _?s68k_handle_opcode_0x/ .. /^[#\/]APP$|^_?S68K_HANDLE_0x....:$/)
{
- print if (/^[#\/]APP/ || /^L/);
+ print if (/^[#\/]APP/ || /^L/ || /^_?S68K_HANDLE_0x....:$/);
}
# Delete the trailer for each function
-elsif (/^_S68K_DONE_WITH/ .. /^\s*ret$/)
+elsif (/_S68K_DONE_WITH/ .. /^\s*ret$|^\s*jmp\s+_s68k_handle_opcode_dummy$/)
{
print if (!/\s*movl %ebp,%esp$/
&& !/\s*leal\s*(-?\d+)?\(%ebp\),%esp$/
@@ -20,7 +20,8 @@
&& !/\s*popl/
&& !/\s*ret$/
&& !/^_S68K_DONE_WITH/
- && !/s68k_handle_opcode/);
+ && !/s68k_handle_opcode/
+ && !/^\s*jmp\s+_s68k_handle_opcode_dummy$/);
}
elsif (/^\s*lods/)
{
Please sign in to comment.
Something went wrong with that request. Please try again.