From 417c8c1a90cb565351408962822fe832e5790502 Mon Sep 17 00:00:00 2001 From: "Clifford T. Matthews" Date: Tue, 9 Jun 2009 10:19:47 -0600 Subject: [PATCH] Updated README/TODO to mention ppc target. --- README | 16 ++++++++++++---- TODO | 33 +++++++++++++++------------------ 2 files changed, 27 insertions(+), 22 deletions(-) diff --git a/README b/README index f9161b9..d929562 100644 --- a/README +++ b/README @@ -18,10 +18,9 @@ show that at least for little endian architectures, 32-bit and 64-bit versions can be built that don't use the native backend. On an i386 Fedora 9, this version of Syn68k compiles and produces a -libsyn68k.a that works with Executor. Tomorrow, Fedora 11 will be -out, using gcc 4.4. I'll try to make it so that Syn68k works on it as -well as older Fedora systems too. I'll try to get it so the i386 and -x86_64 versions of Syn68k works on gcc 4.1, 4.2, 4.3 and 4.4. +libsyn68k.a that works with Executor. Fedora 11 is now out and it +uses gcc 4.4. Once I have Fedora 11 installed, I'll test under gcc +4.4. To compile syn68k on a 32-bit i386 system, try @@ -48,6 +47,15 @@ currently have to override the cleanup script, since the stock script make # 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 + 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 diff --git a/TODO b/TODO index 6093075..ac17fda 100644 --- a/TODO +++ b/TODO @@ -1,19 +1,24 @@ - --enable-native should default to true IFF on i386 + --enable-native should only be present where it's available + and perhaps should default to whatever is fastest (e.g., I + believe it's faster to run native in 32-bit mode on an x86_64 + than it is to run non-native in 64-bit mode on an x86_64, although + I haven't yet timed them) - x86_64 (non-native) doesn't run + only invoke the x86 cleanup & optimize when compiling for an + x86 architecture - try to get non-native i386 running first + Fix i486-cleanup.pl and i486-optimize.pl for all x86 targets + (including Mac OS X) - look at how we convert between Mac addresses and pointers - (especially look at code we used to use on alpha) - - Mac OS X fixes: - - figure out why i486-cleanup.pl basically eats all - of syn68k.s + 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) Make so we can build the various debug versions, non-native, etc. + figure out *exactly* which options should be available + via configure + Figure out exactly which variables Makefile.common.in sets, then get rid of Makefile.common.in @@ -31,14 +36,6 @@ Make sure we get proper dependencies (if possible) - make sure syn68k builds on a powerpc (either the - old yellow dog linux on sybil, or on Mac OS X on sybil) - - non-native - - figure out *exactly* which options should be available - via configure - write-up what is needed to do testing on a real m68k need a .spec file so we can build syn68k and syn68k-devel