On Fri, 4 Aug 2006, Wouter Verhelst wrote:
> On Fri, Aug 04, 2006 at 12:24:21PM +0200, Roman Zippel wrote: > > While it's possible to avoid these instructions, it would mean > > possibly very larger code and thus even slower code. > [snip] > I agree that the loss of addressing modes and of opcodes may make the > object code larger; I am not convinced, however, that this will result > in problematic differences, especially not if we include optimized C > libraries that can be used by 2.6 kernels on different machines (and the > intent is to do this, very much in the same way that there is now a > libc6-686 package on the i386 architecture). [snip] > it is certainly true that hybrid code will not be the most optimal code > anywhere. > > As I see it, however, we have two alternatives to a hybrid architecture: > the first is that we do nothing, keep things as they are, and have the > port face more and more moments like this one as time progresses; > eventually, there will be a point where we will simply have to give up. > Having the port run on ColdFire hardware as well will slow this > evolution down; if not indeterminally, then at the very least by a few > years. > > The second alternative would be to drop classic 68k hardware completely > and to focus on ColdFire hardware _only_. I'm sure that's not what you > want. If there was a m68k backend for GCC-LLVM [1], the m68k port could ship LLVM-IR that was assembled for the target at install time. Could be a viable long term solution. In the short term, I think we have to wear the performance hit of lowest-common-denominator hybrid binaries. At least LLVM seems to be a more maintainable design than GCC. -f [1] http://www.gelato.org/pdf/apr2006/gelato_ICE06apr_llvm_lattner_apple.pdf http://llvm.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
