[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.
> 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).
> 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.



Reply to: