ColdFire was Re: [buildd] Etch?
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/
Reply to: